Что делать, когда обмены между разными базами данных портят вам жизнь…

Если при обмене между базами данных наблюдаются следующие симптомы:

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

То, скорее всего, вы используете конфигурацию «Конвертация данных». Неважно, какой редакции. Все отличие КД 2.0 от КД 3.0 в удобстве отладки и поиска ошибок (см. выше п. 3).

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

Чуть ниже, я расскажу вам, как навсегда забыть проблемы связанные со словом ‘обмен’.

История проблемы и как пришло осознание того, что нарыв созрел и его пора вскрывать.

Две нетиповых базы данных (условно обзовем их БД1 и БД2):

• В направлении БД1 -> БД2 передаются данные о нормативно справочной информации (НСИ).
  Все справочники создаются только на стороне БД1.
• В направлении БД2 -> БД1 передается информация по кассовым документам. Объем передаваемых данных составляет около 400 000 документов в сутки или, в пиковые периоды, до 150 документов в секунду.
• Объем файла обмена в пределах 0.7 – 2 Гб. Файл обмена транслируется через файловый ресурс.

С какими проблемами сталкивались:

• Общее время обмена, за сутки, составляло порядка 15-20 часов. До 20% времени уходило на формирование и передачу файла обмена (на стороне источника).
• Часть, из этого, уходила на запись файла обмена на дисковое пространство.
• Еще большая часть, уходила на запросы к БД в цикле (таков принцип работы конфигурации «КД»)
• Периодически, приходилось «резать» файл обмена на части, и проталкивать его в КИС руками.
• В КД 2.0 (КД 3.0), пока не загрузился весь файл обмена, обмен не может считаться успешно состоявшимся.
• Поэтому, если при загрузке данных, по 400 тысячам документов, хотя бы с одним документом произошел сбой – весь процесс обмена приходилось запускать заново.
• Поиск ошибок обмена превращался в неблагодарный труд (вспомните добрым словом КД 2.0).

Как решали проблему и что это дало на выходе.

Если кратко, то выполнили следующее:

• Отказались от использования конфигурации КД 2.0, в направлении БД2 – БД1 (трансляция кассовых документов).
• Сбор данных отправки производится одним пакетом запросов к БД. Собранные данные трансформируются в строку JSON.
• В базу-приемник данные передаются посредством HTTP-запроса.
• Запись документов, в базу-приемник, производится без проведения и в несколько потоков.
• Само проведение документов запускает специальный механизм отложенного проведения документов.

Более подробно, все технические аспекты – это тема отдельной публикации (планируется отдельно).

Результаты оптимизации обмена данными:

• Все вышеперечисленное позволило организовать обмен данными фактически в режиме online. Частота обмена данными составляет 10 минут.
• Среднее время транспорта 400 000 документов составляет не более 2ч. 30 минут.
• Возможные ошибки передачи данных не прерывают транспортировку всего потока.
• Простота поиска и локализации ошибок кода конвертации.

Но, это тоже еще не все! Есть еще и вишенка на тортике!

Мы решили не останавливаться на достигнутом и поставили себе целью сократить суточное время обменов до полутора часов! Возможно ли это?!

Мы помним, что в моменты пиковых нагрузок, количество одновременно проводимых документов доходит до 150 шт/сек. При данной интенсивности записей очень большую роль играет повышение параллельности работы системы, а именно – сокращению времени транзакционных блокировок.

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

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

Вынеся, все данные процедуры, за пределы транзакции, мы добились сокращения времени платформенной транзакции до…… Внимание! – 0.003 сек!

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

Этим самым мы ставим себе целью:

• Разгрузить кластер серверов, снизив количество запросов с 400 000 до 288 запросов в сутки.
• Снизить количество взаимоблокировок базы данных
• И, в конечном итоге, снизим на порядок время проведения пакета документов.

В качестве резюме

Конфигурации «Конвертация данных 2.0» (КД 3.0) – отличные универсальные инструменты. Но, они крайне не готовы к работе с регулярными и большими объемами данных.

Сбор необходимых данных (одним запросом) для последующей online-передачи, может быть решением проблемы.

При пакетном проведении документов:

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

Данная методика позволяет повысить производительность системы в тысячу и более раз.