Мотивом для появления данного исследования послужила твёрдая уверенность автора в том, что потоковая обработка данных в режиме реального времени является наиболее актуальной и востребованной задачей на сегодняшний день.
Данное требование заставляет искать наиболее эффективные способы организации потока данных, генерируемого в режиме реального времени или по возможности максимально близко к этому, на основании тех изменений, которые происходят в базах данных.
Предварительные результаты исследования механизма истории данных 1С:Предприятие 8 свидетельствуют о том, что данный механизм может быть перспективным кандидатом для решения выше обозначенных задач.
История изменения конфигурации фиксируется для каждого объекта метаданных, для которого включено использование этого механизма. Запись версий выполняется в таблицу DataHistoryMetadata.
Изменение данных прикладных объектов захватывается и фиксируется в таблице DataHistoryQueue0. Фиксация выполняется в основной транзакции записи объекта перед самым её завершением после записи в таблицы регистрации изменений планов обмена.
Таблица DataHistoryQueue0 играет роль классической таблицы-очереди, для которой разрешено только добавление записей, что исключает возможность возникновения каких бы то ни было блокировок. Это делает её практически идеальным кандидатом для организации потоковой интеграции или обработки данных.
Следует отметить, что каждая запись объекта порождает новую версию данных в этой таблице независимо от того изменились они или нет. Однако проблему дублирования данных можно решить при помощи поля DataId, выполняя по нему группировку (сжатие потока данных).
Захваченные механизмом данные кодируются в собственном бинарном формате и сохраняются в поле Content соответствующих таблиц DataHistoryMetadata и DataHistoryQueue0. Далее приводится пример кодирования в этом формате для простого справочника "ИсторияДанных", который использовался для проведения исследования. Надо сказать, что формат кодирования вполне доступен для понимания и создания практичных алгоритмов его обработки.
Предварительные выводы:
1. Таблица DataHistoryQueue0 это почти идеальная таблица-очередь.
2. Механизм истории данных будет явно производительнее любого аналогичного способа регистрации изменений объектов в регистрах сведений, а также механизма планов обмена.
3. Механизм истории данных можно использовать для потоковой интеграции и обмена данными даже в высоко нагруженных системах.
4. Историю данных можно экспортировать для анализа во внешние системы без их накопления в таблице DataHistoryVersions.
5. Предварительно кажется, что использование механизма истории данных для целей потокового обмена данными и прочей интеграции выглядит очень перспективным.
Вспомогательная информация:
2. Protocol Buffers data encoding to the wire
3. Версионирование объектов VS История данных
