Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Мы разработали новый механизм реструктуризации базы данных, который позволяет ускорить обновление конфигурации в среднем в 3-4 раза, а в отдельных случаях на порядки. Ускорение достигается за счёт минимизации манипуляций над данными и максимального их переноса на уровень системы управления базой данных (СУБД).
Реструктуризация это изменение структуры и состава таблиц базы данных, и перенос имеющихся данных в изменённые таблицы. Обычно реструктуризация выполняется в тот момент, когда вы нажимаете Обновить конфигурацию базы данных в Конфигураторе. Но выполняется она не каждый раз.
Реструктуризация выполняется тогда, когда изменения конфигурации требуют появления новых колонок или таблиц в базе, или когда меняется тип существующей колонки. Например, вы добавили реквизит к справочнику, добавили документ, или изменили тип имеющегося реквизита с Число на Строка. В этих случаях потребуется реструктуризация.
Если рассматривать реструктуризацию с точки зрения манипулирования данными, то существует база данных и схема данных, которая соответствует конфигурации базы данных. После того, как вы обновляете конфигурацию базы данных, создаются новые структуры данных, в которые переносятся старые данные.
В процессе реструктуризации последовательно анализируются все объекты конфигурации. Не углубляясь в подробности можно сказать, что для каждого объекта выполняется:
Из этих трёх шагов перенос данных занимает наибольшее количество времени. При этом сами операции переноса данных могут быть простыми и сложными.
Например, к простым и быстрым операциям относятся те, которые вызваны добавлением или удалением столбцов таблицы. В этом случае отдельным запросом создаётся новая таблица (с изменённой структурой) и данные переносятся в неё.
Все остальные операции являются сложными, могут занимать длительное время, и для их выполнения требуется участие Конфигуратора (или серверной части платформы, если обновление выполняется на сервере). Потому что процесс переноса данных может сопровождаться различными вспомогательными действиями, обусловленными спецификой 1С:Предприятия.
Например, может потребоваться удаление ссылок на несуществующие объекты, изменение предопределённых данных, предварительная фильтрация данных (для удаления движений, соответствующих удаляемым регистраторам), проверка уникальности номеров и кодов, проверка количества уровней вложенности справочника и корректности его иерархии, и другие.
Главное изменение заключается в том, что оптимизация реструктуризации достигнута не за счёт локальных изменений «традиционного» механизма, а за счёт создания полностью нового механизма реструктуризации.
Это непростая и трудоёмкая задача, потому что механизм реструктуризации должен обеспечивать транзакционность изменений, то есть надежность и целостность базы данных во всех случаях. Механизм должен быть готов к тому, что процесс реструктуризации может прерваться в любой момент (в результате сбоя, например), и при этом система должна остаться в консистентном состоянии. То есть либо в виде старой версии, либо в виде новой версии. Старый механизм для этого создавал новые версии изменённых таблиц, и заполнял их. А потом подменял все старые версии на новые.
Новый механизм тоже обеспечивает транзакционность, но более сложным способом.
Кроме этого новый механизм основан на ряде идей, которые позволили получить значительное ускорение:
На основе этих идей мы достигли максимальной оптимизации на тех изменениях конфигурации, которые приводят к следующим операциям с данными:
В других операциях перенос данных требуется как и раньше, но практически всегда (в большей части операций) он осуществляется на уровне СУБД. Данные переносятся единым запросом. Это может быть INSERT для новых таблиц, или UPDATE существующих таблиц.
Конечно, существуют такие изменения, которые всё равно проходят обработку на сервере с выгрузкой данных построчно. Например, преобразование строки в число, или в дату. Такие операции нецелесообразно делать на уровне СУБД, к тому же они довольно редко встречаются. Но наиболее частые изменения проводятся всё же на уровне СУБД, одним запросом на одну таблицу.
Результаты
В среднем ускорение достигает 4 раз. Это, конечно, зависит от конкретной конфигурации, от конкретных изменений, и даже конкретных данных. В отдельных случаях ускорение может быть до 20 раз. Такое возможно, например, при удалении реквизита в большой таблице, или если изменения затрагивают маленькие таблицы, но сам объект при этом является довольно большим.
Помимо ускорения есть и другой положительный момент. Во многих случаях не перестраиваются индексы. Это позволяет сохранить их актуальность, сохранить статистику, сократить место, требуемое для реструктуризации.
Мы провели несколько сравнительных экспериментов на реальных информационных базах, и получили следующие результаты:
Новый механизм реструктуризации мы планируем включить в версию 8.3.11 в статусе бета. Он реализован только на сервере, причём на сервере должна быть установлена Java 8.
Чтобы использовать новый механизм реструктуризации, вы можете запустить Конфигуратор в пакетном режиме. Кроме этого в файле conf.cfg вы также можете указать необходимость использования нового механизма. Тогда новая реструктуризация будет выполняться при нажатии Конфигурация – Конфигурация базы данных – Обновить конфигурацию базы данных на сервере. Если никаких специальных действий не предпринимать (просто установить новую платформу), то стандартно будет использоваться старый механизм.
Пока поддерживаются только две СУБД: MS SQL Server и PostgreSQL.
На текущий момент мы оптимизировали реструктуризацию не всех объектов конфигурации, а только основных:
Для перечисленных объектов (кроме регистров) оптимизированы любые их изменения. Для регистров мы оптимизировали реструктуризацию движений и реструктуризацию таблиц регистрации изменений. Операции пересчёта итогов и пересчёта срезов для регистра сведений мы пока не оптимизировали. Однако, несмотря на это, использование нового механизма уже даёт существенное ускорение всего обновления регистров в целом.
Мы рассматриваем возможность увеличения охвата операций и расширения состава объектов конфигурации, реструктуризация которых оптимизирована в новом механизме.
