Реструктуризация — бесконечная история

Делай сразу хорошо – плохо само получится.
Виды реструктуризации на текущий момент.
Динамическая
Обычный механизм реструктуризации
Оптимизированный механизм реструктуризации.
Не надо прогибаться под изменчивый мир? Хотели как лучше, а получилось
Сколько длится конвертация базы 1C на 8.2 в 8.3 на 5 терабайтах?
Большой архитектурный просчет 1С или Как жить на 1С с базой больше 5 терабайт?
Осторожно двери закрываются.

Делай сразу хорошо – плохо само получится

В современном мире модно что‑то постоянно менять — потому что:

Новые формы налоговой отчетности повысят контроль и «собираемость налогов».
Новые требования бизнеса повысят «прибыль и капитализацию в будущем»
Нужно быстро доделать проект, который начала другая команда.
Аудиторам нужна другая отчетность, а не как в прошлом году.
И вообще «5 лет ездить на одной машине, а пользоваться телефоном 2 года» — моветон.

Я думаю каждый может накидать примеров, но их объединяет одно — через год это из «важно и срочно» перейдет в готовность Х% и категорию «важно, но не срочно», потому что … будут новые изменения. А далее судьба задачи зависит от запятой в «закрыть нельзя закончить» и общей корпоративной культуры.

Вроде в результате эволюции должны выживать проверенные решения и Best practice, но «давайте сделаем это по‑быстрому, а потом оптимизируем» приводит лишь к выживанию того, что мы называем Legacy. Legacy становится фундаментом к которому привязывают разные другие системы, процессы и поменять его еще та задача.

Зато плодятся средства разработки функционала, генераторы кода, целые отделы DevOps, автотесты — все, для того чтобы успеть реализовать функционал, пока он не потерял актуальность. И чем более гибко система адаптируется к изменениям, тем меньше бизнес советуется с ИТ. Зачем? Успели в прошлый раз успеют и в этот, все что не успеют дожмем через agile и бонус дадим.

За agile software development и бонусами теряется вопрос проработки архитектуры. Он как бы там есть, но всем мешает agile teaches us the true meaning of architecture потому что

“Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.”

В итоге в гонке за ~~лидером~~ морковкой, побеждает компромисс, который успешно догоняет всех уже через 5 — 10 лет, а иногда после выплаты бонусов. Довольно общих слов — посмотрим, как это выглядит на практике в ПО с жизненным циклом более 10 лет — платформе 1С. Да здесь изложено именно про платформу, а не конфигурации на ней. Платформа Платформа (1c.ru) это как движок для игр, в которые играют люди. Игры могут быть разных жанров, а движок\фундамент один ‑поэтому ответственность архитектора гораздо выше.

Виды реструктуризации на текущий момент

1С представляет собой ORM систему, где добавление реквизита в объект метаданных через конфигуратор платформа обрабатывает сама. т. е. определяет\создает таблицы, в которые нужно добавить колонки, дополнительные поля индексов и многое другое. Реквизит можно сделать составным типом (например ссылка, строка, число), и даже сменить тип — платформа все сконвертирует сама.

С точки зрения разработчика 1С все реализовано красиво и относительно надежно, можно вообще не думать, что творится внутри СУБД при реструктуризации. Все визуально, даже формы, которые сохраняют и читают реквизит не потребуют написания кода — просто положи реквизит на форму. Видно, что архитектуру функционала быстрой разработки в этой части хорошо прорабатывали. Функционал разработчика и конструктор интерфейса получились красивыми, гибкими и доступными. Мне даже трудно это с чем то сравнить, например, SAP в этой части и рядом не стоял, хотя денег у него больше

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

1С предлагает три вида реструктуризации\обновления.

Динамическая

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

Вот так выглядит динамическое обновление

Плюсы понятны — например можно оперативно исправить собственную ошибку, которая прорвалась через DevOps без остановки работы всех пользователей.

Минус только один — код у клиента не подгрузится пока он не зайдет в 1С заново

Динамическая реструктуризация рекомендуется опытным убившим этим хотя бы одну базу данным процессом. Иначе говоря — не рекомендуется, ведь если поменять что‑то кроме кода (например добавить параметр сеанса либо изменить роль ) базу можно сделать неработоспособной в зависимости от релиза. Ее конечно можно восстановить методами Динамическое обновление — это зло? (infostart.ru), но лучше восстановить бэкап, который НЕ забыли сделать, чтобы не замедлять работу пользователей. В документации об этом режиме написано довольно кратко Глава 2. Работа с конфигурацией:: Руководство разработчика:: 1С:Предприятие 8.3.23. Документация (1c.ru) , да и что тут писать — Вы сами можете придумать ситуацию, когда подмена кода на ходу даст интересный эффект. У одного пользователя работает старый код, у другого новый и если они пишут в базу эффект будет удивительным.

Обычный механизм реструктуризации

Если Вы верны традиционным ценностям — стабильность, надежность, предсказуемость и т. д.

Вы можете использовать «Обычный механизм» который требует не только завершить работу всех пользователей, но и

«В данном режиме реструктуризация всегда выполняется через создание копии каждой изменяемой таблицы с последующим преобразованием каждой строки данных в конфигураторе или на стороне сервере (в зависимости от настроек выполнения реструктуризации).»

Раньше он был надежным настолько, что делал все в одной транзакции судя по раздуванию Transaction log, что со временем начинало бесить и раздражать. Ведь администратор СУБД знает что можно это делать по другому, а не плюс 200% дополнительного пространства на диске. Сейчас по наблюдениям с длинной транзакции стало лучше, но принцип остался прежним.

Поэтому для тех, кто любит погорячее в 1С придумали.

Оптимизированный механизм реструктуризации

Как пишет 1С:

«В данном режиме происходит попытка выполнить максимальное количество действий на стороне СУБД, а также выполнить модификацию существующих данных и индексов вместо создания копии и переноса данных с обработкой. В данном режиме большинство действий выполняется на стороне сервера системы „1С:Предприятие“.

Иными словами использовать Alter table и подобные операции.

Несмотря на то что он появился в 2017 году, использует Java, а способ его активации скрыт в conf.cfg за следующими заклинаниями и не выведен в интерфейс:

ConfLocation=C:\Program Files\1cv8\conf

UpdateDBCfg=v2

JavaHome=C:\Program Files\Java\jre1.8.0_191

#Задание максимального размера доступной памяти для JAVA-процесса

JavaOpts=-Xmx3072m

Работа оптимизированного механизма реструктуризации

И это не зря — свежие ошибки https://bugboard.v8.1c.ru/error/000 134 532, которые не дают провести реструктуризацию исправили только в 8.3.22.1750 релизе. И такой подход к эксплуатации намекает, что в широкие массы выводить это пока страшно.

Ключевой момент в том, что фундаментально он не решает проблему с реструктуризацией больших объемов. Ведь при смене релиза с 8.2 на 8.3 недостаточно просто добавить колонки, еще идет обработка информации под новую структуру данных (заполнение колонок значениями), практически по всем типам метаданных. И эта часть не оптимизирована

Получился в итоге компромиссный вариант Оптимизация реструктуризации базы данных | 1С:Зазеркалье (1c.ru) , и самое грустное, что не очень надежный.

Игры с типом реквизита или составными типами, также лишают данный механизм преимуществ ведь это тоже уже обработка существующей информации.

В релизе 8.3.23.1739 на определенных операциях в этом механизме видно непопадание в индексы 1С с понятными последствиями.

Оптимизированный механиз реструктуризации еще нужно оптимизировать :)

Не надо прогибаться под изменчивый мир? Хотели как лучше, а получилось…

Как видно в 1С были благие намерения — дать разработчику с помощью визуального ORM делать любые виды реструктуризации просто и надежно. Иными словами — красивый функционал. Но не учли главное — когда объект метаданных близок к терабайту со своими индексами, тут работают уже другие принципы.

Простое добавление колонки с индексом, приведет к блокировкам таблицы на уровне СУБД, а постобработки данных таблицы (даже без копирования ) без распараллеливания будут идти очень долго.

В итоге красивый функционал, на большом объеме данных уже живет не красиво. Добавим еще данных, и он будет просто не нужен.

Знакомая ситуация? Когда функционал это главное?

И на это у 1С есть ответ с множеством компромиссов и ограничений Глава 2. Работа с конфигурацией:: Фоновое обновление конфигурации базы данных:: 1С:Предприятие 8.3.23. Документация (1c.ru)

Я не буду в него углубляться, потому что это очередная попытка решить проблему роста данных без фундаментального изменения архитектуры хранения данных в 1С.

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

При росте объемов данных.
При росте объемов вычислений.
При маштабировании на узлы.
При работе в нештатной ситуации.
Переносимость на разные архитектуры и далее по Вашему списку.

Проработка уже этих вопросов сильно поменяет концепцию функционала. Например, стоит наложить ограничения и отказаться от смены типа реквизита (число \ строка) на уровне платформы 1С и Вы уже можете упростить архитектуру реструктуризации кардинально. Тем более на больших объемах это работать не будет, всегда есть другие варианты.

Про архитектуру порой так сложно и абстрактно пишут Architectural pattern — Wikipedia, что ее проработка видится где‑то в крупных компаниях, с технадзором, реестром отечественного ПО и прочей мотивацией, где есть кого и за что посадить. При этом чтение Patterns и AntiPatterns не приводит к пониманию Best Practice, потому что это не математика, где все можно привести к строгой структуре.

Это как по скелету решать — волк это будет или собака? Вроде почти одно и тоже, но один человеку друг, а другой и не друг и не враг, а так.

На самом деле достаточно начать с ~~себя~~.

Перечня открытых вопросов \ разрезов для анализа — перечень которых индивидуален для каждого приложения, но они определяют какой должна БЫТЬ программа в разных обстоятельствах,и где нужно заложить задел на маштабирование.

Если взять управление данными при росте объемов в 1С, можно накидать следующее:

Максимальные объемы (лимиты) с возможностью обслуживания штатными средствами 1C (переиндексация, удаление помеченных объектов сейчас укладываются за сутки только на сравнительно небольших базах).
Маштабирование при росте объемов данных (текущее состояние такое Язык мой враг мой).
Удаление архивных данных (текущее состояние такое 1С БодиПозитив / Хабр (habr.com)).
Обмен данными между приложениями. (текущий механизм планов обмена работает без распараллеливания).
Изменение структуры таблиц, реструктуризация.
Универсальность и специфика взаимодействия с различными СУБД. Сейчас 1С поддерживает Postgres, MS SQL, Oracle но жизнь уже требует другие варианты.

Как задать правильные вопросы?

Просто надо сместить фокус от того, как СДЕЛАТЬ нужный функционал, и перевести внимание на вопросы более высокого уровня общие для данного класса программ. Например, обработка ошибок должна быть в любой программе, и там много вариантов логгирования, режимов трассировки, отладки (особенно в режиме параллельной обработки данных через фоновые задания)

Решение этих вопросов нужно заложить еще в начале проектирования. Необязательно все это реализовывать сразу, но в архитектуре это уже должно быть заложено как закладывается в кузове авто возможность поставить более\менее мощный двигатель, полный привод или трансформация багажника. Наберите «платформа MQB» и Вы поймете о чем речь Volkswagen Group MQB — Википедия (wikipedia.org)

Чем оканчивается создание функционала, и откладывания на потом решения этих открытых вопросов ‑можно увидеть в 1С на подсистеме реструктуризации. Хотя конец тут это только начало. Подобные проблемы есть повсеместно и у других производителей ПО, по причинам указанным выше, и это не какие‑то in‑house самоделки, а вполне коммерческие продукты типа SAP.

Сколько длится конвертация базы 1C на 8.2 в 8.3 на 5 терабайтах?

С конвертацией конфигурации 1С с 8.2 в 8.3 без режима совместимости с 8.2 все столкнутся рано или поздно. И эта реструктуризация отличается от обычных изменений\добавлений метаданных — тотальным влиянием почти по всем метаданным 1С. То есть ее нельзя разделить на части.

Формально отличия для программиста 1С 8.2 против 8.3 укладываются в небольшую статью на ИТС Перевод конфигураций на платформу «1С:Предприятие 8.3» без режима совместимости с версией 8.2:: Платформа, механизмы и технологии:: Методическая поддержка для разработчиков и администраторов 1С:Предприятия 8 (1c.ru) .

Конечно в кластере серверов 8.3 много переработали в части администрирования и маштабирования, но это не отвечает на вопрос: Почему нельзя было сделать обратную совместимость на уровне языка 8.3?

Внутренняя структура хранения на уровне полей, при конвертации 8.2 в 8.3, меняется существенно, это нормально для данной идеологии ORM. Есть хорошие статьи Размещение данных 1С:Предприятия. Таблицы и поля:: Администраторам:: Методическая поддержка для разработчиков и администраторов 1С:Предприятия 8 (1c.ru) . К сожалению, новые поля почему‑то не документированы, например в основной таблицы регистра бухгалтерии _AccRg.

8_2 [dbo].[_AccRg640](

8_3 [dbo].[_AccRg640](

[_Period] [datetime] NOT NULL,

[_Period] [datetime2](0) NOT NULL,

[_RecorderTRef] [binary](4) NOT NULL,

[_RecorderRRef] [binary](16) NOT NULL,

[_LineNo] [numeric](9, 0) NOT NULL,

[_Active] [binary](1) NOT NULL,

[_AccountDtRRef] [binary](16) NOT NULL,

[_AccountCtRRef] [binary](16) NOT NULL,

[_Fld17280RRef] [binary](16) NOT NULL,

[_Fld641RRef] [binary](16) NOT NULL,

[_Fld642DtRRef] [binary](16) NULL,

[_Fld642CtRRef] [binary](16) NULL,

[_Fld643DtRRef] [binary](16) NULL,

[_Fld643CtRRef] [binary](16) NULL,

[_Fld644] [numeric](15, 2) NOT NULL,

[_Fld645Dt] [numeric](15, 2) NULL,

[_Fld645Ct] [numeric](15, 2) NULL,

[_Fld646Dt] [numeric](20, 5) NULL,

[_Fld646Ct] [numeric](20, 5) NULL,

[_Fld647Dt] [numeric](15, 2) NULL,

[_Fld647Ct] [numeric](15, 2) NULL,

[_Fld648Dt] [numeric](15, 2) NULL,

[_Fld648Ct] [numeric](15, 2) NULL,

[_Fld649Dt] [numeric](15, 2) NULL,

[_Fld649Ct] [numeric](15, 2) NULL,

[_Fld17281] [numeric](15, 2) NOT NULL,

[_Fld650] [nvarchar](150) NOT NULL,

[_Fld651] [binary](1) NOT NULL,

[_Fld16846_TYPE] [binary](1) NOT NULL,

[_Fld16846_RTRef] [binary](4) NOT NULL,

[_Fld16846_RRRef] [binary](16) NOT NULL,

[_Fld17027] [numeric](20, 0) NOT NULL,

[_Fld628] [numeric](7, 0) NOT NULL,

[_ValueDt1_TYPE] [binary](1) NULL,

[_ValueDt1_RTRef] [binary](4) NULL,

[_ValueDt1_RRRef] [binary](16) NULL,

[_KindDt1RRef] [binary](16) NULL,

[_ValueCt1_TYPE] [binary](1) NULL,

[_ValueCt1_RTRef] [binary](4) NULL,

[_ValueCt1_RRRef] [binary](16) NULL,

[_KindCt1RRef] [binary](16) NULL,

[_ValueDt2_TYPE] [binary](1) NULL,

[_ValueDt2_RTRef] [binary](4) NULL,

[_ValueDt2_RRRef] [binary](16) NULL,

[_KindDt2RRef] [binary](16) NULL,

[_ValueCt2_TYPE] [binary](1) NULL,

[_ValueCt2_RTRef] [binary](4) NULL,

[_ValueCt2_RRRef] [binary](16) NULL,

[_KindCt2RRef] [binary](16) NULL,

[_ValueDt3_TYPE] [binary](1) NULL,

[_ValueDt3_RTRef] [binary](4) NULL,

[_ValueDt3_RRRef] [binary](16) NULL,

[_KindDt3RRef] [binary](16) NULL,

[_ValueCt3_TYPE] [binary](1) NULL,

[_ValueCt3_RTRef] [binary](4) NULL,

[_ValueCt3_RRRef] [binary](16) NULL,

[_KindCt3RRef] [binary](16) NULL,

[_EDHashDt] [numeric](10, 0) NOT NULL,

[_EDHashCt] [numeric](10, 0) NOT NULL

Перечислять, что меняет 1С внутри при конвертации в 8.3 нет смысла — Вы можете увидеть это при пробной конвертации через СУБД, просто отобрав таблицы с суффиксом NG NO(временное название новой таблицы при реструктуризации).

Важно другое — сейчас нет готовых инструментов, которые могут сделать реструктуризацию базы 1C большого объема 2–5 терабайт за разумное время.

По сути способа три:

Создать новую базу в формате 1с 8.3 и перенести туда данные, например, планами обмена. Проблема этого способа — нет готовых инструментов БСП для параллельной!!! загрузки данных, хотя бы из большого регистра сведений.
Обычная Реструктуризация — средствами 8.3. Проблема этого способа в том, что на базе 5 терабайт он занимает 6 дней, на базе 2 терабайта 2–3 дня . Оптимизированным режимом мне до конца довести это не удалось из — за ошибок (смотрите выше). В любом случае это не влезет в технологические окна, кроме новогодних праздников в некоторых компаниях.
Свернуть базу до разумных размеров и использовать типовой способ реструктуризации. Но свертка это нестандартный процесс 1С БодиПозитив.

Любой другой способ подразумевает решение собственной разработки из комбинации разных способов, а мы не этого мы ожидаем от платформы.

Как подготовить конфигурацию к реструктуризации? это тема отдельной статьи. Если у Вас бухгалтерия 3.0 это просто, если Бухгалтерия 2.0 уже все сложнее. Все зависит от библиотеки стандартных подсистем, переход на в 8.3 перешел в версии 2.2 Редакция 2.2 БСП (1c.ru)

Причина длительной реструктуризации простая — каждый объект метаданных в 1С обрабатывается при реструктуризации отдельно без распараллеливания операций. Например реструктуризация большого регистра будет идти перекладкой по 1000 записей в таблицу _infoRgNG последовательно. Посмотрите на этот Top таблиц и вы поймете, что все это вытянется в бесконечность.

У кого-то такие объемы обычное дело за пару лет

Метаданные по типам тоже реструктуризируются последовательно Справочники, Документы, Регистры. Это оправданно, поскольку важна ссылочная целостность, но мы понимаем, что Регистры друг на друга не ссылаются (это не ссылочный тип) и их можно реструктуризировать параллельно (разные регистры). А для больших регистров параллельная обработка данных просто необходима, иначе ожидание будет пропорционально размеру самого большого

В таких обстоятельствах можно только сделать следующие подготовительные действия.

Подготовить базу \ оборудование так же как описано в статье Как великану в стране 1С пересесть на слона , включая очистку итогов (чтобы не тратить двойное время на конвертацию и пересчет). К этому можно добавить только два пункта:

Если Вы использовали разумное разделение по File group (ms sql) \ Table spaces (Oracle), то 1С все это проигнорирует и новые таблицы с суффиксом NG таблицы создаст в пространстве по умолчанию (Primary). Как следствие понадобится двойное дисковое пространство и терабайтные файлы операционной системы, с которыми трудно работать. Это общая проблема для любой реструктуризации 1С. Выхода два либо искать еще дополнительно 5ТБ либо сделать перемещение таблиц в Primary с нужными размерами файлов заранее средствами СУБД.
Так же можно сэкономить место удалив часть индексов (почти половина размера базы), которые не используются при реструктуризации, но восстанавливаются. Это можно делать только если Вы знаете, что индекс не используется и восстановится после реструктуризации, в противном случае будет замедление реструктуризации и работа системы впоследствии, без нужных индексов. Например, если регистр сведений имеет поле _SimpleKey, то у него можно оставить кластерный индекс и индекс по _SimpleKey — этот регистр система пересоздаст и остальные индексы тоже. Не очевидное условие? Поэтому нужно понимать, что делаете. Иногда проще найти удвоенное дисковое пространство для конвертации, чем делать такое.

Обладая данными знаниями, можно прийти к заключению, что свертка базы перед реструктуризацией — это самый оптимальный способ, поскольку:

А) Процедуру свертки можно использовать ежегодно и держать базу в форме. Ваши усилия не будут потрачены на одноразовую операцию.

Б) Вы сразу решаете проблемы с временем реструктуризации и впишетесь в технологические окна.

В) Сократите накладные расходы на содержание базы в будущем.

Вкладывайтесь в свои решения свертки и будет Вам счастье. Пример как это можно делать оптимально 1С БодиПозитив.

Источник: https://habr.com/ru/articles/762574/