MUMPS: Массовое перестроение индексов

Операция поддержания индексов в актуальном состоянии обычно состоит в обновлении индексных структур при изменении основных, индексируемых. Некоторым особняком стоит операция массового перестроения индекса по каким-либо причинам. При ее исполнении перестраиваются индексные записи для одновременно большого числа записей. В эксплуатационном отношении это массовое перестроение может быть оптимизировано как программно, так и административно (если такая возможность предусмотрена).

К массовому перестроению индексов / одного индекса приводят задачи:

Создание индекса

При создании индекса СУБД должна для каждой имеющейся индексируемой записи выполнить вставку индексных записей. При этом, пока идет их вставка, сами данные не изменяются.

Изменение кластерного индекса

При изменении кластерного индекса все записи меняют идентификаторы, поэтому все другие индексные записи должны быть перестроены. При перестроении записей сами данные не изменяются.

Массовый импорт данных

Обычно перед импортом данных индексы отключают, если есть такая возможность, проводят импорт, потом включают индекс. Пока индекс выключен, он просто накапливает информацию о необходимости переиндексации определенных записей - вместо внесения индексных структур делается отметка о том, что после включения индекса может быть не полное перестроение индексных записей, а только для измененных / добавленных / удаленных записей. После включения (или активации) индекса перестроение идет не по всем записям, а только по тем, о которых есть отметка.

Удаление данных таблицы

При удалении индексируемых записей СУБД может выполнить как позаписное удаление (delete * from table), так и массовое освобождение занимаемого пространства (truncate table). В случае М-систем полного аналога truncate не существует, поэтому оптимизировать можно лишь удаление индексных структур - при полном удалении данных таблиц полностью удалять все индексные деревья.

Возможное изменение структуры индексируемых данных

Если в структуре индексных записей как-то использовалась информация о структуре индексируемой записи, то в случае ее изменения такие индексы также должны быть перестроены - имеющиеся записи удалены и построены новые.

Изменение определения индекса

При поддержании индекса с условием на вставку или индекса с вычисляемым значением это условие и выражение вычисления могут измениться. В этом случае все индексные записи по такому индексу должны быть удалены и построены заново. В целях оптимизации по времени выполнения операции массового перестроения индексов мы можем использовать специфические для этих операций признаки:

• Индексируемые данные не меняются. При этом мы выполняем цикл. Следовательно, у нас могут оказаться инварианты цикла, которые мы можем вынести за пределы цикла. Например, мы можем эскалировать блокировки до более общих, сэкономить на создании и очистке временных переменных и так далее. Вынос инварианта за пределы цикла - это оптимизационная задача, и она может быть выполнена обычно только после составления самого кода, который нужно оптимизировать.<\li>
• При массовой вставке индексных записей мы предполагаем, что эта операция может быть длительной и затронуть значительное количество узлов. Поэтому мы может использовать наиболее общую блокировку индексных и индексируемых записей. Более того, такая эскалация может сделать бессмысленной работу пользователей, и могут быть предприняты специальные административные меры по отключению пользователей от системы на время таких длительных операций.
• В случае если идет массовое удаление индексных записей мы в итоге должны получить состояние их полного отсутствия. Поэтому нет нужды удалять каждый узел - можно удалить все дерево целиком.
• В случае если идет массовая вставка индексных записей то в большинстве случаев мы можем использовать специфические для СУБД средства, например $SortBegin / $SortEnd в СУБД Cache.
• Мы можем программно включить или отключить опцию журналирования / не журналирования. Чтобы при выполнении операции администратор мог выбрать - использовать журналирование каждой операции или выключить журналирование, провести перестроение записей и снова включить журналирование, с тем чтобы после этого выполнить бекап базы - полный или инкрементный. В первом случае для восстановления базы используется предыдущий бекап плюс накат журнала, во втором - предыдущий бекап плюс повтор перестроения индексов либо просто бекап после перестроения индексов. Второй вариант многие администраторы выбирают по причине его более быстрой работы - бекап выполняется оптимизированно, поблочно, а перестроение индексных записей - позаписно, поэтому операции с бекапом могут быть более эффективны чем операции с журналом.

Программно для массового перестроения индексов предпочтительно иметь специальную утилиту, которую можно вызвать из других утилит для составления простого средства управления сложной системой.

Поскольку при массовом перестроении индексов индексные структуры не соответствуют данным, выполнение операций перестроения для проектируемой системы может быть специальной операцией, выполняемой регламентно, в период неактивности пользователей. Иначе для работы системы во время перестроения индексов разработчикам придется реализовать временные алгоритмы поиска не по индексам, а по самим данным.

Подробнее о книге "MUMPS СУБД"