Зафиксировать в журнале, таком как база данных Kafka +, со свойствами ACID?

Я планирую в тесте, как заставить эту архитектуру работать:

http://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/

Где все данные хранятся как факты в журнале, но проверки при публикации изменения должны проводиться по таблице. Например, если я отправлю «Создать счет-фактуру с клиентом 1», мне нужно будет проверить, существует ли клиент и другие вещи, а затем, когда проверка проходит, фиксируется в журнале и помещается текущее изменение в таблицу, чтобы таблица имела самая актуальная информация пока у меня есть вся история изменений.

Я мог бы поместить логи в базу данных в виде таблицы (я использую PostgreSql). Однако меня беспокоит масштабируемость этого, кроме того, я хочу подписаться на поток событий от нескольких клиентов, и PG ни одна другая РСУБД, которую я знаю, не позволяла мне делать это без опроса.

Но если я использую Kafka, я беспокоюсь о ACID между обоими хранилищами, поэтому Kafka может получить неправильные данные, такие как откат PG или что-то подобное.

So:

1- Возможно ли обеспечить согласованность между РСУБД и хранилищем журналов ИЛИ 2- Можно ли в режиме реального времени подписаться и настроить PG (или другую РСУБД) для быстрого хранения событий?


postgresql apache-kafka event-sourcing acid
person mamcx    schedule 02.09.2016    source источник
comment
Непонятно, чего вы хотите добиться с помощью такой настройки, а не просто с помощью db. Журнал изменений — это единственное, что вы хотите от него получить?   -  person Tim    schedule 04.09.2016
comment
И возможность подписки на него с нескольких клиентов. Я беспокоюсь, что это может оказать большое давление на БД, потому что мне нужно будет использовать опрос.   -  person mamcx    schedule 05.09.2016

Ответы (1)


arrow_upward
0
arrow_downward

Легкие (1) ответы на предоставленные вопросы:

  1. Для достижения согласованности может быть достаточно правильной настройки уровня изоляции транзакций. и не беспокойтесь об откатах БД. Вы по-прежнему можете иногда создавать несогласованность, если только вы не установите уровень изоляции «сериализуемый». Даже в этом случае вы гарантированно будете последовательны, но все равно можете вести себя нежелательно. Например, клиент создает клиента и быстро выставляет счет с помощью асинхронного API, и событие счета сначала попадает в вашу резервную систему. В этом случае событие счета будет аннулировано, и клиенту нужно будет повторить попытку, надеясь, что к этому времени клиент будет создан. Легко избежать, если вы контролируете клиентов и уполномочиваете их использовать API синхронизации.

  2. Возможность хранения событий в реляционной БД зависит от предполагаемого размера набора данных, аппаратного обеспечения и шаблонов доступа. Я большой поклонник Postgres, и вы можете многое сделать, чтобы сделать поиск событий молниеносно быстрым. Мое эмпирическое правило — если размер вашего рабочего стола меньше 2300–300 ГБ и у вас есть приличный сервер, Postgres — это то, что вам нужно. При использовании источника событий обычно нет объединений, и общий шаблон доступа заключается в получении всех событий по идентификатору (возможно, ограниченному отметкой времени). Postgres отлично справляется с такими запросами, если вы правильно индексируете. Тем не менее, подписчикам событий необходимо будет получать эти данные, поэтому это может быть не очень хорошо, если у вас тысячи подписчиков, что на практике случается редко.

«Концептуально правильный» ответ: если вы все еще хотите использовать потоковый подход и принципиально решить условия гонки, вы должны предоставить гарантии упорядочения событий для всех событий в системе. Например, вам нужно иметь возможность заказать событие «добавить клиента 1» и событие «создать счет для клиента 1», чтобы вы могли гарантировать согласованность в любое время. Это действительно сложная проблема для решения в целом для распределенной системы (см., например, векторные часы). Вы можете смягчить это с помощью некоторых хитрых уловок, которые будут работать для вашего конкретного случая, например. в приведенном выше примере вы можете разделить свои события по «customerId» на раннем этапе, когда они попадут в бэкэнд, тогда вы можете гарантировать, что все события, связанные с одним и тем же клиентом, будут обработаны (примерно) в том порядке, в котором они были созданы.

С удовольствием разъясню свою точку зрения, если это необходимо.

(1) Простое или простое: обязательная ссылка

person Tim    schedule 07.09.2016
comment
1) Существует список ресурсов или книги, где можно использовать эти приемы? 2)Думаю данные будут не такие большие,мои потенциальные клиенты это владельцы небольших магазинов,и я думаю что вместо записи лога в кафку прямо в базу я записываю лог в таблицу,потом лог тяну В кафку в конечном итоге (так что только 1 клиент против БД), а затем использовать его для распространения данных для подписчиков. Итак у меня БД -> LogInDb -> Pull -> LogInKafKa -> PUSH -> Clients. - person mamcx; 09.09.2016
comment
Не то чтобы я в курсе. Это зависит от того, какие компромиссы может допустить ваше приложение. Думаю, обобщать будет сложно. - person Tim; 09.09.2016