Взаимодействие 1С со сторонними продуктами посредством REST и Golang (middleware). Часть 3 - ElasticSearch

18.06.21

База данных - Журнал регистрации

+18 –
> > > > >
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
  • image.png
Как в статье №1 этого цикла выгрузим через прослойку журнал регистрации (xml формат) в ElasticSearch. Статья будет иметь практическую направленность в минималистичном стиле

Предыдущие и будущие статьи:

Видел на этом ресурсе, как некоторые выгружают журнал в файлы, потом специальной утилитой эти файлы парсят и помещают в ElasticSearch. Видел, как из таблицы СУБД с журналом регистрации выбирались записи для ElasticSearch. У меня есть своя идея. В этой статье мы воспользуемся функцией глобального контекста ВыгрузитьЖурналРегистрации(), а полученный XML-файл отправим в прослойку через HTTP-запрос методом POST. На стороне прослойки распарсим файл и передадим полученную структуру в ElasticSearch. В итоге посмотрим полученный результат в веб-интерфейсе Kibana

Для тестирования делаем обработку с отборами по датам для журнала и командой отправки.

Запускал все это дело в демо ERP на Платформе 8.3.16.1502

Для парсинга XML в прослойке я воспользовался пакетом "github.com/beevik/etree"

А для работы с ElasticSearch - пакетом "github.com/olivere/elastic"

В настройки прослойки вывел адреса ElasticSearch и имя индекса

Видим, что данные пришли в ElasticSearch, накладываем какой-нибудь отбор

Исходники 1С обработки и прослойки на GitHub https://github.com/dmitry-msk777/Connector_1C_Enterprise

ОБНОВЛЕНИЕ 06.10.2020

Протестировал загрузку на файле журнала 2GB - 2 000 000 записей, переписал алгорим парсинга XML под функцию xml.Unmarshal, а запись в ElasticSearch под bulk по 10 000 записей за раз.

Производительность стала приемлемой на рабочем компьютере с 8GB и простеньким процессором: парсинг файла 6 минут, загрузка в Elastic 10 минут.

Обнаружил также проблему у функции глобального контекста ВыгрузитьЖурналРегистрации() если в параметр МаксимальноеКоличество задавать число меньшее 10 000, то он все равно будет всегда грузить 10 000. Узнал я это когда начал парсить выгружаемые файлы. В СП информации этой нет, в методической информации тоже нет. В начале я решил, что этот параметр не работает, когда вместо 50 записей, которые я хотел выгрузить, в XML оказалось 10 000

ОБНОВЛЕНИЕ 11.10.2020

Для файлов XML при отправке в прослойку добавлено zip-сжатие, это позволило например уменьшить файл с данными с 494MB до 32МБ

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

 

Вступайте в нашу телеграмм-группу Инфостарт

Golang RESTapi middleware ElasticSearch

+18 –

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Версионирование справочников, документов и регистров сведений на SQL-сервере

Журнал регистрации Системный администратор 1С:Предприятие 8 1C:Бухгалтерия Россия Платные (руб)

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

23180 руб.

22.02.2018    38583    63    56    

58
LogiCH - хранение и анализ журнала регистрации в сверхбыстрой СУБД ClickHouse

Журнал регистрации Системный администратор 1С:Предприятие 8 1C:Бухгалтерия Платные (руб)

Конфигурация LogiCH эффективно решает проблему хранения и анализа записей журналов регистрации. Разработка использует столбцовую СУБД ClickHouse, одну из самых быстрых Big Data OLAP СУБД. Любой анализ журнала можно выполнить в одном отчете, в котором доступны все возможности СКД с учетом ограничений RLS. Количество подключаемых баз не ограничено и не влияет на скорость построения анализа.

6100 руб.

28.11.2018    24208    23    9    

49
ClickHouse и Журналы регистрации 1С: анализ в реальном времени – опыт Magnit Tech

Журнал регистрации Бесплатно (free)

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

28.02.2026    2621    julia96_07    0    

12
Сравнение парсера журнала регистрации Vector и ibcmd

Журнал регистрации Программист Россия Бесплатно (free)

В материале рассматривается сравнение двух инструментов для работы с журналом регистрации 1С: утилиты ibcmd и платформы Vector. Описаны их функциональные возможности, тестирование производительности и практическое применение для преобразования логов в формат JSON.

20.11.2024    7038    user1913000    13    

26
Логирование в приложениях

Журнал регистрации Тестирование QA Программист Бесплатно (free)

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

21.10.2024    8235    leemuar    8    

25
Регламентное сокращение журнала регистрации

Инструменты администратора БД Журнал регистрации Системный администратор 1С:Предприятие 8 1С:Управление торговлей 11 Абонемент ($m)

Внешняя обработка для регламентного сокращения журнала регистрации для конфигураций на базе БСП и платформы 8.3.20+

1 стартмани

29.12.2023    5051    61    dima_gsv    6    

15
Магия преобразований Vector, часть 3: журнал регистрации + прямой экспорт ошибок в Sentry

Журнал регистрации Мониторинг Системный администратор Программист Абонемент ($m)

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

1 стартмани

19.11.2023    4175    9    AlexSTAL    0    

8
Магия преобразований: ЖР, ТЖ, RAS/RAC, логи - универсальное решение Vector

Мониторинг Журнал регистрации Технологический журнал Системный администратор Программист Абонемент ($m)

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

1 стартмани

13.11.2023    9340    15    AlexSTAL    0    

48
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Shmell 660 22.09.20 12:12 Сейчас в теме
Интересный подход. Вопрос на уточнение - какая периодичность хранения ЖР? При полном включенном журнале и 100+ одновременно работающих пользователях - размер журнала может начинаться от 1 ГБ и стремиться к бесконечности. Чем больше по размеру xml файл - тем он дольше по времени парсится. В статье еще хотелось бы увидеть замеры по времени, а точнее корреляцию между объемом журнала и временем занесения записей в elastic (какой подход используется в пакете - построчный put или bulk insert)
+ – Ответить
2. dmitry-irk38 139 22.09.20 13:00 Сейчас в теме
(1) Ограничений на время соединения и размер передаваемого тела (с файлом) не устанавливал, попробую прогнать какой-нибудь большой журнал с большим файлом.

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

По поводу метода "построчный put или bulk insert" поглядел, вероятно это put потому что каждое событие отдельно грузится в Elastic, попробую использовать bulk insert.

Как Вы думаете какое количество времени допустимо для выгрузки большого журнала регистрации?
+ – Ответить
3. Shmell 660 23.09.20 09:01 Сейчас в теме
(2) по фоновым заданиям - это подход хороший, но нужно будет контролировать целостность выгрузки, т.к., например, какое-либо фоновое может отвалиться.

по времени - тут все зависит от требуемой частоты анализа/просмотра ЖР, вернее от частоты актуальности, если нужно что бы каждые 5 минут заносилась при инкрементном подходе свежая порция данных из ЖР - то это одна тех реализация и, скорее всего, ВыгрузитьЖурналРегистрации() не подойдет, а если частота - сутки, то другая, где использование данной процедуры вполне приемлемо.

Тем не менее, я считаю, что для суточного анализа - Ваш подход хорош.
+ – Ответить
4. dmitry-irk38 139 06.10.20 20:59 Сейчас в теме
(3) Протестировал производительность 2 миллиона записей примерно 2GB грузились 3 часа, а с bulk insert по 10 000 записей в порции, за 10 минут.

Сейчас 2 GB грузит за 15 минут, 5 минут на парсинг XML, его тоже пришлось переписать т.к старый алгоритм падал на 1GB (недостаточно памяти).

Возможно, можно еще ускориться если поставить на сервер и поиграть с размером bulk insert, но 15 минут для журнала 2GB кажется приемлемым.

Можно еще попробовать сживать файлы в Zip, чтобы по сети они быстрей передавались если это все на разных физических\логических машинах размещается.
Shmell; user1464234; +2 – Ответить
Для отправки сообщения требуется регистрация/авторизация