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

18.06.21

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

+17 –
> > > > >
  • 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

+17 –

См. также

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

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

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

22800 руб.

22.02.2018    35916    59    54    

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

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

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

6000 руб.

28.11.2018    21273    18    7    

43
Журнал регистрации получения работниками расчетных листков

Зарплата Журнал регистрации Бухгалтер Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 2.5 1С:Зарплата и кадры бюджетного учреждения 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Бухгалтерский учет Бюджетный учет Платные (руб)

Журнал регистрации получения работниками расчетных листков (реестр получения расчетных листков), позволяющий подтвердить при проверке факт выдачи расчетного листка в соответствии со ст.136 ТК РФ.

1200 руб.

30.09.2013    76839    58    12    

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

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

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

20.11.2024    1797    user1913000    12    

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

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

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

21.10.2024    3850    leemuar    8    

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

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

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

1 стартмани

29.12.2023    2569    40    dima_gsv    3    

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

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

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

1 стартмани

19.11.2023    1795    6    AlexSTAL    0    

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

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

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

1 стартмани

13.11.2023    5537    11    AlexSTAL    0    

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

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

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

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

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

Тем не менее, я считаю, что для суточного анализа - Ваш подход хорош.
+ – Ответить
4. dmitry-irk38 137 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 – Ответить
Оставьте свое сообщение