Комментарии 8
У нашего клиента, первый и единственный столбец в индексе являлся монотонно возрастающим ключом. Из-за этого, каждая новая вставка шла на ту же самую страницу в конце В-дерева, пока эта страница не была заполнена.
гхм, тут наоборот борются за монотонность uuid:
https://github.com/uuid6/uuid6-ietf-dr
потому что вставка в случайные места b-tree тоже имеет свои проблемы (увеличивается фрагментация индекса, больший объём записи в лог, проблемы с cache hit)
Предложенный способ как раз с одной стороны сохраняет монотонность, чтобы новые строки укладывались по возрастанию значения составного CI, а с другой - равномерно раздает строки по секциям, как колоду карт N игрокам - так что с точки зрения физического реордера данных при псевдослучайном PK, который CI, это порядково лучше. В каждую секцию ложатся записи с ID (1, 5, 9, ..), (2, 6, 10, ..) итд. Вот только я не знаю, не лучше ли буферизованный insert, в котором каждый процесс сначала грузит пачку записей хоть в табличную переменную, а потом делает INSERT .. FROM ..SELECT
Вот только я не знаю, не лучше ли буферизованный insert
лучше, конечно, но это уже изменение логики работы системы, что не всегда допустимо.
..и здесь мы начинаем в очередной раз сочувствовать бедным ДБА, которые изо всех сил пытаются выправить огрехи проектирования систем вертикальными разработчиками, отвоевывая пару десятков процентов там, где изначально-правильное проектирование (с тем же ДБА с правом вето в составе команды) сэкономило бы девяносто этих процентов..
не могу согласиться на 100%.
это хорошо работает если данные, условно говоря, ничего не стоят.
если же нам нужно обеспечивать acid, то нескинутые в БД данные придётся всё равно сохранять в каком-то персистентном хранилище, создавать механизм восстановления после сбоев.
да, это всё реально, но
a. сложнее, чем просто записать в базу;
b. вероятность выстрелить себе в ногу высока, а разработчики СУБД на обеспечении сохранности данных, как говорится, собаку съели.
там, где нет экстремального хайлоада, или наоборот эмбедда со своими ограничениями, лучше переложить эту головную боль на базу данных.
статей по теме много, вот, например, применительно именно к ms sql:
https://www.mssqltips.com/sqlservertip/6595/sql-server-guid-column-and-index-fragmentation/
а вот про постгрес:
https://habr.com/ru/company/ozontech/blog/564520/
и в ms sql даже есть специальный механизм, который обеспечивает естественную сортировку некоторых uuid:
https://stackoverflow.com/questions/7810602/sql-server-guid-sort-algorithm-why
Как справиться с PAGELATCH при высоко-параллельных INSERT-нагрузках