Почему после обновления платформы 1с необходимо делать реструктуризацию базы данных

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

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

Реализовано в версии 8.3.11.2867.

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

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

Реструктуризация это изменение структуры и состава таблиц базы данных, и перенос имеющихся данных в изменённые таблицы. Обычно реструктуризация выполняется в тот момент, когда вы нажимаете Обновить конфигурацию базы данных в Конфигураторе. Но выполняется она не каждый раз.

Реструктуризация выполняется тогда, когда изменения конфигурации требуют появления новых колонок или таблиц в базе, или когда меняется тип существующей колонки. Например, вы добавили реквизит к справочнику, добавили документ, или изменили тип имеющегося реквизита с Число на Строка. В этих случаях потребуется реструктуризация.

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

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

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

• Анализ его изменений;
• Создание новых таблиц в базе данных, которые соответствуют новой структуре объекта;
• Перенос данных.

Из этих трёх шагов перенос данных занимает наибольшее количество времени. При этом сами операции переноса данных могут быть простыми и сложными.

Например, к простым и быстрым операциям относятся те, которые вызваны добавлением или удалением столбцов таблицы. В этом случае отдельным запросом создаётся новая таблица (с изменённой структурой) и данные переносятся в неё.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы провели несколько сравнительных экспериментов на реальных информационных базах, и получили следующие результаты:

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

Особенности текущей реализации

Новый механизм реструктуризации мы планируем включить в версию 8.3.11 в статусе бета. Он реализован только на сервере, причём на сервере должна быть установлена Java 8.

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

Пока поддерживаются только две СУБД: MS SQL Server и PostgreSQL.

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

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

Для перечисленных объектов (кроме регистров) оптимизированы любые их изменения. Для регистров мы оптимизировали реструктуризацию движений и реструктуризацию таблиц регистрации изменений. Операции пересчёта итогов и пересчёта срезов для регистра сведений мы пока не оптимизировали. Однако, несмотря на это, использование нового механизма уже даёт существенное ускорение всего обновления регистров в целом.

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

Почему после обновления платформы 1с необходимо делать реструктуризацию базы данных

Имеется очень сильно переписанная база на основе Розницы. До сих пор работала на версии платформы 8.3.13.1644
Лежит на postgresql-10.5-24.1C_x64, кластер 1С и postgre SQL с базой находятся на одном физическом сервере.
Размер окол 45Гб.

Решили обновить платформу 1С.
Сисадмин на тестовой машине установил postgresql_13.4_6.1C_x64, сервер 1С и платформу 8.3.20.1674.

Из старой версии dt выгружается и при необходимости прекрасно загружается обратно, а вот в новую версию отказывается загружаться. Процесс загрузки начинается, загружает примерно 5 Гб (по данным pgadmin) и выходит с ошибкой.

После включения логирования получаем ошибку
48:26.312001-0,EXCP,3,process=rphost,p:processName=NEW,OSThread=1088,t:clientID=17,t:applicationName=Designer,t:computerName=BUH,t:connectID=21,SessionID=1,AppID=Designer,Exception=SeanceContextException,Descr=Попытка получения неинициализированного значения

Методом проб и ошибок было выяснено: новая платформа успешно загружает базу УТ10, имеющую больший размер, чем целевая.
Если загрузить базу с помощью платформы 8.3.13.1644 и затем обновить платформу то база работает, однако выгрузка в DT проходит, а обратно не загружается.
Если установить 1с 8.3.18.1661, то тоже база нормально загружается и работает, на более свежих платформах загрузка не проходит.

Подскажите, как убедить последние версии платформы 1С загружать нашу базу.

Зачем вам 20 платформа? Почему бы не оставить 13, ну или хотя бы 18?

У меня ЗУП работает например сейчас на 19 платформе, а все остальные самописки на 13 до сих пор, и с 13 их переводить не собираюсь

установи ту платформу, через которую выгружали. Загрузи на сервер и установи новую платформу.

(3) наверное по этому: «Если загрузить базу с помощью платформы 8.3.13.1644 и затем обновить платформу то база работает, однако выгрузка в DT проходит, а обратно не загружается. «

Не понятно зачем для УТ10 последняя платформа.
(5) у него вообще Розница )))
(6) Розница 1.0 ?
(0) зачем вы дт мучаете, неужели нет возможности по средствам скуля выгрузить и загрузить базу?
Иногда полезно грузить в пустую базу , а не в прежнюю. Т.е. создал пустую базу на SQL и грузи.

Ошибки могут быть при выгрузке в dt. 1С рекомендует восстанавливать архивы средствами СУБД, если это не переход с файловой на клиент-серверную

(10) явно скуль используется раз «Сисадмин на тестовой машине установил postgresql_13.4_6.1C_x64, сервер»

(0) Вы меняете и версию платформы и версию СУБД
Странно что у вас там не взорвалось ничего

(1) Планируем подключить обмен по ЭДО, а для этого взять обработку Diadok в перспективе они скорее всего все равно потребуют более свежую платформу.
(6) Розницей это было очень давно. Сейчас там больше своего написано.
(8) Сисадмин утверждает что у postgresql c этим проблемы. К тому же, а если придется на SQL переходить, то как это без dt сделать?
(9) пробовали. создавали и пустую базу, в нее загружали только конфигурацию и затем уже целевой dt результат такой же.
(10) Ошибки наверное могут быть, но почему тогда в старые версии грузится?
(12) Пробовали не менять версию СУБД — ошибка та же на том же месте(загружался такой же объем базы).

(13) Тестировали бд ?
(14)Да, конфигуратором. После все равно не загружается в новую платформы.
В СЕРВЕРНОМ варианте?
(12) действительно, повезло еще.
!18) Я же писал в (13) что была попытка поменять только платформу, но это ни к чему не привело.

(13) вы же сами пишите, что у вас клиент-серверный вариант работы с базой «Лежит на postgresql-10.5-24.1C_x64,» попробуйте сделать бекап на стороне скуля, постгря без проблем с этим справится и грузите уже этот бекап, а не вашу дтшку. «Сисадмин утверждает что у postgresql c этим проблемы» — может это у сисадмина проблемы? Какая ошибка?

забудьте уже о дтшках на базах с более 10 юзверами и размерами за 40гигов. Всегда есть риск не развернуть базу, либо развернуть с ошибками, поэтому и не рекомендуют использовать ДТ для бекапов

(20) т.е. вы считаете нормальным тот факт что 1С разучилась загружать собственные дт?
в(1) я писал: Если установить 1с 8.3.18.1661, то тоже база нормально загружается и работает, на более свежих платформах загрузка не проходит.

(19) из чего следует вывод — 20-я платформа тестовая подделка, посмотрите, сколько криков на тему. перешли на 20-ю — все умерло.

(22) вы проблему хотите решить, или по возмущаться, почему ваш ДТ 1ска не кушает?)

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

(22) если в выгруженном дт есть ошибки (рассогласованность схемы базы? например, ошибки в полях и структуре табличек, которые ТиИ никогда не правит) то dt никогда не загрузится ни в какой релиз.

и это ..со времён выгрузки в dat файлик в 7.7
Если ваш Одмин не умеет делать скулевый бэкап.. гоните его сцанными тряпками

(26) Как проверить наличие ошибки рассогласованность схемы базы?
К тому же 8.3.18.1661 прекрасно грузит.

(29) Эту базу или что грузит ?
такой запрос че возвращает ?
SELECT * FROM ConfigSave ?
База в каком режиме совместимости ?
(31) там бекап не могут на скуле сделать, а вы прямой запрос просите сделать)

Грузит именно эту базу именно из этого же дт
(31) не пробовали. Это надо на старом сервере сделать конечно?

(33) А вы умеете? Расскажите как, я сисадмину передам.

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

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

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

Знаю такую проблему для файловой базы, про серверный вариант не слышал. В нашей базе кстати таких нет.

(34) И в какой именно вашу выгрузку не загружает ?
и вы 18 накатывали куда, на старый сервер или на новый ?

(37) Зря иронизируем. Однажды мне помогло банальное ТиИ (реструктуризация). База, загруженная из DT, становилась битой после непродолжительной работы с ней. Крамольная мысль: вероятно какие-то служебные данные из DT предыдущей платформы загружались без их реструктуризации.

(29) ну так и оставайся на этой платформе.
почитайте внимательно вот эти рекомендации https://its.1c.ru/db/metod8dev/content/2922/hdoc

+(42) (офф) я даже помню случай, когда DT файловой версии не грузился в клиент-серверную версию той-же платформы (хотя, как по мне, так обратное считал более вероятным).

(42) дело говорит
Нужно текущую обновить платформу, потом сделать реструктуризацию через ТИ, а потом уже попробовать выгрузку загрузку DT

ИМХО, автор хернёй страдает.
1С всегда и везде писала, что dt не является архивом и что бекапы клиент-серверных баз должны делаться средствами СУБД.
Единственное, где без dt не обойтись — миграция с файлового варианта на клиент-сервер и обратно или с одной СУБД на другую.
Налицо придумывание самому себе проблем и мужественные попытки их преодоления.
Обновлять одновременно и версию платформы и версию СУБД — заведомый поиск приключений на свою задницу. Причем с заранее неизвестным источником причин этих приключений — толи СУБД глючит, то ли платформа. А может там админ криворукий и тестовый сервер криво настроил и там тупо места на диске не хватает (например).

(46) спасибо за дельный совет. Попробуем.

(47)Уважаемый, я видимо где-то написал на непонятном для вас языке, но

1. Не было обновления, была установка на новом сервере и уже туда попытка «миграции». — неудачно
2. Была произведена попытка миграции на новую платформу 1С с использованием старой версии постгриса. — неудачно
3. А если когда нибудь все таки потребуется мигрировать «с одной СУБД на другую», а я уже знаю: dt не грузится?
4. Место на диске бралось с кратным запасом по отношению к размеру базы. Причем еще раз отмечу, на той же машине не могут загрузить базу только последние версии платформы.

Вы пишете «1С всегда и везде писала, что dt не является архивом». Спасибо Kassern он как раз вовремя дал ссылку https://its.1c.ru/db/metod8dev/content/2922/hdoc
где написано: «Иногда этот режим используют, также, для создания резервной копии информационной базы» ну вот мой случай как раз «иногда».
Все перечисленные в статье недостатки этого метода компанию устраивают.

(49) Поставить на новом серваке ту-же версию постриги и ту же версию 1с-ины не предлагать ?
А потом уже заниматься поднятием версии платформы

Да и..45 гиг.. версионирование поди, гигов 30 место отъело ? 🙂

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

(52) ну и обновляй, в начале на старом постриге обнови платфору ( не делая никаких выгрузок)
Потом подыми версию скуля

для мегагуру-нытиков про «дт ето не архивация».
1. по ссылке из (44): «1С:Предприятие поддерживает возможность загрузки/выгрузки информационной базы в файл. Этот механизм предназначен, прежде всего, для получения образа информационной базы независимо от способа хранения данных.» по слогам. «поддерживает». но не рекомендует для постоянного использования в качестве штатного бэкапа («обладает рядом недостатков. Основным недостатком такого способа создания резервной копии является необходимость использования однопользовательского режима для осуществления этой операции. При большом объеме информационной базы перерыв в работе пользователей может быть достаточно велик, что не всегда приемлемо.»)
2. у человека — НЕ штатный бэкап, а именно перенос из релиза в релиз с изменением версии формата хранения. для которого используемый им метод и применим, и «поддерживается».
поддержка постгри кроссплатформенного переноса базы — это плюшка «параллельная», не пересекающаяся с описанной задачей. она есть — Ок, но как она если при этом еще и движок 1с меняется (который в том числе также может коснуться структуры на низком уровне).
ну т.е. — штатный механизм, для которого и обещана поддержка, и область применения соответствует — не работает как обещано, значит надо прежде всего думать почему так и как исправить именно это. а уж далее способы продвинутого серверного администрирования — это уже «далее», а не растопырив пальцы и презрительно выпячивая нижнюю губу на штатные методы.

(55) одно дело, когда человек проблему решил и пытается разобраться, что способствовало ее появлению, другое дело, когда человек сидит со старой платформой и никуда свою дт воткнуть не может с кучей ошибок, а на подсказки решения проблемы разворачивания бекапа через инструмены скуля получили ответ — мол сложно для админа. Никто тут губу с пальцами не растопыривает, тут человек не с файловой на скуль переходит и не с постгри на ms sql, а всего лишь пытается развренуть на другом серваке свою базу, но почему-то сразу пытается на новую платформу.

(52) Можете и дальше обижаться словно девочка. Дело Ваше.
Просто никто никогда так не делает.

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

А утверждения вашего сисадмина про то что «. у postgresql c этим проблемы» звучат мало убедительно.
Разделите задачи обновления платформы и обновления СУБД и проблемы не будет.

Есть четкие описания порядка обновления платформы от 1С. Ни в одном из них нет упоминания о выгрузке/загрузке через dt.
Есть четкие описания обновления версии СУБД от Postgre. И (неожиданно) в них тоже нет никаких упоминаний о каких-то загрузках сторонними приложениями (1С) из файлов непонятного происхождения (с точки зрения СУБД).

До сих пор ни одного явного доказательства, что проблема именно в 1С, а не на стороне СУБД, ОС или на стеке , так и не прозвучало.
Если ваш dt успешно можно загрузить на той же версии платформы и той же версии СУБД, откуда он был выгружен, то абсолютно никаких оснований обвинять в чем-то 1С я не вижу. Можете и дальше печалиться, сокрушаться, расстраиваться или что вы там ещё делаете вместо того чтобы нормально работать.

(57)Достаточно заменить постгре на мс скл и Ваши рассуждения теряют смысл совсем.
(58) а что не так с мс скл?

(0)Вам надо локализовать ошибку с точностью до записи таблицы.
но сначала с точностью до таблицы.
для этого можно настроить тж и выяснить инyтрукции выполненные до ошибки.( экстенсивный долгий путь)
либо сгенерировать «маленькую» бд с 1к записей в каждой не служебной таблице и загрузить её(тк бд маленькая — загрузка быстрая).
если ошибка повториться , то (бысто) её проанализировать с помощью тж. ошибка скорее всего в служебных таблицах.
иначе
сгенерировать огромное кол-во выгрузок (dt) с несколькими таблицами . чтобы выяснить на какой таблице происходит ошибка.

Месяц назад обновлял платформу с 14-й на 20-ю, снес полностью каталог кластера 1С. ЖР можно сохранить, если нужны.
Выгруженные в dt из 14-й базы прекрасно загрузились в 20-ю, даже совсем старая бухгалтерия бюдж. уч., которой 12 лет и с 8.2 совместимость. Проработало все это время без нареканий.
PostgreSQL тоже менялся, с 11-й редакции на 13-ю. Ничего не екнуло.

Обновление платформы

День добрый!
1С:Бухгалтерия, платформа 8.3.18.1741
На последних вебинарах несколько раз Вы говорили об обновлении Платформы до 8.3.20 (ПРИНЦИПИАЛЬНО!)
Это обязательно надо сделать? В информации сервиса обновления указано, что не обязательно…
Может ли релиз платформы повлиять на последние изменения и обновления?
Спасибо

Обсуждение (2)

Ирина Шаврова Сотрудник БухЭксперт8 :

Приложение

Здравствуйте!
Вот смотрите какие плюшки реализованы в Платформе 8.3.20:
— повышена скорость работы системы и улучшено использование оперативной памяти при работе под управлением ОС Windows.
— Повышена стабильность кластера серверов в проблемных ситуациях.
— Повышена производительность некоторых видов запросов, выполняющихся в системах с ограничением доступа к данным.
— Повышен контроль над использованием ресурсов рабочим процессом кластера.
— Снижено потребление оперативной памяти кластером серверов при работе в разделенном режиме.
— Расширены возможности использования расширения конфигурации. Источник: https://dl03.1c.ru/content/Platform/8_3_20_1363/1cv8upd_8_3_20_1363.htm#9528e919-7110-11eb-8371-0050569f678a Поэтому, конечно, смысл переходить на новую платформу есть. ��
Но в то же время, если у вас есть сложные обмены с другими конфигурациями, загрузки и выгрузки в вашей Бухгалтерии торопиться не надо. По отзывам пользователей в таких случаях случаются проблемы и их приходится решать в авральном режиме, особенно, несли вы используете расширения конфигурации, внешние обработки или подгружаете базы данных из копий. Наши рекомендации были основаны на новых фишках релиза платформы и на том факте, что подготовка к вебинару шла на релизе 8.3.20, а подгружать эту базу пришлось на более низкую платформу и были проблемы с подгрузкой. Если вы не используете расширений, у вас нет доработок и обменов с разных ПК, вы не подгружаете новые копии к себе на более низкую платформу (например, выгружаете с работы и берете базу домой), то переход на 8.3.20 даст вам плюсы. Если что-то из перечисленного у вас в наличие, то не переходите.
Сейчас отлажены версии 8.3.17, 8.3.18, 8.3.19 и хорошо работают.
Вероятно, вам не слишком нужны новые фишки по возможностям доработки программы и языка запросов, если база у вас полностью типовая. Тем более что в декабрьском релизе 8.3.20.1674 были проблемы с динамическими списками в прорисованных формах.
Правда, на текущем релизе 8.3.20.1710 ошибка исправлена. Но сам переход на 8.3.20 при всех своих плюсах не так прост (ниже подробно разверну этот вопрос) На текущий момент можно оставаться на версиях платформы: не ниже 8.3.17.1851, 8.3.18.1741, 8.3.19.1467 без всякого ущерба для работы.

Ирина Шаврова Сотрудник БухЭксперт8 :

Обратите внимание на следующие моменты при переходе с предыдущей версии на версию 8.3.20:
— Конвертация конфигураций, информационных баз, внешних обработок и внешних отчетов при переходе от предыдущей версии к версии 8.3.20 не требуется.
— Для использования некоторых новых возможностей версии 8.3.20 необходимо отключить режим совместимости. При отключении и включении режима совместимости выполняется изменение структуры некоторых объектов базы данных. Для того, чтобы иметь возможность работать с информационной базой предыдущими версиями, необходимо установить режим совместимости.
— До первого не динамического обновления конфигурации базы данных не будет выполняться динамическое обновление конфигурации базы данных.
— Для использования динамического обновления конфигурации базы данных рекомендуется после перехода на новую версию выполнить реструктуризацию информационной базы. Эту операцию можно выполнить с помощью тестирование и исправление информационной базы с включенным режимом Реструктуризация таблиц информационной базы или выполнить какие-либо изменения в конфигурации, приводящие к реструктуризации базы данных. Поэтому если у вас нет сисадмина и вы обновляетесь самостоятельно, учтите эти моменты, или если не уверены в том, что сможете справиться с указанными выше моментами — оставайтесь на старой платформе.

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

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

• Новые формы налоговой отчетности повысят контроль и «собираемость налогов».
• Новые требования бизнеса повысят «прибыль и капитализацию в будущем»
• Нужно быстро доделать проект, который начала другая команда.
• Аудиторам нужна другая отчетность, а не как в прошлом году.
• И вообще «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С:Предприятие“.

Иными словами использовать 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С.

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

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

Проработка уже этих вопросов сильно поменяет концепцию функционала. Например, стоит наложить ограничения и отказаться от смены типа реквизита (число \ строка) на уровне платформы 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С. То есть ее нельзя разделить на части.

Конечно в кластере серверов 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.

• Удаление данных и архив Методика похудения для 1С — 100% (infostart.ru).
• Подстраиваем запрос под общие разделители 1С Миссия невыполнима. Общие реквизиты разделители против временных таблиц / Хабр (habr.com).
• Соблюдаем Партицированная дисциплина программиста в 1С / Хабр (habr.com).
• Убираем узкие места в СУБД чтобы не уперется в стену Delayed durability поможет вашему ORM увеличить производительность на 50% и более, если Вы только будете использовать … / Хабр (habr.com).
• Подстраиваем Postgres под особенности 1С Как эффективно настроить autovacuum в Postgres для 1С / Хабр (habr.com).

Иными словами — Вы не можете перейти на новую версию платформы штатными инструментами, когда база перешагнула 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 заложит нужные архитектурные решения для других СУБД.

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

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

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

• Программирование
• Анализ и проектирование систем
• Проектирование и рефакторинг
• 1С