|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
Друзья, помогите с секционированием (MSSQL 2017). Есть таблица некой статистики (телеметрия): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
При построении индексов используется FillFactor 50%, индексы регулярно перестраиваются. Записей в таблице - несколько миллиардов. Индексы и данные лежат в разных файлах, на разных дисках. Обеспечивается быстрый поиск по A+B+C, по A и по B. Раз в сутки обеспечивается слияние с таблицей суточной статистики аналогичной структуры. Обновляется более 50% записей (обновляются только [EndTime] и [Count]), производительность апдейта устраивает (до 5 минут). Однако вставка нескольких тысяч новых строк занимает более часа. Смотрю в сторону секционирования таблицы с функцией партицирования [pf_BegTime] по полю [BegTime], чтоб новые записи валились в новый файл (каждую неделю создавать). Начал было реализовывать, но столкнулся с проблемой уникального индекса [idx_Main], который должен быть уникальным не только в пределах секции, но и во всей таблице: Код: sql 1.
Попытка создания завершается ошибкой: Column 'BegTime' is partitioning column of the index 'uix_Main'. Partition columns for a unique index must be a subset of the index key. Помогите плиз. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2020, 21:49 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
=Сергей= Помогите плиз. Никак, секционированный уникальный индекс обязан содержать поле секционирования в ключе. Я даже скажу больше, неуникальный так же будет содержать поле секционирования в ключе неявно. Ограничение понятно, поддерживать уникальность в рамках нескольких секций достаточно проблематично. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2020, 22:14 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
А как ещё повысить производительность при вставке? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2020, 23:49 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
=Сергей=, авторвставка нескольких тысяч новых строк занимает более часа Что-то мешает вставке, такое незначительное количество не может вставляться столько времени. Например, висят долгие читающие запросы на таблице, или еще что-то. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2020, 01:08 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
offtopic =Сергей= При построении индексов используется FillFactor 50%Задлянафига? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2020, 03:50 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
SERG1257 Задлянафига? Как то исторически сложилось ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2020, 09:13 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
SERG1257 offtopic =Сергей=При построении индексов используется FillFactor 50% Обычно это делается для избежания page splits ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2020, 09:48 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
Владислав Колосов Что-то мешает вставке, такое незначительное количество не может вставляться столько времени. Например, висят долгие читающие запросы на таблице, или еще что-то. Я гляну и отпишусь, спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2020, 17:04 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
msLex Обычно это делается для избежания page splits Чтобы избежать вредной фрагментации. А что такое FillFactor 50% - та самая фрагментация и есть, причем во всей таблице/индексе, а не только в задетой странице ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2020, 17:23 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
SERG1257 msLexОбычно это делается для избежания page splits Нет, page splits неприятен не столько появлением физической (внутренней) фрагментации, сколько просадкой перфонанса в ходе самого расщепления страниц. Поэтому, коль уж фрагментации все равно не избежать, индексы, подверженные расщеплению, принудительно фрагментируют, ребилдя с FillFactor меньше 100. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2020, 17:42 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
SERG1257, проблема фрагментации минорная, появляются задержки вставки, которые вызываются расщеплением страниц, в том числе переносом данных. Если данные гарантированно добавляются "в конец" таблицы, то иметь fillfactor <> 100 (0) нет смысла. Фактор заполнения выбирается таким образом, чтобы в периодах между регулярной переиндексацией количество расщеплений было бы минимальным. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2020, 19:39 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
msLex просадкой перфонанса в ходе самого расщепления страницЧто не проблема для кластерного индекса у TC и неизвестно является ли проблемой для некластерных индексов. Зато вдвое медленнее будет бакап, checkdb, меньше данных в памяти и т.д. и т.п. Так что =Сергей= на следующем перестоении индексов поставь 100% для кластерного и хотя бы 80% (а можешь начать с 100% и уменьшать потом) для некластерных. Это не решит проблемы с медленным добавлением нескольких тысяч строк, но другим операциям станет легче дышать. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2020, 19:42 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
=Сергей= Владислав Колосов Что-то мешает вставке, такое незначительное количество не может вставляться столько времени. Например, висят долгие читающие запросы на таблице, или еще что-то. Я гляну и отпишусь, спасибо Может, записи с гигантскими блобами? Но скорее какой то дефект, экзотический, типа индекса на инсёрт, который стучится к связанному серверу или эксельному файлу. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2020, 23:18 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
alexeyvg типа индекса на инсёрт, который стучится к связанному серверу или эксельному файлу. триггера ... |
|||
:
Нравится:
Не нравится:
|
|||
11.10.2020, 10:07 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
komrad alexeyvg типа индекса на инсёрт, который стучится к связанному серверу или эксельному файлу. триггера Посмотрим на результат исследований ТС, интересно, что там так мешает. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.10.2020, 22:26 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
А зачем собственно секционирование вообще может потребоваться, особенно в облаке? Ну вот есть предположим 100 мл таблица, ну разбили ее 10 партиций по 10 мл. Что конкретно от этого ускорилось - запросы? Так там индексы есть, искать по индексу что на 10мл, что 100мл разницы-то особой не будет. Или переключение партиций, оно конечно мгновенно подключится, но загрузка в source-то столько-же времени займет. Что-то от меня ускользает смысл их использования ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 04:37 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
В телеметрии 100млн может быть за неделю . . . ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 05:23 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
авторЧто конкретно от этого ускорилось - запросы очистка старых данных ускорилась. дроп партиции и всё. по идее ускорились запросы хорошо попадающие в одну партицию целиком. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 15:57 |
|
Секционирование таблицы
|
|||
---|---|---|---|
#18+
ScareCrow авторЧто конкретно от этого ускорилось - запросы очистка старых данных ускорилась. дроп партиции и всё. по идее ускорились запросы хорошо попадающие в одну партицию целиком.Необязательно, даже "как правило" необязательно. 982183 В телеметрии 100млн может быть за неделю . . . И это немного, это была агрегированная телеметрия, наверное, кто то обрабатывает и "сырую"... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 20:40 |
|
|
start [/forum/topic.php?fid=46&msg=40007267&tid=1685508]: |
0ms |
get settings: |
9ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
1089ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 1190ms |
0 / 0 |