|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
Добрый день! Есть такое архитектурное решение (изначально не моё): 1) Внешняя система заливает данные по проводкам в первичную таблицу как есть, при этом в виде guid каждой строки генерится рандомно и уникально набор символов, близкий по смыслу к GUID. По этому полю построен индекс (некластерный). 2) Есть уже реальная таблица в витрине с таким же именем и почти такой же структурой, которая синхронизируется с таблицей из пункта 1) Сейчас возникают долгие запросы при синхронизации, этих 2-х таблиц. Так как кол-во строк порядка 30 мл-нов. Вот думаю, в какую сторону копать. Вижу несколько вариантов: а) Cделать это id поле числовым и заново попросить перелить таблицу1. б) Генерить в поле id tableотсортированный гуид и накатить на него Primary Key кластерный - тогда запросы синхронизации , по типу Код: sql 1.
пойдут побыстрее. А как сделали бы вы , есть у вас такой опыт? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.03.2021, 19:05 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
medoed а) Cделать это id поле числовым и заново попросить перелить таблицу1. б) Генерить в поле id tableотсортированный гуид и накатить на него Primary Key кластерный - тогда запросы синхронизации , по типу б) если синхронизация случайных записей, то разница будет только в отсутствии лукапа. Впрочем, какую то выгоду это даст. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.03.2021, 20:45 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
Посчитать хэш, но он, вероятно, итак считается. GUID в качестве идентификатора взят, скорее всего, именно в расчёте на последующее сливание таблиц. Переход в INT заставит Вас потом рожать механизм синхронизации такой что бы избежать коллизий из серии "какого чёрта,- тут 12345678 и тут тоже 12345678, но они разные! ". Ну и вместо int брать стразу bigint ... В общем - посмотрите как выполняется запрос на слияние (возможно что у Вас запрос мудрёный, с доп.условиями) , и добавьте памяти и быстрый диск... 30 лямов записей - это не так уж и много... ... |
|||
:
Нравится:
Не нравится:
|
|||
16.03.2021, 22:56 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
medoed, какой объём вставки одной транзакции? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 00:29 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
medoed Добрый день! Есть такое архитектурное решение (изначально не моё): 1) Внешняя система заливает данные по проводкам в первичную таблицу как есть, при этом в виде guid каждой строки генерится рандомно и уникально набор символов, близкий по смыслу к GUID. По этому полю построен индекс (некластерный). 2) Есть уже реальная таблица в витрине с таким же именем и почти такой же структурой, которая синхронизируется с таблицей из пункта 1) Сейчас возникают долгие запросы при синхронизации, этих 2-х таблиц. Так как кол-во строк порядка 30 мл-нов. Вот думаю, в какую сторону копать. Вижу несколько вариантов: а) Cделать это id поле числовым и заново попросить перелить таблицу1. б) Генерить в поле id tableотсортированный гуид и накатить на него Primary Key кластерный - тогда запросы синхронизации , по типу Код: sql 1.
пойдут побыстрее. А как сделали бы вы , есть у вас такой опыт? Сферическая синхронизация в вакууме? И каким именно боком guid участвует в вашей "синхронизации"? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 06:40 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
aleks222, Покрасоваться решили? Запрос выше на примере delete ,в нем id типа guid. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 08:01 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
Владислав Колосов, С утра разовая вставка порядка 50 к записей. Ну и днём могут прилетать небольшие изменения(каждые 15 минут) по 100-500 записей. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 08:03 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
SIMPLicity_, Не , слияние таблиц особо не предусмотрена. Тут клиенту просто привычней генерить символьный идентификатор для вставки в базу. Ну и классическая схема - быстрая вставка в табличку импорта, а дальше в самой базе уже через процедуру синхронизация с таблицей master. Синхронизация(полная, а не только свежих данных) , как раз через этот guid , так как он уникален. Ну и опасений нет, что числовой счётчик собъется. Такая схема норм работала, пока не выросли объемы. Оперативы достаточно и по процам норм. На ssd базу пока переносить не планируем ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 08:10 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
medoed, Про логику синхронизации не пояснили, но судя по по приведённому Вами запросу с DELETE в этой логике не всё оптимально. Т.е. по всей видимости сначала "набиваем под завязку" данными таблицу, а потом из таблицы "вычёркиваем" то, что не пригодилось. Закономерно при таком подходе с ростом количества записей механизм будет проседать по производительности всё сильнее и сильнее, и замена GUID на любой другой идентификатор только даст временную отсрочку. Может быть есть возможность пересмотреть алгоритм синхронизации? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 09:10 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
zeon11 medoed, Про логику синхронизации не пояснили, но судя по по приведённому Вами запросу с DELETE в этой логике не всё оптимально. Т.е. по всей видимости сначала "набиваем под завязку" данными таблицу, а потом из таблицы "вычёркиваем" то, что не пригодилось. Закономерно при таком подходе с ростом количества записей механизм будет проседать по производительности всё сильнее и сильнее, и замена GUID на любой другой идентификатор только даст временную отсрочку. Может быть есть возможность пересмотреть алгоритм синхронизации? Скорее вы правы. План и то что в нём не нравится прилагаю. Переписать есть возможность - а как бы вы сделали? Во время вставки в первую таблицу , триггер на ней прикрутить, который будет данные синхронизировать во второй? Но мне кажется это тоже не самый гут вариант. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 09:23 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
medoed, Синхронизация двусторонняя? Т.е. новые данные появляются в двух таблицах, или нисходящая, т.е. новые данные появляются только в одной таблице? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 09:28 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
zeon11 medoed, Синхронизация двусторонняя? Т.е. новые данные появляются в двух таблицах, или нисходящая, т.е. новые данные появляются только в одной таблице? Нисходящая только в таблице 1, потом они перетекают из неё в таблицу 2-ва. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 09:32 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
medoed, Можно сделать так, например, в обоих таблицах создать поле признака синхронизации. Новые данные изначально помечаются признаком "Не синхронизированны". Затем при синхронизации признак переводится в состояние "Синхронизирован". Таким образом при первичной настройке серверу придётся "попотеть" на синхронизации, зато в последующем Вы получите ламинарный поток данных, без роста нагрузки во времени. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 09:40 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
zeon11 medoed, Можно сделать так, например, в обоих таблицах создать поле признака синхронизации. Новые данные изначально помечаются признаком "Не синхронизированны". Затем при синхронизации признак переводится в состояние "Синхронизирован". Таким образом при первичной настройке серверу придётся "попотеть" на синхронизации, зато в последующем Вы получите ламинарный поток данных, без роста нагрузки во времени. Но если находятся косяки, то часто бывает данные полностью переливаются в таблице 1 , тогда признак синхронизации не особо поможет. Так как источник синхронизации порядком изменился. Прикрепляю план изначальный, который не нравится мне (таблицы тестовые)... ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 09:43 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
В случае нисходящей синхронизации достаточно признак синхронизации поместить только в одну, рабочую таблицу. В накопительной таблице этот признак можно и не ставить. И да, в рабочей таблице нужно сделать блокировку на изменение синхронизированных данных (в триггере напр.) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 09:48 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
medoed, Извини, срочно уезжаю, вечером подумаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 09:50 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
medoed aleks222, Покрасоваться решили? Запрос выше на примере delete ,в нем id типа guid. В вашем запросе абсолютно фиолетово, что там целое или guid. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 10:12 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
medoed Прикрепляю план изначальный, который не нравится мне ЗЫ: Для синхронизации придумали инструкцию MERGE ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 10:19 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
aleks222 medoed aleks222, Покрасоваться решили? Запрос выше на примере delete ,в нем id типа guid. В вашем запросе абсолютно фиолетово, что там целое или guid. Однако int поменьше весит и по нему Primary Key кластерный можно построить! Запрос будет в разы быстрее, нежели не по отсортированному GUID-у! ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 10:27 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
invm medoed Прикрепляю план изначальный, который не нравится мне ЗЫ: Для синхронизации придумали инструкцию MERGE До этого с Db2 работал некоторое время - там Merge подглючивал. Но вот переписал по вашему совету на Merge, та же самая хрень! ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 11:07 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
medoed та же самая хрень! ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 11:11 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
invm medoed та же самая хрень! Index Seek если весь запрос войдёт - будет гут! ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 11:22 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
medoed, Подумайте над тем, что работать с полной копией (30 млн строк) данных по определению менее эффективно, чем с инкрементом (<= 50К строк). Инкремент - это если бы вы удаляли из таблицы 1 данные, примененные на таблице 2 (в одной транзакции). Сложности с применением удалений к таблице 1 вполне решаемы (типично для ХД). На худой конец приемлема имитация инкремента посредством признака синхронизации, о котором говорилось выше. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 11:22 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
medoed Index Seek если весь запрос войдёт - будет гут! Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 11:30 |
|
Guid как id для многомилионной таблицы (тормоза)
|
|||
---|---|---|---|
#18+
SIMPLicity_ Посчитать хэш, но он, вероятно, итак считается. GUID в качестве идентификатора взят, скорее всего, именно в расчёте на последующее сливание таблиц. Переход в INT заставит Вас потом рожать механизм синхронизации такой что бы избежать коллизий из серии " какого чёрта,- тут 12345678 и тут тоже 12345678, но они разные! ". Ну и вместо int брать стразу bigint ... В общем - посмотрите как выполняется запрос на слияние (возможно что у Вас запрос мудрёный, с доп.условиями) , и добавьте памяти и быстрый диск... 30 лямов записей - это не так уж и много... Так может думать совсем далекий девелопер, который не знаком со словом HASH ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2021, 11:37 |
|
|
start [/forum/topic.php?fid=46&fpage=30&tid=1684940]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
28ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 146ms |
0 / 0 |