Как организовать запись событий приложения в удаленное хранилище?

Question

[bakomchik]

Задача: организовать RealTime мониторинг процессов системы реального времени.
Стек:

• java
  
• ejb,
  
• hibernate
  
• postgres
  

Особенности: долгие транзакции, нагрузка ~100rps
Сценарий:
В приложении происходят события (~100rps ), изменяющие сущность(набор сущностей) в базе данных (Postgres).
Данные событие (1) необходимо отправить на удаленный сервер (2) , там его обработать( десериализовать,проверить и подготовить к записи) (3) , и отразить изменения в хранилище (4) , для того чтобы в отдельном приложении сделать RealTime мониторинг (javascript, middleware).

Требования:

• События передаются и обрабатываются в порядке их возникновения
  
• Необходима гарантированная доставка событий
  
• В дальнейшем необходимо горизонтально масштабировать
  
• Нужно Schemaless решение
  

Сразу оговорюсь , что пробовали решать "инфраструктурно", репликацией БД, но результаты не удовлетворительные , реплика отстает на 5-10 минут, из за объема данных и не очень хорошего канала.

Собственно открытые вопросы:

1. Формат и протокол : В каком формате передавать (binary,json,bson), какой "сериализатор" использовать (avro,thrift,jakson,protobuf)?
   
2. Передача : Что использовать в кач-ве транспорта (rabbitmq,kaffka,thrift rcp,http)?
   
3. Процессинг : Как "low latency" обрабатывать события, что использовать (akka,desruptor,plain java)?
   
4. Хранение: Какое хранилище использовать?
   

_______________________________________________________________________
Пока сформировалось такое видение архитектуры:

• Формат: json
  
• Tranport: Apache Kaffka
  
• Процессинг : Akka(java)
  
• Хранение : MongoDB
  

Сценарий :

1. происходит событие
   
2. Используя CDI-events, при коммите транзакции событие сериализуется в JSON
   
3. Далее событие публикуется в топи Kaffka
   
4. Удаленный сервер, Akka, забирает сообщение из топика, выполняет проверки
   
5. Далее событие сохраняется в Mongo
   

Уважаемые коллеги, мне необходим совет и критика данного решения, или альтернативные варианты архитектуры.
Может кто-нибудь имел опыт решения подобных задач.
Заранее спасибо!

Answer 1

[Алексей Черемисин]

Ну, а что у вас конкретно тормозит? Выборка из базы, передача, процессинг или обновление "хранилища"?
Здесь же универсального решения быть не может. В каких-то случаях можно пренебречь промежуточным хранением до завершения "длинной" транзакции, в каких-то это не очень хорошо.
Попробуйте все промежуточные данные о событии хранить в key-value базе типа redis.

Comments

[bakomchik]

"Ну, а что у вас конкретно тормозит? Выборка из базы, передача, процессинг или обновление "хранилища"?" -- решения готового пока нет.
На данный момент приложение Мониторинга делает запросы в БД с которой работает логика бизнес приложения. Запросов очень много и они очень развесистые(да мы их оптимизировали как могли) и занимают чуть ли ни 70% времени БД
Исходя из этого появилась необходимость в промежуточном хранилище.

"Попробуйте все промежуточные данные о событии хранить в key-value базе типа redis." : уже думали об этом, но не совсем подходит(не распределяем из коробки, плохо кластеризуется, да и данные выбирать надо по запросам а для этого hash не подходит)

[bakomchik]

Спасибо за ответ.

[Алексей Черемисин]

bakomchik: из коробки ничего не распределяемо, ну а редис очень даже неплохо кластеризуется. Ну и если нужно много разных данных выбирать, elasticsearch вам в помощь! Ну или монго, я за эластик.