Оптимізація реструктуризації бази даних

Ця стаття є анонсом нової функціональності.
Не рекомендується використовувати зміст цієї статті для освоєння нової функціональності.
Повний опис нової функціональності буде наведено у документації до відповідної версії.
Повний список змін у новій версії наведено у файлі v8Update.htm.

Ми розробили новий механізм реструктуризації бази даних, який дозволяє прискорити оновлення конфігурації в середньому в 3-4 рази, а в окремих випадках на порядок. Прискорення досягається рахунок мінімізації маніпуляцій над даними і максимального їхнього перенесення рівень системи управління базою даних (СУБД).

Що таке реструктуризація?

Реструктуризація це зміна структури та складу таблиць бази даних, і перенесення наявних даних у змінені таблиці. Зазвичай реструктуризація виконується в той момент, коли ви натискаєте Оновити конфігурацію бази даних у Конфігураторі. Але виконується вона щоразу.

Реструктуризація виконується тоді, коли зміни конфігурації вимагають появи нових колонок чи таблиць у базі, або коли змінюється тип існуючої колонки. Наприклад, ви додали реквізит до довідника, додали документ, або змінили тип наявного реквізиту з Число на Рядок. У таких випадках буде потрібно реструктуризація.

Якщо розглядати реструктуризацію з погляду маніпулювання даними, існує база даних і схема даних, що відповідає конфігурації бази даних. Після того, як ви оновлюєте конфігурацію бази даних, створюються нові структури даних, які переносяться старі дані.

«Традиційна» реструктуризація

У процесі реструктуризації послідовно аналізуються об'єкти конфігурації. Не заглиблюючись у подробиці можна сказати, що для кожного об'єкта виконується:

• Аналіз його змін;
  
• створення нових таблиць у базі даних, які відповідають новій структурі об'єкта;
  
• Перенесення даних.
  

З цих трьох кроків перенесення даних займає найбільшу кількість часу. При цьому самі операції перенесення даних можуть бути простими та складними.

Наприклад, до простих і швидких операцій належать ті, що викликані додаванням або видаленням стовпців таблиці. У цьому випадку окремим запитом створюється нова таблиця (зі зміненою структурою) і дані переносяться до неї.

Всі інші операції складні, можуть займати тривалий час, і для їх виконання потрібна участь Конфігуратора (або серверної частини платформи, якщо оновлення виконується на сервері). Тому що процес перенесення даних може супроводжуватись різними допоміжними діями, зумовленими специфікою 1С:Підприємства.

Наприклад, може знадобитися видалення посилань на неіснуючі об'єкти, зміна визначених даних, попередня фільтрація даних (для видалення рухів, що відповідають реєстраторам, що видаляються), перевірка унікальності номерів і кодів, перевірка кількості рівнів вкладеності довідника і коректності його ієрархії, та інші.

Новий механізм реструктуризації

Головна зміна полягає в тому, що оптимізація реструктуризації досягнута не рахунок локальних змін «традиційного» механізму, а рахунок створення повністю нового механізму реструктуризації.

Це непросте і трудомістке завдання, тому що механізм реструктуризації повинен забезпечувати транзакційність змін, тобто надійність та цілісність бази даних у всіх випадках. Механізм має бути готовим до того, що процес реструктуризації може перерватися будь-якої миті (в результаті збою, наприклад), і при цьому система повинна залишитися в консистентному стані. Тобто або у вигляді старої версії або у вигляді нової версії. Старий механізм для цього створював нові версії змінених таблиць та заповнював їх. А потім підміняв усі старі версії на нові.

Новий механізм теж забезпечує транзакційність, але складнішим способом.

Крім цього, новий механізм заснований на ряді ідей, які дозволили отримати значне прискорення:

• Максимальна кількість операцій делегується на рівень СУБД, тому що це найбільш близька до даних частина, і вона має більші можливості зміни даних.
  
• Обробляються ті таблиці СУБД, у яких зміни конфігурації можуть викликати зміна даних. У «традиційному» механізмі це було завжди так. Наприклад, при зміні реквізиту табличної частини документа копіювалися дані основної таблиці, і всіх табличних частин документа.
  
• Таблічні частини реструктуруються окремо. При цьому можлива окрема «пореквізитна» їх зміна. Наприклад, якщо ви додали реквізит до табличної частини, до таблиці просто додається новий стовпець, без модифікації основної таблиці.
  

На основі цих ідей ми досягли максимальної оптимізації тих змін конфігурації, які призводять до наступних операцій з даними:

• Додавання чи видалення стовпців таблиць.Ці операції проводяться тепер на поточних таблицях (раніше створювалися нові таблиці і їх переносилися дані). Необхідність додавання або видалення стовпців виникає, наприклад, при додаванні або видаленні реквізитів, зміні деяких властивостей об'єкта конфігурації (ієрархія довідника і стовпець _ParentID) та ін.
  
• Додавання чи видалення індексів. Просто створюється новий індекс, без створення нових таблиць та перенесення даних. Ці операції виконуються, якщо ви встановили індексування у реквізиту, наприклад.
  
• Зміна існуючих індексів. Також виконується без створення таблиць та перенесення даних. Наприклад, кластерний індекс регістра відомостей змінюється тоді, коли ви додаєте вимір.
  

В інших операціях перенесення даних потрібно як і раніше, але практично завжди (здебільшого операцій) він здійснюється на рівні СУБД. Дані переносяться єдиним запитом. Це може бути INSERT для нових таблиць або UPDATE існуючих таблиць.

Звичайно, існують такі зміни, які все одно проходять обробку на сервері з розвантаженням даних рядково. Наприклад, перетворення рядка на число, або в дату. Такі операції недоцільно робити лише на рівні СУБД, причому вони досить рідко зустрічаються. Але найчастіші зміни проводяться на рівні СУБД, одним запитом однією таблицю.

У середньому прискорення сягає 4 разів. Це звичайно залежить від конкретної конфігурації, від конкретних змін, і навіть конкретних даних. В окремих випадках прискорення може бути до 20 разів. Таке можливо, наприклад, при видаленні реквізиту у великій таблиці, або якщо зміни зачіпають маленькі таблиці, але сам об'єкт є досить великим.

Крім прискорення, є й інший позитивний момент.У багатьох випадках не розбудовуються індекси. Це дозволяє зберегти їхню актуальність, зберегти статистику, скоротити місце, необхідне для реструктуризації.

Ми провели кілька порівняльних експериментів на реальних інформаційних базах і отримали такі результати:

• Додавання реквізитів до документів та вимірювань до регістрів відомостей. База 400 Гб. Новий механізм дозволяє прискорити реструктуризацію з 2:00 до 15 хвилин.
  
• Зміна режиму сумісності з 8.2.19 на 8.3.6. База 6 Тб. Прискорення з 5 до 12 годин.

Особливості поточної реалізації

Новий механізм реструктуризації ми плануємо включити до версії 8.3.11 у статусі бета. Він реалізований лише на сервері, причому на сервері має бути встановлена ​​Java 8.

Щоб використовувати новий механізм реструктуризації, можна запустити Конфігуратор у пакетному режимі. Крім цього, у файлі conf.cfg ви також можете вказати необхідність використання нового механізму. Тоді нова реструктуризація виконуватиметься при натисканні Конфігурація – Конфігурація бази даних – Оновити конфігурацію бази даних на сервері. Якщо ніяких спеціальних дій не робити (просто встановити нову платформу), стандартно буде використовуватися старий механізм.

Поки що підтримуються лише дві СУБД: MS SQL Server і PostgreSQL.

На даний момент ми оптимізували реструктуризацію не всіх об'єктів конфігурації, а лише основних:

• Планів обміну,
  
• Довідників,
  
• документів,
  
• Журналів документів,
  
• Планів видів характеристик,
  
• Планів рахунків,
  
• Реєстрів відомостей,
  
• Реєстрів накопичення,
  
• Реєстр бухгалтерії.
  

Для перерахованих об'єктів (крім регістрів) оптимізовано будь-які зміни.Для регістрів ми оптимізували реструктуризацію рухів та реструктуризацію таблиць реєстрації змін. Операції перерахунку підсумків та перерахунку зрізів для регістру відомостей ми поки що не оптимізували. Однак, незважаючи на це, використання нового механізму вже дає суттєве прискорення всього оновлення регістрів загалом.

Ми розглядаємо можливість збільшення охоплення операцій та розширення складу об'єктів конфігурації, реструктуризація яких оптимізована у новому механізмі.