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

29.09.23

Разработка - Рефакторинг и качество кода

При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при масштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3, складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».
  • Делай сразу хорошо – плохо само получится.
  • Виды реструктуризации на текущий момент.
    • Динамическая
    • Обычный механизм реструктуризации
    • Оптимизированный механизм реструктуризации
  • Не надо  прогибаться под изменчивый мир? Хотели как лучше, а получилось…
  • Сколько длится конвертация базы 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/000134532 , которые не дают провести реструктуризацию исправили только в 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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[_Fld642DtRRef] [binary](16) NULL,

[_Fld642DtRRef] [binary](16) NULL,

[_Fld642CtRRef] [binary](16) NULL,

[_Fld642CtRRef] [binary](16) NULL,

[_Fld643DtRRef] [binary](16) NULL,

[_Fld643DtRRef] [binary](16) NULL,

[_Fld643CtRRef] [binary](16) NULL,

[_Fld643CtRRef] [binary](16) NULL,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[_Fld628] [numeric](7, 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,

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

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

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

 

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

 

 

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

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

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

 

Большой архитектурный просчет 1С или Как жить на 1С с базой больше 5 терабайт?

Выше был озвучен перечень «открытых вопросов \ разрезов для анализа » которые нужно было рассмотреть при проектировании платформы 1С, и как то предусмотреть в архитектуре.

На текущий момент имеем:

  • Маштабирование при росте объемов: Маштабирование 1С понимает по другому, дистанцируясь от СУБД – достаточно почитать Масштабируемость (1c.ru) . Как работать с большими таблицами в 1С без сторонних средств – вопрос открытый. А ведь по сути 1С это генератор запросов для СУБД, и при его использовании нужно понимать последствия для СУБД Концепция ORM Как двигатель прогресса - выдержит ли ее Ваша СУБД .
  • Удаление архивных данных : Обработки в типовых конфигурациях не предназначены для больших объемов: ORM 1C не поддерживает на уровне СУБД ни партицирование, ни шардинг . Т.е. вы даже быстро удалить архивные данные не сможете, а про быстрый перенос извлечение из архива уже речи нет.
  • Реструктуризация структуры данных средствами 1С без партицирования и шардинга  на больших таблицах это неэффективный процесс, поскольку вы не можете параллелить его по партициям или шардам. Ниже будет видно, что даже поезд партицирования уже уходит, спасибо общим реквизитам с разделителями и в целом структуре таблиц Партицированная дисциплина программиста в 1С

 

Вы думаете, что это влияет только на смену версии платформы 8.2-8.3, которая происходит раз в 10 лет?

Напротив - эти архитектурные просчеты как тараканы лезут регулярную эксплуатацию. Все типовые конфигурации 1С, которые пишутся самой 1С  - выглядят как будто объем не имеет значения, ниже примеры:

  • Вы Не можете записать N документов\справочников\или других значений ссылочного типа одной операцией, поскольку метод .Записать() всегда работает на один объект. К чему это приводит видно тут Концепция ORM как двигатель прогресса – выявит слабое место Вашей СУБД  
  • Вы Не можете быстро почистить базу, потому что удаление тоже вызывается на каждый регистратор.
  • Вы Не можете записать наборы записей в регистры по нескольким регистраторам одной операцией, поскольку метод .Записать() работает только для одного регистратора . Обходные варианты есть, но это  антипаттерн Язык мой враг мой
  • Вы Не можете отследить судьбу фоновых заданий, потому что разработчики предусмотрели хранение истории только 1000 заданий. Когда Вам нужно обработать 1 миллион операций, фоновыми заданиями с пакетом по 1000 операций – вы уже исчерпаете лимит. Конечно, Вы можете доделать свою подсистему управления фоновыми заданиями, как и многое другое. У некоторых несколько миллионов в день это нормальный объем.
  • Вы Не можете быстро синхронизировать биржевые котировки , потому что они в типовом варианте планы обмена  1с обрабатывают загрузку последовательно. Обычно их 60 – 100 тысяч в день. Как следствие общую базу справочников (master data management) можно реализовать только на половину
  • При росте объемов запросы будут работать все медленней, потому что нужна Партицированная дисциплина программиста в 1С / Хабр (habr.com)
  • Из регистров – только оборотные РегистрыНакопления с агрегатами, архитектурно оптимизированы под параллельную запись в несколько потоков
  • Реализация метода .Записать() Compare by statements любому разработчику даст несколько идей на рефакторинг.

Это я все про штатные средства конечно, «нестандартными» средствами можно все сгладить, а пользователь за красивым интерфейсом (функционалом) будет счастлив в неведении

Когда в фундаменте что-то не предусмотрено возникают «оптимизации» - достаточно посмотреть на «оптимизированный» механизм реструктуризации, реструктуризацию в фоновом режиме. Это выглядит как «сушка» бодибилдера, который еще не успел создать рельеф. Мышцы мы увидим, но конкурс он так не выиграет. Оптимизация как правило вишенка на торте, а не способ исправить проблему.

В итоге все эти проблемы приходится решать комбинацией сторонних средств, особым написанием кода или на уровне СУБД, а не ORM 1C.

Иными словами – Вы не можете перейти на новую версию платформы штатными инструментами, когда база перешагнула 2 терабайта.

 

А ведь на момент создания платформы 1С 8.3 все инструменты для решения этих вопросов были. Минимум два варианта

  • Шардинг по периодам
  • Партицирование по периодам

Да партицирование в MS SQL появилось в MS SQL 2005 , но в Oracle оно было уже с Oracle 8i c 1998 года т.е. можно было еще с версии 1С 8.2 это заложить, а в 1С 8.3 развить и улучшить

Партицирование менее гибко чем шардинг, поскольку требует во всех индексах поле партицирования) иначе с партициями нельзя полноценно работать. Однако оно не требует дополнительных усилий со стороны программного кода – все берет на себя СУБД.  Возможности партицирования слишком зависят от СУБД, например , в MS SQL можно сделать truncate партиции, но нельзя ее просто «отстегнуть» в другую базу данных  с той же структурой таблиц.

Но даже при партицировании бонусом сразу получаем

  • Мгновенное удаление архивных данных через truncate
  • Возможность класть архивные данные на другие  диски (файлы) в рамках одного Instance СУБД
  • Возможность распараллеливания запросов по партициям на уровне СУБД
  • Обслуживание партиций – перестроение индексов отдельно по партициям

Это уже не мало. При шардинге гибкость возрастает еще больше, так как это больше концепция чем конкретная реализация от производителя СУБД.

Да в чем проблема на первый взгляд? Платформа предоставляет разработчику 1С язык программирования и ORM вообще независимый от СУБД (На текущий момент MS SQL, Oracle, IBM DB2 , Postgres) , переписать нужное под капотом и все дела.

Есть важный нюанс – если Вы разработали структуру данных, библиотеку процедур или ORM, запустили в ее продуктив, значит несколько поколений разработчиков уже будут их использовать. За десять лет их сменится 5 поколений, ведь работу рекомендуется менять каждый 2 года, во избежание «профессионального выгорания». За это время,  они создадут столько проверенного и работающего кода, что при любом «code review» в глазах будет двоится классика «Работает не трогай». Поэтому на очередной приоритезации задач выберут интеграцию с chatGPT нежели партицирование и шардинг.

 

Осторожно двери закрываются

Если Вы хотите что бы Ваше приложение жило по принципам эволюции, нужно сразу заложить благоприятную среду при проектировании. Как минимум определиться с жизненным циклом. Вы удивитесь реакции заказчика, когда скажете: «через пять лет можете удалить приложение вместе с данным, все-равно переписывать». Просто попробуйте.

Можете не говорить, но инволюция все сделает за Вас – медленно и верно выведет всех из зоны комфорта при работе. Через 4 года придет 3-е поколение разработчиков, им опять скажут, что сроки «уже вчера», но кто скажет им «сделайте хорошо и на века хотябы на 10-15 лет»?

Почему-то при строительстве мостов, сроки эксплуатации на десятки лет, это нормальная практика, а при создании программ нет. Хорошо, что ИТ становится все дороже и дороже, может хоть это заставит задуматься «спонсоров проекта». ИТ в этом отношении больше ведомые, чем ведущие поскольку тут главное уложится в «проектный треугольник» - трузатраты, ресурсы, длительность. Агитировать заказчика за хорошие решения программист\архитектор, может, если у него есть у самого чувство прекрасного, а пока это не обязательное требование. 

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

Будет жалко если все упрется в подсистемы под капотом, двери закрываются, но еще не поздно.

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

Однако PostgresPro дает шанс сделать шардинг , если 1С будет сотрудничать в этом направлении. На последней конференции для разработчиков ответ 1С был  духе «рассматриваем, но планов пока нет». А жизнь преподносит сюрпризы - Oracle, MS SQL, IBM становятся токсичными для платформы:

А) во первых на них уже никогда (лет 10) нельзя положиться в России, а на мировом рынке они легко могут тоже сделать с Китаем или другими странами

Б) Реализация шардинга хотябы для PostgresPro  заложит нужные архитектурные решения для других СУБД

Отличное время для перемен План разработок - прозрачный шардинг (postgrespro.ru)

Конечно, большинство думает, что последствия ошибок при проектировании финансового ПО не такие страшные как в Boeing 737 Max . В авиации уже на уровне регуляторов заложены обязательные процедуры, но они сильно напрягали менеджмент с предсказуемым результатом. Программа это нематериальный актив, поэтому есть иллюзия, что все можно поменять.

Вам не кажется, что хорошо спроектированная архитектура это больше психологический, чем технический вопрос?

Важно не то, что мы знаем, а то что не знаем. Даже самый опытный Full stack разработчик, проходит только один путь и глубоко понимает только малую часть ИТ ноосферы.  Однако к правильному решению можно  прийти, только задав правильные вопросы, просто представьте, что программа это не код, а живой организм. Хорошая архитектура позволяет долго жить без больших реструктуризаций. Это большая и интересная тема – до новых встреч на нашем  телеграмм канале. 

архитектура рефакторинг реструктуризация производительность

См. также

Рефакторинг и качество кода Программист Стажер Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Рассмотрим основные принципы шаблона проектирования "Стратегия" на простом примере.

25.06.2024    2620    MadRave    33    

22

Рефакторинг и качество кода Программист Платформа 1С v8.3 Абонемент ($m)

В статье расскажу и покажу процесс проведения Code-review на примере обработки с GitHub.

1 стартмани

04.06.2024    5074    mrXoxot    55    

40

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

Поделюсь своим опытом аудита кода авторских продуктов с Infostart.ru как одним из элементов применения DevOps-практик внутри Инфостарт. Будет настоящий код, боевые скриншоты, внутренние мемы от команды ИТ-лаборатории Инфостарт и прочее мясо – все, что любят разработчики.

10.04.2024    10885    artbear    84    

104

Рефакторинг и качество кода Программист Платформа 1С v8.3 Россия Бесплатно (free)

Предлагаю вашему вниманию советы мастеров древности. Программисты прошлого использовали их, чтобы заострить разум тех, кто после них будет поддерживать код. Гуру разработки при найме старательно ищут их применение в тестовых заданиях. Новички иногда используют их ещё лучше, чем матёрые ниндзя. Прочитайте их и решите, кто вы: ниндзя, новичок или, может быть, гуру? (Адаптация статьи "Ниндзя-код" из учебника JavaScript)

01.04.2024    3134    DrAku1a    15    

35

Рефакторинг и качество кода Программист Бесплатно (free)

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

01.04.2024    916    Prepod2003    6    

2

Рефакторинг и качество кода Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда понадобился новый оператор, но его нет в синтакс-помощнике, что делать?

18.03.2024    1687    ZhokhovM    5    

4

Рефакторинг и качество кода Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда разработчик платформы решил пойти на кухню за кофе, а проверку препроцессоров не добавил, и вот тут-то и началось: "Что, опять все сломалось? Ну и кофе же я забыл сделать!".😅

18.03.2024    3451    ZhokhovM    4    

10
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. sapervodichka 6865 30.09.23 22:51 Сейчас в теме
Есть такая тема по ускорению реструкторизации https://www.youtube.com/watch?v=ZG_M7KIXlv0
2. starik-2005 3061 02.10.23 10:56 Сейчас в теме
(1) Есть мнение, что:
1. Это работает не всегда. И ты не знаешь на 100%, что оно не сработает в очередной раз.
2. Это может что-то сломать. Прецеденты были.
3. Я вообще теряюсь, нафига для ALT ER TABLE 1С-никам понадобилась JAVA.
5. 1CUnlimited 316 02.10.23 14:28 Сейчас в теме
(2) Судя по багрепортам, оно так
По п 3. мне в принципе понятно - Java это не просто язык, а еще платформа для его исполнения JVM с параллелизмом и прочим.
А реструктуризация это еще не просто Alt er table, нужно отслеживать состояние процессов, иметь план сбой (чтото пошло не так) и много другое . На Java это быстрее и удобней реализовать, чем на С++ на котором пишутся системные вещи платформы
https://habr.com/ru/companies/1c/articles/269611/

другое дело - держать 2 метода реструктуризации параллельно, это будет провоцировать ошибки и снизит эффективность тестирования "на кошках". Надо оставлять один , но качественный
4. 1CUnlimited 316 02.10.23 14:13 Сейчас в теме
(1) по видео они обкатывали самый простой случай - добавление колонки. Но когда тип меняется или расширяется про это умалчивают. А там обработка данных идет без распараллеливания (я имею ввиду пакетная обработка записей таблицы)
Только в 8.3.22.1750 исправили ошибки которые не давали сделать реструктуризацию 8.2 в 8.3 в оптимизированном режиме , поэтому я не смог ей воспользоваться.
Собственно тут https://wonderland.v8.1c.ru/blog/optimizatsiya-restrukturizatsii-bazy-dannykh/
прямо написано про огранниченность функционала данного режима, и как следствие для конвертации 8.2 в 8.3 он "ограниченно годен"

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

Добавление или удаление столбцов таблиц. Эти операции проводятся теперь на текущих таблицах (раньше создавались новые таблицы и в них переносились данные). Необходимость добавления или удаления столбцов возникает, например, при добавлении или удалении реквизитов, при изменении некоторых свойств объекта конфигурации (иерархия справочника и столбец _ParentID) и др.
Добавление или удаление индексов. Просто создаётся новый индекс, без создания новых таблиц и переноса данных. Эти операции выполняются, если вы установили индексирование у реквизита, например.
Изменение существующих индексов. Также выполняется без создания таблиц и переноса данных. Например, кластерный индекс регистра сведений меняется тогда, когда вы добавляете измерение.

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

Конечно, существуют такие изменения, которые всё равно проходят обработку на сервере с выгрузкой данных построчно. Например, преобразование строки в число, или в дату. Такие операции нецелесообразно делать на уровне СУБД, к тому же они довольно редко встречаются. Но наиболее частые изменения проводятся всё же на уровне СУБД, одним запросом на одну таблицу
.


А в примере как раз в [dbo].[_AccRg640 столбцы не просто добавляются, но и делается пост обработка для заполнения их данных. И параллельной обработки я там не увидел
3. booksfill 02.10.23 12:43 Сейчас в теме
Со всем полностью согласен.

Думаю, проблема не в том, что 1С не знает такие слабые места, как неудовлетворительная производительность работы с СУБД, устаревший язык программирования и т.д. и т.п.
Это видно по тому, что 1С уже сделала и делает, та же работа с потоками, регулярные выражения, EDT и .т.п. появляются не просто так. Но медленно, очень медленно.

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

Проблема еще и в том, что придется менять систему обучения, то же секционирование само по себе не заработает - над еще правильно строить запросы. Возможность самостоятельно создавать, удалять индексы, делать bulk операции- это значит, что мальчики с курсов "освой ИТ за 1 месяц", могут наворотить такого, что мало не покажется.
1CUnlimited; +1 Ответить
6. 1CUnlimited 316 02.10.23 14:41 Сейчас в теме
(3)
(3)
то же секционирование само по себе не заработает - над еще правильно строить запросы.


По большому счету эффективное секционирование это определение колонки секционирования (период) , и принудительное использование ее во всех запросах. Для Программиста 1С это все что нужно знать. А управление секциями может легко взять на себя платформа
Например, при желании 1С уже сейчас может секционировать регистры накопления и бухгалтерии (в них везде есть поле период), если только пересмотрить свой подход к индексам (поле секционирования должно быть первым)
Сейчас это не так
Ну и Документы с табличной частью не партицируешь, поскольку в табличной части нет поля Период
Прикрепленные файлы:
7. starik-2005 3061 02.10.23 16:12 Сейчас в теме
(6)
поскольку в табличной части нет поля Период
В табличной части есть сцылка, в которой некоторым образом есть что-то типа периода. А распределение по партициям может определяться функцией, которая вытащит из гуида сцылки нужные данные. Но там все еще и на индексы завязано помимо данных, т.е. нужен выровненный (что бы это ни значило) индекс, иначе "невозможно будет переключиться между секциями". Если этими индексами занимается платформа, то все наверное ок. Но чета меня терзают смутные сомнения, что оно там автоматом как надо встает.
9. 1CUnlimited 316 02.10.23 17:02 Сейчас в теме
(7) Всякие функции партицирования они максимум диапазоны позволяют указывать на уровне SQL
Фукнция партицирования
Пытаться по ссылкам определять "чтото типа периода" это нереально.
Ключевое это выровненные индексы. А раз в индексах порядок полей поменяется, значит и генератор запросов на уровне платформы нужно будет подправить, иначе не попадем в индексы. Ну и в каждом запросе обязательно период употреблять, иначе любой запрос будет распределяться по всем партициям (будет хуже). Это тоже нужно делать на уровне платформы как с Общими реквизитами
8. booksfill 02.10.23 16:31 Сейчас в теме
(6)
Для Программиста 1С это все что нужно знать

Не думаю, все же следует понимать, что будет с производительностью запроса по нескольким секциям и по одной.
Например, если секции распределены по разным файловым группам, с разной доступностью.
Или чем кончится попытка вставки в архивную read only секцию и т.п.
10. 1CUnlimited 316 02.10.23 17:06 Сейчас в теме
(8) Если период в запросе явно фигурирует, и он является колонкой партицирования, тогда партиция будет выбиратся по условию на период. А если запросы строить без поля партицирования, это сделает результат хуже - СУБД применит запрос ко всем партициям. На уровне платформы можно для партицированных таблиц такой контроль сделать чтобы было меньше ошибок
11. starik-2005 3061 02.10.23 17:20 Сейчас в теме
(10)
На уровне платформы можно для партицированных таблиц такой контроль сделать чтобы было меньше ошибок
Все упирается в то, что код - это программисты пишут, а партиционирование - этим админы рулят (даже пусть DBA). И вот сегодня DBA "расщепил" таблицу, а вчера написанные запросы про продажи за все года оказываются без фильтра. Ну или динамические списки документов/регистров, которые вроде как открываются без фильтра по дате/периоду, скажут пользователю что-то странное...
12. Serg2000mr 429 03.10.23 13:25 Сейчас в теме
(0) По поводу влезания в технологическое окно: вы не рассматривали аренду вычислительных мощностей под задачу типа Amazon EC2, Microsoft Azure, VK Cloud ?
13. 1CUnlimited 316 03.10.23 16:19 Сейчас в теме
(12) А что это даст?
Самый длительный процесс при переходе с 8.2 в 8.3 это всякие постобработки записей при реструктуризации, они идут в один поток (в примере как раз в [dbo].[_AccRg640 столбцы не просто добавляются, но и делается пост обработка для заполнения их данных. И параллельной обработки я там не увидел) там нагрузки на ресурсы особенно нет, а время тратится.

А так как то считал - аренда MS Azure эквивалентной мощности за год\полтора стоит как железный сервер такого же уровня с ОС , софтом и т.д.
Учитывая что оборудование на продуманном решении работает десяток лет (достаточно только узлы серверов приложений добавлять), лучше брать свое. На этом горизонте и с учетом инфляции это гораздо выгодней.
Уже лет 10 тактовые частоты не растут фундаментально, а растет только количество ядер. Поэтому распараллеливание фоновыми это единственный вариант сохранения производительности
14. Serg2000mr 429 03.10.23 22:00 Сейчас в теме
(13) Возможно, как-нибудь соберусь, не пожалею денег и протестирую. Практика покажет. На год-полтора большие мощности и не нужно арендовать, аренда и не предполагает длительное использование.
15. 1CUnlimited 316 04.10.23 10:48 Сейчас в теме
(14) Аренда имеет смысл только ради двойного дискового пространства, которое неизбежно потребуется из на особенностей реструктуризации (копии таблиц даже в оптимизированном режиме, переброс данных из Ваших tablespace в Primary )
Оставьте свое сообщение