Тюнинг планов обмена

08.07.24

Интеграция - Перенос данных 1C

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

Планы обмена – это основной механизм регистрации изменений данных платформы 1С.

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

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

По итогам мастер-класса была написана статья, которая актуальна до сих пор.

Коротко напомню, как возникают эти проблемы. У нас в 1С есть программное средство – менеджер планов обмена, который позволяет регистрировать изменения, удалять их и выбирать:

  • Для выбора изменений используется метод – ПланыОбмена.ВыбратьИзменения(…)

  • Для удаления зарегистрированных изменений – ПланыОбмена.УдалитьРегистрациюИзменений(…)

  • А для регистрации изменений – два метода: платформенный и произвольный:

    • Произвольный метод
      ПланыОбмена.ЗарегистрироватьИзменения(…);
      мы можем вызвать в любой точке кода.

    • Платформенный метод срабатывает при записи объектов (при вызове Объект.Записать()). Он делает то же самое, что ПланыОбмена.ЗарегистрироватьИзменения(…), но работает фоном, в ядре платформы. При платформенном способе мы управляем регистрацией изменений при помощи коллекции Получатели из настроек обмена данными объекта: Объект.ОбменДанными.Получатели.Добавить(…);

 

При этом:

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

  • А в случае произвольной регистрации изменений – если мы вызываем ПланыОбмена.ЗарегистрироватьИзменения(…), например, где-нибудь в подписке на событие «Перед записью» – мы будем удерживать блокировку на таблице регистрации изменений все время до завершения транзакции.

 

Моделирование проблемы блокировок при регистрации изменений

 

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

  • мы получаем какой-то объект;

  • записываем его;

  • заполняем коллекцию получателей – я здесь использую платформенный метод регистрации;

  • и ставим точку останова на строке «ЗафиксироватьТранзакцию()» – таким образом мы искусственно продлеваем транзакцию, удерживая блокировку на таблице регистрации изменений. Блокировка создается по тому объекту, для которого выполняется регистрация изменений и по тем узлам, что мы для регистрации выбрали.

Запускаем сессию 1С, выполняем этот код, встаем на точке останова. И одновременно открываем вторую сессию – для создания конкурирующей транзакции, в которой мы пытаемся зарегистрировать изменения по тому же самому объекту, по тем же узлам.

 

Т.е. мы нажимаем кнопку «Зарегистрировать изменения» – получаем ошибку конфликта блокировок на таблице регистрации изменений.

 

«Удалить регистрацию изменений» – получаем ошибку.

 

«Выгрузить данные РИБ» – например, мы здесь вызвали «ВыбратьИзменения, тоже получили ошибку.

Во всех трех случаях мы видим ошибку СУБД.

Причем эта ошибка СУБД характерна как для Microsoft SQL Server, так и для PostgreSQL – там происходит ровно то же самое.

 

И если мы пытаемся этот объект записать, мы тоже получаем ошибку. Причем это уже не ошибка СУБД – это объектная, так называемая управляемая блокировка, которую накладывает сервер 1С.

На этой блокировке я хотел бы особенно остановиться. Это очень важная и нужная блокировка, которая не имеет ничего общего с блокировками на таблице регистрации изменений планов обмена. Эта блокировка про другое – она защищает целостность данных объекта, который мы записываем.

 

Схема решения проблемы блокировок таблицы регистрации изменений на уровне СУБД

 

А теперь давайте спустимся на уровень СУБД – здесь я еще раз напомню о своей статье, где подробно расписано, как все это работает на уровне СУБД.

Платформа 1С по отношению к таблице регистрации изменений выполняет команды SQL: INSERT, UPDATE и DELETE.

Эти команды вызываются в следующих случаях:

  • INSERT может вызываться в результате:

    • платформенной регистрации – она здесь у меня помечена как «Платформа»

    • или при произвольной регистрации методом «Зарегистрировать изменения»

  • UPDATE вызывается в процессе выполнения метода «Выбрать изменения».

  • DELETE – вызывается при удалении регистрации.

При этом на уровне СУБД:

  • методы UPDATE и DELETE блокируют записи в таблице регистрации изменений, и из-за этого возникают ожидания на блокировках – мы ждем, пока они закончат свою работу;

  • а метод INSERT – это неблокирующая операция, она просто добавляет записи в таблицу и никого не ждет при этом.

 

Методика тюнинга планов обмена, про которую я буду говорить далее, решает только проблемы блокировок СУБД и именно на таблицах регистрации изменений.

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

Чтобы бороться с объектными блокировками, существуют другие методики – в частности, этим занимаются 1С-эксперты: они пытаются как-то укоротить транзакцию, оптимизировать код в процедурах проведения и так далее. Тюнинг планов обмена на поведение платформы никак не влияет. И это правильно. Все остальные блокировки мы удаляем.

 

На этом слайде показана ключевая идея доклада.

Давайте попробуем поразмышлять, что нам надо сделать, чтобы не было блокировок на записях таблиц регистрации изменений. Очевидно, что нам надо каким-то образом сделать так, чтобы команды UPDATE и DELETE ничего не блокировали.

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

Возникает вопрос – а что делать с регистрациями? Регистрации мы перехватываем командой INSERT, которая содержит ключи изменяемых объектов. И записываем данные об этих регистрациях в регистр сведений «Таблица-очередь Регистрация изменений».

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

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

Мы используем триггеры СУБД.

  • Для SQL Server это триггеры INSTEAD OF, которые формируют инструкцию типа: «Вместо команды INSERT положи в регистр сведений» – примерно так.

  • А для PostgreSQL это триггерные функции, которые потом «подвешиваются» к триггеру BEFORE – там аналогичная методика.

С помощью этих триггеров мы будем перенаправлять команды INSERT, которые шлет платформа для таблицы регистрации изменений, в регистр сведений «Таблица-очередь Регистрация изменений».

В чем плюсы этой методики ?

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

  • Во-вторых, огромным плюсом я считаю то, что мы в принципе не меняем код 1С вообще никак – для платформы все работает прозрачно!

Сохраняется работоспособность кода по регистрации изменений, который относится к типовым механизмам – например, к механизму регистрации изменений БСП, правилам регистрации объектов КД2. А также продолжит работать код по регистрации изменений, который мы сами написали, включая ручную регистрацию пула объектов, полученных запросом.

Единственный минус:

  • Методы ВыбратьИзменения и другие, завязанные на таблице регистрации изменений, ничего выгружать не будут. Потому что таблицы пустые – им выгружать нечего. Этот код мы не меняем, но он работает вхолостую. Поэтому нам код выгрузки надо каким-то образом адаптировать для получения данных о регистрации из этого регистра «Таблица-очередь Регистрация изменений». Это можно отнести к минусам. В любой технологии есть плюсы и минусы, здесь так.

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

 

Платформа DaJet – приложение для тюнинга планов обмена

 

 

Чтобы реализовать прототипы и доказать состоятельность этой идеи, я разработал небольшое приложение на платформе DaJet, автором и единственным разработчиком которой на данный момент выступаю я.

Платформа DaJet состоит из следующих компонент:

  • В ядро DaJet входят:

    • Библиотека Metadata, которая позволяет читать метаданные 1С.

    • Компонент DbView, который позволяет создавать вьюхи, представления СУБД. Этот компонент очень активно используют, например, аналитики данных – он позволяет им в нормальных терминах работать с базами данных 1С.

    • Модуль Scripting, предоставляющий SQL-язык запросов в терминах 1С, но со своими дополнениями и расширениями.

    • И модуль Flow – это библиотека для создания и построения конвейеров потоковой обработки данных. По сути, это аналог Kafka Streams для C#.

    • Библиотеки ядра поддерживают работу с основными СУБД – MS SQL Server и PostgreSQL. И с наиболее популярными брокерами – RabbitMQ и Kafka.

  • У библиотек ядра нет интерфейса – с ними можно работать напрямую на C#, но не все знают C#. Поэтому для создания классической трехзвенной архитектуры разработан сервер DaJet. Он построен на базе веб-сервера Kestrel и в его задачи входит:

    • Во-первых, выполнение скриптов.

    • И он используется как хост для конвейеров обработки данных. Если говорить в терминах 1С, то сервер DaJet – это аналог 1С-вского rphost, а конвейеры – это фоновые задания.

    • Все компоненты платформы DaJet написаны на C#. И они кроссплатформенны – работают на Windows, на Linux и на macOS. Декларируется, что платформа .NET 8.0, которую я использовал, работает даже на ARM-процессорах, но я не проверял.

    • Для удобства работы с сервером DaJet у него есть свой веб API – можно выполнять команды через Postman или Curl, обращаться к этим библиотекам, выполнять какие-то задачи.

  • Также разработан клиент с веб-интерфейсом пользователя – DaJet Studio. Это приложение написано на технологии Blazor – это микрософтовский UI-фреймворк, основанный на WASM (WebAssembly). Клиент работает во всех современных браузерах, которые поддерживают технологию WASM – все последние версии браузеров эту технологию сейчас точно поддерживают.

 

 

Платформа расширяемая, и для нее можно писать приложения – на слайде показана главная страница приложения, которое я написал специально для тюнинга планов обмена.

Установка DaJet очень простая – скачал zip-архив, распаковал в папку, запустил http-сервер DaJet и просто зашел браузером по адресу http:/localhost:5000. Открылось приложение, и мы там можем что-то делать.

Чтобы это можно было самим потрогать и поэкспериментировать с новыми технологиями, я разработал специальную версию DaJet 2.3.3, которая содержит, в том числе, cf-ник для 1С и демо-базу.

На слайде – главное окно этого приложения.

  • Слева – панель, которая показывает зарегистрированные базы 1С.

  • Справа – рабочая панель.

Сделано это по аналогии с MS SQL Server Management Studio или pg-admin, если кто знает. Концепция примерно такая.

Слева – список баз. В каждой базе есть всякие разные сервисы. Например:

  • сервис api – это для скриптов;

  • сервис exchange – это для обменов;

  • сервис dbw – это сгенерированные вьюхи;

  • а «Расширения» и «Конфигурации» – это просто метаданные 1С.

Если мы кликнем на сервис exchange правой кнопкой мыши, у нас откроется контекстное меню с волшебной кнопкой, которая называется «Тюнинг планов обмена».

При вызове «Тюнинга планов обмена» в рабочей панели откроется форма с двумя кнопками – «Включить» и «Выключить». Т.е. вся реализация – это две кнопки.

Получается, что в клиенте DaJet у меня есть возможность для базы ms-exchange – очевидно, что эта база на MS SQL – включить тюнинг планов обмена или выключить.

 

При включении «Тюнинга планов обмена» выводится список всех объектов, которые входят в состав всех планов обмена – все, что в принципе можно оттюнить, где есть таблицы регистрации изменений. Сейчас это реализовано так, чтобы работать по всем планам обмена и по всем объектам – в конце концов, это прототип и НИОКР.

Что делает кнопка «включить»:

  • Первым делом она создает объект базы данных SEQUENCE – это генератор числовой последовательности на уровне ядра СУБД. Для чего он нужен, я чуть позже расскажу.

  • Потом начинается транзакция.

  • По очереди блокируется таблица регистрации изменений каждого объекта метаданных – проходит цикл по таблицам регистрации, каждая таблица обрабатывается в транзакции. Для MS SQL Server она накладывает на таблицу исключительную блокировку – TABLOCKX. А для PostgreSQL – EXCLUSIVE MODE, что то же самое.

  • Блокировка нужна для того, чтобы перенести все уже существующие регистрации в регистр сведений, чтобы нам там ничего не мешало. 100 тысяч записей из таблицы регистрации изменений переносятся в регистр сведений одной командой SQL – на это уходят считанные секунды.

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

  • Фиксируется транзакция, и все.

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

 

При выключении тюнинга плана обмена все триггеры сбрасываются, и система возвращается в обратное состояние.

При этом в 1С вообще ничего не надо делать, для нее это абсолютно прозрачно – просто удаляются триггеры, и дальше работает платформенная регистрация изменений.

 

Для регистра сведений, в который перенаправляются данные, я предлагаю некую типовую структуру.

  • Первое измерение – это «Вектор», число (19, 0). Здесь в пояснении написано, что это гарантированно уникальный последовательный ключ. Объект SEQUENCE, который создается на уровне ядра СУБД, триггером генерирует значение этого вектора. Название «Вектор» произошло от векторных часов. Если вы не знакомы с этим термином, в моей статье вы можете почитать, как и зачем использовать векторные часы для синхронизации в распределенных базах данных. По сути, вектор – это версия.

  • Далее у нас идет два измерения (или ресурса, что неважно) – это «Узел» и «Ссылка» для ссылочных типов данных – справочники, документы и прочее. Это те данные регистрации изменений, которые должны были попасть в таблицу регистрации изменений, но попали в регистр. Они попадают сюда.

  • «Данные» и «Транзакция» – это реквизиты регистра. Их заполнение необязательно, но с их помощью мы получаем дополнительные бонусы.

Преимущества такой структуры регистра сведений:

  • Во-первых, все регистрации становятся последовательными. Все зарегистрированные изменения идут в строгой последовательности согласно этому вектору.
    Это то, чего у нас нет в планах обмена – там регистрация зависит от GUID, от внутреннего идентификатора объекта. В какой он там последовательности попадет в эту таблицу – вообще неизвестно. Здесь гарантируется некая последовательность. Это первый бонус.

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

  • Ну а значение реквизита «Данные» – произвольное. Мы можем его использовать для служебных целей – написать там вообще что угодно. Например, мы можем его использовать при регистрации изменений для регистров сведений и вообще регистров. Вы знаете, что у них чаще всего составной ключ – это несколько полей. А здесь для ключа объекта у нас одно поле. Например, есть регистр сведений, у которого три измерения – как их запихать в одно? С этим пока есть техническая сложность, но я сейчас покажу, как ее в прототипе реализовал.

 

Ключ регистра сведений записи в прототипе помещается в поле «Данные». И если нам нужно каким-то образом сериализовать ключ записи регистра сведений в одно поле – эта проблема в принципе решаемая, поскольку у всех современных СУБД есть средства работы как с XML, так и с JSON. И даже можно в бинарном виде при желании все это сериализовать.

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

Но в данном случае это работает так, как показано на слайде.

Например, здесь мы видим, что идентификатор транзакций для пяти объектов одинаковый – видимо, в транзакции регистрировали справочник «Номенклатура». Если нам это важно, мы можем эти записи по транзакции объединить.

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

А здесь, поскольку у нас все время идет добавление – может быть много объектов. Но есть «Ссылка» и есть ключ «Данные», по которым мы эти данные можем агрегировать. Об этом я скажу позже.

 

Здесь я привожу шаблон триггера для MS SQL Server с комментариями

 

И то же самое для PostgreSQL.

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

Таблица регистрации изменений у него одна, и триггер на эту таблицу тоже один.

 

Как работать с этим регистром сведений – с этой «Таблицей-очередью Регистрация изменений»?

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

  • Выбираем первые 10000 записей (регистраций).

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

  • Получаем поля «Вектор», «Узел» и «Ссылка». «Узел» и «Ссылка» – это данные регистрации, которые мы перехватили и перенаправили.

  • Если применить группировку по «Узлу» и «Ссылке», можно актуальную версию получить. Это как раз к вопросу о дедупликации данных. Мы с ней боремся вот таким образом – просто группируем по ключам и таким образом устраняем дубли. Я еще люблю это называть сжатием потока данных.

Поток данных сжали, получили то, что мы хотим обработать, упорядочили, если нам нужна последовательность. И дальше, как получить из «Ссылки» или из ключа «Данные» объекты – это мы все знаем, все умеем.

 

Администрирование триггеров

 

 

Часто возникает вопрос: «Что делать, если у нас реструктуризация? Куда денутся эти триггеры? Слетят, не слетят? И вообще, что с этим делать?»

По ссылочным объектам – сразу скажу, ничего не произойдет.

По регистрам при реструктуризации мы можем увидеть сообщение: «Регистрация изменена» – это означает, что произошла реструктуризация таблицы регистрации изменений. Это может произойти, например, когда изменился ключ записи регистра сведений – если мы добавили измерение или удалили, будет реструктуризация.

На слайде показано, что происходит в 1С при реструктуризации. Сначала создается новая таблица, в нее переносятся данные, потом старая таблица удаляется через DROP TABLE, а новая таблица с перенесенными данными переименовывается в старое название.

Поскольку DROP TABLE удаляет все триггеры, с этим нужно что-то делать. Но, если помните, там была кнопка «Включить тюнинг планов обмена» – ровно так же нажимаем кнопку, и все триггеры восстанавливаются.

Причем сзади к этим кнопкам прикручен веб-API, как мы помним. То есть в принципе можно кнопку не нажимать – можно дергать этот скрипт из Postman или CURL. Обновили базу данных, реструктуризация прошла, дернули скрипт по веб-API – у нас триггеры восстановились. Это тоже решаемая проблема.

Таким образом, тюнинг планов обмена позволяет решить проблему блокировок, но требуется адаптация кода выгрузки – это, наверное, самая большая проблема.

По ссылке вы можете скачать релиз платформы DaJet с демобазой 1С.

Платформа DaJet позволяет решать еще много других задач – смотрите обучающие видео, изучайте выложенные материалы и пользуйтесь.

Когда все совсем плохо с планами обмена – есть готовое решение. Можно взять и использовать. Это решение с открытым исходным кодом. Единственное ограничение – на его основе нельзя делать коммерческие продукты.

 

Вопросы

 

Получается, что платформа 1С регистрирует изменения в отдельных таблицах для каждого из метаданных – справочников, документов, регистров. А вы создаете один регистр сведений, который является сборным для всех справочников и документов. И чем их больше, тем у нас больше записей туда будет писаться. Что происходит при повторной перезаписи документа?

Будет еще одна запись в регистре сведений. Сколько регистраций летит в план обмена, столько же записей будет в регистре сведений.

Но в таблице регистрации у вас может быть одна запись по объекту, а в регистре сведений таких записей может быть много. Как с этим бороться, я уже сказал – при выборке мы можем сжать поток данных группировкой по Узлу и Ссылке.

Когда обмен успешно прошел, мы должны удалить записи регистрации. Чтобы их найти, у нас есть поле вектор. Выбираем первые 10000, и там не зря была актуальная версия, МАКСИМУМ(Вектор) – вы знаете, по какой вектор вы уже выбрали. Обработали, и все, что меньше этого вектора, просто удалили.

А как получить подтверждение с узла, что этот обмен успешен, что они приняли наш пакет данных?

Обычно из таких регистров сведений данные передаются, например, в брокер – в RabbiMQ или в Apache Kafka. Там применяется паттерн Transactional Outbox плюс Polling publisher. Рекомендую ознакомиться, почитать в Интернет, найти, что это такое.

Это работает следующим образом:

  • Открывается транзакция в СУБД.

  • Выбираются данные для обмена и запихиваются в брокера.

  • Если от брокера получается подтверждение, транзакция закрывается.

  • Если в этом процессе происходит ошибка, транзакция в СУБД откатывается, все записи возвращаются в очередь.

Этот паттерн называется Outbox.

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

Но если мы откроем транзакцию, мы же тоже будем иметь блокировку для записи?

Если вы не будете параллельно обрабатывать одни и те же сообщения, ожиданий на блокировке не будет.

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

У нас вообще в один поток все выгружается – весь этот один регистр со всеми объектами в системе, которые там зарегистрировались, выгружается в один поток в Kafka или в RabbitMQ. И очень редко бывает, когда в этом регистре есть записи. DaJet умудряется в одном потоке успевать выгружать всё, что бы там на центральном сервере ни зарегистрировали.

Это получается асинхронная отправка?

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

И удаление записей из этого регистра у меня выполняет не 1С, а DaJet на уровне SQL.

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

Как осуществляется изоляция вектора, что нет двух записей с одним и тем же вектором?

Это гарантирует ядро СУБД. SEQUENCE – это объект СУБД, который гарантированно при многопоточной конкурентной нагрузке всегда выдает один вектор, чтобы дублей не было. Именно поэтому этот объект и используется.

В свое время мы использовали UTC время, которое 1С генерирует с точностью до миллисекунды. Вот у нас были ситуации, когда в одну миллисекунду было 10 регистраций. SEQUENCE помогает с этим разобраться.

Решение DaJet уже где-то используется?

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

Я могу рассказать о нашей ситуации. У нас был РИБ на 50 узлов – и там обмены просто вставали, актуальность данных на узлах отставала от центральной базы от часа и выше. Для онлайн-торговли это абсолютно неприемлемо.

Сначала мы там реализовали другую методику – через регистр сведений и свои подписки на события, чтобы потом через RabbitMQ раскидать это все по нашей РИБ-овской сети.

Сейчас мы применили DaJet и это позволило масштабироваться с 50 до 300 узлов. При этом актуальность данных на узлах у нас сейчас меньше 10 секунд. Бывают всплески, когда 5000 сообщений в очереди – это уже аларм летит. В такие всплески у нас актуальность данных может быть на узлах до 5 минут. Но обычно там пусто – DaJet разгребает все эти очереди очень быстро.

Т.е. мы с РИБа собирались переходить, а я на досуге подумал: «А зачем с РИБа переходить? РИБ у всех есть. Нельзя ли как-то еще по-другому это сделать?» И придумал такой вариант – он тоже рабочий.

А CDC-механизм почему не попробовали? Там же почти онлайн получается?

На Инфостарте есть замечательная статья Юрия Пермитина по поводу CDC в 1С. Ознакомьтесь, я вам советую. Эта статья сейчас под авторством Инфостарта, т.к. Юра Пермитин, к сожалению, покинул наше сообщество и все свои статьи передал Инфостарт.

У него в статье очень подробно расписано, как можно применить CDC для 1С. Но там есть ряд минусов:

  • В случае реструктуризации и изменения структур данных CDC надо перенастраивать. Для этой цели у Юры сделана подсистема, которая автоматически это все делает прозрачно для 1С – вы можете реструктуризироваться, как хотите, а его подсистема это все поддерживает.

  • И CDC, опять же, регистрирует изменения в таблице SQL, где все поля называются так, как мы «любим»: Fld***, VT*** и т.д. Работать с этим неудобно.

Да, CDC – это хорошая вещь. У PostgreSQL это называется логическая репликация – тоже замечательная вещь. Для работы с ней есть Kafka Connect. Мы берем Kafka Connect и настраиваем его на СУБД. В PostgreSQL Kafka Connect работает как раз с логической репликацией. И она прекрасно вам будет это все в Kafka загонять.

Но, опять же, вопрос, а что делать с этими Fld*** и прочее? Проблема.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

 

10 - 12 октября 2024 года состоится конференция INFOSTART TECH EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Приемы, методы разработки и тестирования
  • DevOps-практики, управление инфраструктурой разработки
  • Интеграция и обмен данными
  • Идеи и тренды в разработке 
  • Администрирование серверов 1С и СУБД. HighLoad оптимизация  
  • Развитие технической команды. Личная эффективность разработчика 

INFOSTART TECH EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


См. также

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен и синхронизацию в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

25080 22572 руб.

12.06.2017    137972    759    292    

404

Перенос данных 1C Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) в продаже с 2015 года, постоянно работаем над их развитием | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

45650 руб.

04.08.2015    162627    367    273    

358

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос данных из ERP в БП 3 | из КА 2 в БП 3 | из УТ 11 в БП 3 | из ЕРП в БП 3 | В продаже с 2019г. | Воспользовались более 176 предприятий! | Сэкономьте время - используйте готовое решение для перехода! | Перенос разработан в формате КД 2 (правила конвертации данных) | Переносятся все возможные виды документов, начальных остатков и нормативно-справочная информация| Можно опционально выгружать каждую пару "номенклатура+характеристика" как отдельную номенклатуру | Есть выгрузка настроек счетов учета и зарплатных данных из ERP / КА 2 | Можно проверить на вашем сервере перед покупкой, обращайтесь!

45650 руб.

15.04.2019    70165    173    146    

115

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.228.x) и БП 3.0 (3.0.154.x). Правила подходят для версии ПРОФ и КОРП.

28000 руб.

15.12.2021    21721    143    40    

104

Перенос данных 1C Системный администратор Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

В продаже с 2014г. | Воспользовались более 122 предприятий! | Перенос данных из БП 3.0 в УТ 11 | из БП 3.0 в КА 2 | из БП 3.0 в ERP | Сэкономьте свое время - используйте готовое решение для перехода! | Постоянно работаем над развитием переноса данных | Обновляем на новые релизы 1С | Есть фильтр выгрузки по организациям | Переносятся начальные остатки на выбранную дату, документы за период времени и вся возможная справочная информация | Перенос сделан на технологии КД 2 (правила конвертации данных)

45650 руб.

31.10.2014    234023    93    330    

301

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 Бухгалтерский учет Управленческий учет Платные (руб)

Переход и перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:ERP Управление предприятием 2.5 и 1С:Комплексную автоматизацию 2.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.227.x), ERP 2.5 (2.5.16.x), КА 2.5 (2.5.16.x) .

28000 руб.

24.06.2020    62302    50    27    

80

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3.87.x и УТ 11.5.16.x

28000 руб.

23.07.2020    48331    208    64    

170

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 Платформа 1C v8.2 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Управление производственным предприятием Россия Платные (руб)

Регулярный обмен, выгрузка, перенос из КА 1.1, УПП 1.3, УТ 10.3 для обмена с любыми конфигурациями, поддерживающими обмен в формате EnterpriseData (КД3) - БП 3.0, ERP, КА 2, УТ 11, Розница 2, УНФ 1.6 и другими. Правила для старых и доработанных конфигураций не требуют синхронного обновления и совместимы с новыми и будущими конфигурациями. Обмен по расписанию, через папку, FTP, почту.

14580 руб.

18.02.2016    184447    572    509    

516
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. aximo 2047 08.07.24 11:54 Сейчас в теме
В свое время, 5 лет назад, я описал - как можно использовать регистры сведений - для ускорения регистраций изменений... https://infostart.ru/1c/articles/1142470/

а тут выдается как некий "тюнинг" :)))))
7. zhichkin 1501 08.07.24 22:50 Сейчас в теме
(1) Спасибо, что напомнили о Вашей статье. Думаю, что в связи с этим будет уместно ещё раз упомянуть публикацию Планы обмена 1С (раздел "Альтернатива планам обмена"), ссылка на которую приводится в самом начале этой статьи. Можно сказать, что данная публикация является продолжением темы планов обмена.
2. mefalcon 27 08.07.24 14:15 Сейчас в теме
Классный инструмент. А как быть с лицензионной политикой фирмы 1С, которая требует использовать для манипуляций с субд только средства платформы 1с. Ваша компания, получается, не пользуется линией поддержки вендора? Как этоорганизационно у вас в компании решено? Спасибо :)
6. zhichkin 1501 08.07.24 22:21 Сейчас в теме
(2) Прошу прощения, но юридические вопросы не входят в сферу моих компетенций.
11. mefalcon 27 09.07.24 10:48 Сейчас в теме
(6) Спасибо за ответ, Дмитрий.
Среди ответов на типовые вопросы по лицензированию ( https://v8.1c.ru/priobretenie-i-vnedrenie/otvety-na-tipovye-voprosy-po-litsenzirovaniyu-1s-predpriyatiya-8/? )
есть ответ про использование собственных инструментов. выдержка из вопроса такая :
"Для реализации своих задач организация предполагает изменить структуру некоторых таблиц базы данных. Также предполагается использовать хранимые процедуры и триггеры для реализации обработки данных. ... Имеет ли организация право вносить в систему перечисленные изменения?"
Ответ такой:
"Лицензионное соглашение не позволяет использовать недокументированные фирмой «1С» средства для построения решений на платформе «1С:Предприятие». Это означает, что средства СУБД (или любые другие внесистемные средства) можно использовать только в том случае, если документация по продуктам линейки «1С:Предприятие» (включая 1С: ИТС) содержит явную рекомендацию использовать данное средство для решения данной задачи."


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

Поэтому вопрос: Вы или ваша организация не обращались к вендору с просьбой изучить Ваш инструмент, чтобы разместить информацию о нем в документации.
Есть кейсы позитивные в этом ключе, например: частная разработка - Vanessa automation, признанная сообществом разработчиков и консультантов как один из самых удобных инструментов автоматизированного тестирования функционала, и размещенная о ней в документации фирмы 1с информация))
12. zhichkin 1501 09.07.24 11:44 Сейчас в теме
(11) Спасибо за уточнение. По этому поводу было сломано огромное количество копий. По итогу, особенно с возрастом, мне это "бодание" перестало быть интересным. Я занимаюсь исключительно исследованием и решением технических проблем. Погружаться в юридические тонкости, а тем более переговоры, у меня нет никакого желания.

Если Вам это интересно, то могу рекомендовать ознакомиться с юридическим анализом того пункта ЛС, который Вы приводите в качестве примера. Может быть найдёте там что-нибудь интересное для себя.
starik-2005; mefalcon; +2 Ответить
13. starik-2005 3060 10.07.24 11:20 Сейчас в теме
(2)
Ваша компания, получается, не пользуется линией поддержки вендора?
Что-то не помню, чтобы вендор хоть раз в своей истории что-то там поправил с помощью линий консультаций своих, а не с помощью сильно следующего релиза, в который внес вместе с исправлением новые ошибки.
3. kauksi 217 08.07.24 17:15 Сейчас в теме
сложный непонятный велосипед. наверно полезен в трудных случаях, 100+ узлов. я ни разу таких пациентов не встречал.
5. zhichkin 1501 08.07.24 22:18 Сейчас в теме
(3) Спасибо за Ваш отзыв. Уточните, пожалуйста, в чём Вы видите "велосипедность" решения ? Поделитесь ссылками на какой-нибудь аналог. Лично мне ничего, кроме решения DB Replication от компании Softpoint, в голову не приходит...
8. kauksi 217 09.07.24 07:48 Сейчас в теме
(5) Это не ругательство, а констатация факта. Чтобы использовать такие инструменты, нужно научиться на них ездить, но это далеко не всем нужно. Поэтому за глубину знаний и статью об этом большой респект!
4. Dormouzze 08.07.24 22:17 Сейчас в теме
Очень сильная статья. (1) такое ощущение, что вы не совсем поняли проблематику, можно ранние статьи автора глянуть по этим вопросам, там многие вещи подробнее написаны)
9. fancy 35 09.07.24 07:57 Сейчас в теме
Поправьте опечатку
ПланыОбмена.ВыбиратьИзменения(…)
10. vikad 130 09.07.24 09:27 Сейчас в теме
14. Silenser 609 11.07.24 11:41 Сейчас в теме
Если я правильно понимаю суть проблемы, которую вы описали, то она заключается в том, что мы страдаем от избыточных блокировок потому, что:
1. У нас сильно нагруженный объект метаданных, по которому постоянно пишутся изменения и мы имеем повышенный риск блокировки или эскалации блокировок.
2. Из-за большого числа изменений мы должны часто делать выгрузку изменений, что приводит к блокировке из-за интенсивной записи изменений.

Наиболее объемной будет именно выгрузка, т.к. она будет пытаться выгрузить все невыгруженные ранее изменения, тогда может разделить эти процессы? Делаем два плана обмена, в один будут приходить платформенные изменения, которые мы будем выбирать неблокирующим образом, например через запрос. Потом, через регламент, перенесем эти изменения во второй план обмена, из которого и будем делать типовую выборку изменений. Таким образом мы исключим длинную типовую выборку изменений из нашей схемы, немного распараллелив процесс, а во второй план эти изменения будут приходить порционно, что не будет приводить к пересечению выборки и записи изменений. Правда в этом случае может образоваться очередь на перекачку изменений из 1го плана во 2й.
Или, я может не совсем уловил проблематику...
15. zhichkin 1501 11.07.24 13:40 Сейчас в теме
(14) Проблематику Вы уловили верно. Методика использования 2-х планов обмена или 2-х узлов известна давно. Например, существует видео Блокировки при обмене данными для подготовки 1С:Экспертов.
Как такое комментировать... На мой вкус это костыль, который порождает ряд других не вполне очевидных проблем. Например, не вдаваясь в глубокий анализ, хочется спросить первое, что приходит в голову: а как понять когда и что можно уже удалить (снять с регистрации) из основного плана обмена или узла ? Ответ на этот вопрос не так уж прост...
Однако, резюмируя, если кому-то эта методика помогает, то почему бы и нет - используйте ¯\_(ツ)_/¯ Всё-таки вендор рекомендует...
16. mikukrnet 182 12.07.24 16:15 Сейчас в теме
Может, разработчики платформы все-таки что-то знали когда отказывались от общего журнала документов и таблицы регистрации изменений сделали свою под каждый объект?

Опять общий регистр на всех, в котором предлагается при случае удалять по 10к записей )
17. zhichkin 1501 12.07.24 17:20 Сейчас в теме
(16) Практика эксплуатации, представленной в публикации технологии, свидетельствует о том, что одного регистра сведений вполне хватает для интенсивного обмена данными, измеряемого десятками миллионов сообщений в сутки. При правильной реализации и эксплуатации такой регистр почти всегда остаётся пустым или имеет в пиках не более 5000 записей-сообщений. Средний размер одного сообщения - 3 Кб в формате JSON. Максимально наблюдавшийся размер сообщения - 70 Мб. Средняя скорость отдачи сообщений из регистра сведений, в зависимости от их размера, во внешние транспортные системы, например, RabbitMQ или Kafka - несколько тысяч в секунду.

Дополнительный видео материал для изучения применимости технологии: РИБ 2.0 (методика).
Оставьте свое сообщение