Size: a a a

Архитектура ИТ-решений

2020 January 23

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Phil Delgyado
Ну, а при любом решении чем дальше в историю, тем дороже перестройка проекций и прочие операции. Для любой схемы.
Не совсем, точно не линейно

Снэпшоты, подумай над этим. Мне в этом смысле очень нравится лямбда архитектура

Ты поднимаешь один снэпшот по ключу из  kv и прокатываешь изменения за сутки

Снэпшоты батчами раз в сутки.

Глобальная история для аналитики и на случай конца света - в RAW слое
источник

d

dreamore in Архитектура ИТ-решений
Влезу в середину с глупостью: есть ли адекватные варианты применений event sourcing? Выглядит так, что проекции очень дорогие по ресурсам.

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

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Нужно разделять горячие и холодные данные. В случае использования брокера как единого источника правды и горячие и холодные данные должны храниться там
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
dreamore
Влезу в середину с глупостью: есть ли адекватные варианты применений event sourcing? Выглядит так, что проекции очень дорогие по ресурсам.

Не могу представить, например, банковский счёт, остаток по которому вычисляется последовательно обрабатывая события от СчетСоздан до последнего движения по счету.
Пока что получается обходиться без event soucing
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Gennadiy Kruglov
Не совсем, точно не линейно

Снэпшоты, подумай над этим. Мне в этом смысле очень нравится лямбда архитектура

Ты поднимаешь один снэпшот по ключу из  kv и прокатываешь изменения за сутки

Снэпшоты батчами раз в сутки.

Глобальная история для аналитики и на случай конца света - в RAW слое
Ну, это можно делать и через команды, кстати. Раз в сутки кидается суммирующее событие, остальные чистим.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
dreamore
Влезу в середину с глупостью: есть ли адекватные варианты применений event sourcing? Выглядит так, что проекции очень дорогие по ресурсам.

Не могу представить, например, банковский счёт, остаток по которому вычисляется последовательно обрабатывая события от СчетСоздан до последнего движения по счету.
Ну, в реальности так оно всегда и делается - остаток на начало дня + список транзакций.
источник

d

dreamore in Архитектура ИТ-решений
Это мне понятно, операционный день закрыт - state финализируется. Но не совсем, блокады, картотеки, отмены, резервы. Настоящего остатка никто не знает поэтому их два. Финализированный, по которым проводки завершены, и предположительный, который банкоматы показывают.

Просто эта банковская концепция появилась раньше event sourcing, и карточнная транзакция (событие с счетом по сути) живёт самостоятельно с своей машиной состояний и сама по себе тоже создаёт кучу событий.
источник

d

dreamore in Архитектура ИТ-решений
Выходит, Event sourcing - это миллениалы переоткрыли то, что давно существует и сложнее на порядки?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
dreamore
Это мне понятно, операционный день закрыт - state финализируется. Но не совсем, блокады, картотеки, отмены, резервы. Настоящего остатка никто не знает поэтому их два. Финализированный, по которым проводки завершены, и предположительный, который банкоматы показывают.

Просто эта банковская концепция появилась раньше event sourcing, и карточнная транзакция (событие с счетом по сути) живёт самостоятельно с своей машиной состояний и сама по себе тоже создаёт кучу событий.
Транзакция - это вообще другое.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Если про состояние счета, то нет такой вещи, на самом-то деле. Т.е. любой синхронный запрос тебе с некоторыми шансами вернет неверные данные. Event sourcing это дополнительно фиксирует.
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
dreamore
Влезу в середину с глупостью: есть ли адекватные варианты применений event sourcing? Выглядит так, что проекции очень дорогие по ресурсам.

Не могу представить, например, банковский счёт, остаток по которому вычисляется последовательно обрабатывая события от СчетСоздан до последнего движения по счету.
А зачем для контроля остатка хранить все движения? Периодически делать snapshot. Для остатка по сути нужны только активные холды. Зато никаких проблем с масштабированием. Все чтения происходят из соответствующих read models. И не надо никаких GridGainов
источник

RM

Rustem Mannanov in Архитектура ИТ-решений
Andrei Soloschak
А зачем для контроля остатка хранить все движения? Периодически делать snapshot. Для остатка по сути нужны только активные холды. Зато никаких проблем с масштабированием. Все чтения происходят из соответствующих read models. И не надо никаких GridGainов
Потому что приходит постановление суда (например, таких случаев много) , об отмене транзкации Х 2 года назад. И надо это делать. Без истории можно, но только в очень простых случаях.
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Ой
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Так надо отделить понятие документа от счёта
источник

d

dreamore in Архитектура ИТ-решений
зря я этот пример привел, мне теперь на сам вопрос никто не ответит
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Какой вопрос?
источник

RM

Rustem Mannanov in Архитектура ИТ-решений
Andrei Soloschak
Так надо отделить понятие документа от счёта
Согласен, это абстрактный пример. Но я бы не решился наверное жить без истории по обоим сущностям.)
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
История никуда не девается
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Просто для ускорения добавляются снапшоиы
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Rustem Mannanov
Потому что приходит постановление суда (например, таких случаев много) , об отмене транзкации Х 2 года назад. И надо это делать. Без истории можно, но только в очень простых случаях.
Эээ, не может быть такого, ЦБ не поддерживает. Только компенсирующую транзакцию...
источник