Идемпотентные потоки или предотвращение дублирования строк с помощью PipelineDB

Мое приложение создает вращающиеся файлы журналов, содержащие несколько показателей приложения. Файл журнала меняется раз в минуту, но каждый файл по-прежнему относительно большой (более 30 МБ, со 100 тыс. строк).

Я хотел бы передавать журналы в PipelineDB (работающую на том же одном компьютере), которую Countiuous View может создать для меня именно те агрегации, которые мне нужны по метрикам.

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

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

Как я могу гарантировать, что каждая строка в моих журналах вставляется ровно один раз в таких случаях? (Очень важно, чтобы я получал полные и точные агрегаты)

Обратите внимание, что каждая строка в файле журнала имеет уникальный идентификатор (серийный номер, созданный моим приложением), но я не могу найти в документах возможность определить уникальное поле в потоке. Я предполагаю, что дизайн PipelineDB не предназначен для обработки уникальных полей в строках потока.

Тем не менее, есть ли альтернативные решения этой проблемы?


person Shmulik Asafi    schedule 09.05.2018    source источник


Ответы (1)


Семантика ровно один раз в потоковом (бесконечные строки) контексте представляет собой очень сложную проблему. Большинство крупных развертываний PipelineDB используют некоторую инфраструктуру шины сообщений (например, Kafka) перед PipelineDB для семантики доставки и надежности, поскольку это не основное внимание PipelineDB.

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

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

Во-вторых, вы можете разделить свои агрегации по файлу журнала (включив путь или что-то еще в группировку) и просто DELETE любые существующие строки для этого файла журнала перед его отправкой. Затем используйте combine для объединения всех файлов журналов во время чтения, возможно, с VIEW.

person Derek Nelson    schedule 09.05.2018
comment
Спасибо за практические советы по моему скромному варианту использования :) - person Shmulik Asafi; 11.05.2018