Перемещать (копировать, затем удалять) данные из операционного хранища в некоторое холодное хранилище точно нужно.
Важно придумать заранее политику, которая удовлетворяет требованиям к системе и предусмотреть вопрос того, как быть с проекциями, которые были построены из перемещенных данных. И то, что надо перемещать стримы/агрегаты целиком, а не отдельные эвенты.
Возможно, стоит предусмотреть возможность перечитывания приложением данных из холодного хранилища. Или, как вариант, можно разбить лог на секции, например, по месяцам и строить проекции, вроде отчетов, соотвтетственно, по этим секторам.
Данных тут не будет больше, чем в приложении сделанном любым другим образом с теми же требованиями. Условно, вы можете хранить ревизии вместо эвентов, или использовать паттерн аутбокс для того, чтобы получить те же свойства системы. Эвенты в эвент-сорсинге же это дэльты состояний, а не копии объетков целиком, в теории они должны быть компактнее других вариантов.
Вы предполагаете что проблемы в отсутствии транзакционности будут возникать редко.
Я не предполагаю, что проблемы будут возникать редко, я говорю о том, что нужно понимать, что применяя эвент сорсинг у вас не будет транзакций концептуально. Я под этим подразумеваю возможность обновления множества сущностей в атомарно, допустим запись эвентов и обновление проекций в одной транзакции. И код обновления проекций, или там взаимодействия с другими сервисами, по-задумке, находится в другом месте и работает с задержкой.
Вы предполагаете что поддержание ACID гарантий сильно замедляет скорость разработки.
Не понимаю откуда взялся тут ACID, ACID он как бы про другое, ACID нужен даже чтобы одну строчку в базу записать и быть уверенным в том, что это произойдет с некоторыми гарантиями... Замедляет разработку транзакция, в которой атомарно меняется N сущностей, потому что такое место в коде становится хрупким, имеет тенденцию разрастаться, например, с ростом кол-ва проекций, и даже некритичный, вторичный функционал, может аффектить критичный.
В моей практике был один интересный случай...
История очень интересная и по теме статьи (нет). Я в статье только подсвечиваю проблемы и по-большому счету призываю думать о том, какие последствия у разных решений могут быть, а не убеждаю всех действовать как я придумал.
Неуместно сравнивать что ли, тут дело в том, чтобы был уровень косвенности и понимание того какое количество кода придётся поменять в случае чего.
Моя идея в том, что внутри некоторого ограниченного контекста можно применять эвент-сорсинг или любую уместную там технологию паттерн и так далее, но внешнему миру об этом знать не нужно и это не должно влиять на то как устроено взаимодействие с сервисом.
Если у вас вся система обслуживает один контекст, то может вам и не нужны уровни косвенности такие как интеграционные эвенты, или апи (если это монолит, например).
Вопросы межсервисного взаимодействия к эвент-сорсингу не относятся. Условно, все те же проблемы нужно решать как и без эвент-сорсинга — делать пессиместичные и дюрабельные блокировки, вызовы идемпотентными и прочее.
Может быть у вас есть пример эвентсорсинга, который несет только полезные свойства, а не tradeoff с отрицательной суммой?
Вопрос не понял, уточните? Плюсы перечислены перед "когда не применять" в "когда применять" :-)
По-большому счету майкрософтовские акторы не отличаются от обычных, просто майкрософт упростил управление лайфсайклом акторов. Когда вам нужно вызвать актор рантайм orleans сам его запустит, у вас будет возможность загрузить данные, затем актор начнет обрабатывать последовательно запросы из мейлбокса, затем после какого-то времени бездействия рантайм сам остановит актор и освободит ресурсы.
Собственно, я лишь имел ввиду то, что акторами обернуть агрегаты и/или проекции получается очень удобно и это сильно снизит нагрузку на базы данных, за счет уменьшения количества запросов к базам данных и количества коллизий, возможно даже и скейлить ничего не придётся.
Тут я скорее хотел подсветить тот факт, что если есть даже теоретическая необходимость в том, что какие-то данные нужно будет удалять из системы (эвентов) и тп, то нужно предусмотреть и продумать именно процесс решения такой задачи, примерно понимать необходимый уровень работы, который потребуется сделать.
Удалить и изменить данные конечно можно, примерно такие шаги можно предпринять:
Сделать новую версию эвентов и поправить код для работы с этой версией эвентов
Начать работать с новыми эвентами
Старые эвенты скопировать в новый сторедж, приведя к новой версии
Удалить старые эвенты
Ну, это я так, утрированно. Вопрос лишь в кол-ве работы которое придётся проделать. Ну и про ПД всё же тут можно продумать, как и про данные которые в скоуп pci-dss попадают. Можно самые очевидные вещи — карточные данные или персональные данные сразу не хранить в сервисе, который за них не отвечает, а запрашивать по-необходимости.
Про facebook смешно и это вполне рабочий вариант, без шуток :-)
Про доменные и интеграционные эвенты — ну да, всё так, я называю доменными то, что внутри домена (домен может обслуживать один сервис или группа сервисов), а те эвенты, что используются для интеграции с другими сервисами — интеграционными.
Я думаю, что использовать доменные эвенты для интеграции не хорошо, по нескольким причинам:
Внешние сервисы могут требовать больше информации, чем содержится в конкретном эвенте. Допустим, можно представить, что у нас есть пара эвентов — о том, что платёж создан (в этом эвенте будет фигурировать orderId, который пришел в запросе создания платежа), и о том, что платёж авторизован (в этом платеже мы зафиксировали факт оплаты orderId фигурировать не будет). В нашем домене мы данные не дублируем, и условно каждый эвент содержит только некоторую дельту данных Если внешнему сервису интересен только факт авторизации платежа для некоторого orderId, то ему придётся консьюмить два эвента и created и authorized (и все промежуточные, в реальном мире от создания платежа до авторизации эвентов будет с десяток) и самому как-то их объединять, т.е. воспроизводить логику из нашего домена. Для интеграции удобно иметь эвент который содержит те данные которые нужны для интеграции :-)
Это ограничивает наши возможности по изменению нашего сервиса. Условно, если нам нужно будет переделать как-то эвенты, убрать одни, добавить другие, то тут может возникнуть проблема, что интеграция сломается. Ну либо идти и менять все зависимые сервисы. Жесткая связность. Думаю, можно интегрироваться и на доменных эвентах, но нужно отдавать отчет в том, какую связность это вносит и поддерживать некоторый баланс.
В статье есть про то что джойнить данные больше не получится — нужны проекции, но, согласен, что можно было бы это подсветить, так как для многих может быть актуальным вопросом.
Отвечу тут.
На большом кол-ве данных в oltp делать запросы для построения отчетов — это путь вникуда. Я думаю что эвент-сорсинг для мелких приложений вряд ли стоит применять, поэтому предполагаю, что это наш кейс приложение с большим кол-вом данных. Большинство решений задачи в таком случае сводится к переливке данных из oltp с помощью change data capture в olap хранилище и там уже строятся отчеты. Особенно актуально в системах с большим количеством сервисов, когда нужны отчеты по данным множества сервисов.
С эвент-сорсингом можно делать это прямо в своем приложении с помощью проекций, при этом отчеты будут всегда актуальными и не будут требовать вычислительных ресурсов в момент запроса, потому что они всегда готовы.
Моё мнение — писать в эвент-сорсинговом приложении консьюмеры, которые в бэкграунде строят какие угодно отчеты и при этом не аффектят oltp нагрузку не такая большая проблема, и более того я считаю это преимуществом такой архитектуры.
Для платежей и заказов нужно хранить историю перехода между состояниями независимо от того, используется ES или нет. Так что пример в статье неудачный (
Так как эту задачу можно решить и без ES, например писать логи дополнительно или хранить ревизии, то это не такой и плохой пример.
Вообще, я считаю, что любая стейт-машина, fsm, хорошо играет вместе с эвент-сорсингом. Допустим, если у нас есть заказ и мы храним историю переходов между состояниями, то мы можем получить некоторые инсайты о том, как клиенты взаимодействуют с сайтом и на этом построить некоторую логику.
Так же имея именно эвенты, а не снимки состояний мы можем почти в реальном времени строить какие-то отчеты для разных нужд, метрики для понимания того, как система работает, или метрики для бизнеса.
И второй вопрос: можно хранить не ивенты, а завести таблицу журнала и хранить там историю состояний, чем это лучше/хуже, чем хранение ивентов?
Если я правильно понял, под таблицей журнала вы имеете ввиду append-only табличку где вы будете хранить целиком версии объектов при каждом изменении.
Нормальный подход, особенно, для блогов или каких-то объектов настроек, потому что они меняются редко и [почти] целиком при каждой записи, к тому же там нет разных причин изменения состояний. Условно, при работе с такими данными есть просто одно действие — сохранить новую версию данных и поэтому моделировать какие-то эвенты — оверхед.
Если стейт-машина сложная и много всяких разных воздействий и состояний, то лучше хранить эвенты, потому что это [сильно] дешевле, к тому же так как с эвентами нет дублей данных, то они с меньшей вероятностью "разьедутся", в эвент-сорсинге же каждый кусочек данных это источник правды и просто необходим. Ещё кажется что эвент-сорсинг предлагает более дженериковый подход к работе с данными, добавляя новый агрегат не придётся менять ничего в write базе данных, вроде создания новых табличек или коллекций, и вы сразу получите историю состояний с причиной изменений и прочими деталями. Ну и ещё поинт, что если вы захотите CQRS, отдельную read модель, то вам придётся примерно все те же механизмы написать что и для эвент-сорсинга, только у вас в базе будет храниться больше данных.
Аудиторы придираются и говорят, что к криптограммам нужно относиться как к данным карты :-)
Возможно, из-за рисков утечки приватного ключа у провайдера, например, но там странная история, ведь в этом случае данные и так будут скомпрометированы. Я не сильно погружен в обсуждение этого вопроса, но думаю, что можно поспорить с аудиторами на этот счет, ну, или хотя бы уточнить причину :-)
Привет! Спасибо за ответы! :-)
Привет!
Перемещать (копировать, затем удалять) данные из операционного хранища в некоторое холодное хранилище точно нужно.
Важно придумать заранее политику, которая удовлетворяет требованиям к системе и предусмотреть вопрос того, как быть с проекциями, которые были построены из перемещенных данных. И то, что надо перемещать стримы/агрегаты целиком, а не отдельные эвенты.
Возможно, стоит предусмотреть возможность перечитывания приложением данных из холодного хранилища. Или, как вариант, можно разбить лог на секции, например, по месяцам и строить проекции, вроде отчетов, соотвтетственно, по этим секторам.
Данных тут не будет больше, чем в приложении сделанном любым другим образом с теми же требованиями. Условно, вы можете хранить ревизии вместо эвентов, или использовать паттерн аутбокс для того, чтобы получить те же свойства системы. Эвенты в эвент-сорсинге же это дэльты состояний, а не копии объетков целиком, в теории они должны быть компактнее других вариантов.
Я не предполагаю, что проблемы будут возникать редко, я говорю о том, что нужно понимать, что применяя эвент сорсинг у вас не будет транзакций концептуально. Я под этим подразумеваю возможность обновления множества сущностей в атомарно, допустим запись эвентов и обновление проекций в одной транзакции. И код обновления проекций, или там взаимодействия с другими сервисами, по-задумке, находится в другом месте и работает с задержкой.
Не понимаю откуда взялся тут ACID, ACID он как бы про другое, ACID нужен даже чтобы одну строчку в базу записать и быть уверенным в том, что это произойдет с некоторыми гарантиями... Замедляет разработку транзакция, в которой атомарно меняется N сущностей, потому что такое место в коде становится хрупким, имеет тенденцию разрастаться, например, с ростом кол-ва проекций, и даже некритичный, вторичный функционал, может аффектить критичный.
История очень интересная и по теме статьи (нет). Я в статье только подсвечиваю проблемы и по-большому счету призываю думать о том, какие последствия у разных решений могут быть, а не убеждаю всех действовать как я придумал.
Неуместно сравнивать что ли, тут дело в том, чтобы был уровень косвенности и понимание того какое количество кода придётся поменять в случае чего.
Моя идея в том, что внутри некоторого ограниченного контекста можно применять эвент-сорсинг или любую уместную там технологию паттерн и так далее, но внешнему миру об этом знать не нужно и это не должно влиять на то как устроено взаимодействие с сервисом.
Если у вас вся система обслуживает один контекст, то может вам и не нужны уровни косвенности такие как интеграционные эвенты, или апи (если это монолит, например).
Вопросы межсервисного взаимодействия к эвент-сорсингу не относятся. Условно, все те же проблемы нужно решать как и без эвент-сорсинга — делать пессиместичные и дюрабельные блокировки, вызовы идемпотентными и прочее.
Вопрос не понял, уточните? Плюсы перечислены перед "когда не применять" в "когда применять" :-)
По-большому счету майкрософтовские акторы не отличаются от обычных, просто майкрософт упростил управление лайфсайклом акторов. Когда вам нужно вызвать актор рантайм orleans сам его запустит, у вас будет возможность загрузить данные, затем актор начнет обрабатывать последовательно запросы из мейлбокса, затем после какого-то времени бездействия рантайм сам остановит актор и освободит ресурсы.
Собственно, я лишь имел ввиду то, что акторами обернуть агрегаты и/или проекции получается очень удобно и это сильно снизит нагрузку на базы данных, за счет уменьшения количества запросов к базам данных и количества коллизий, возможно даже и скейлить ничего не придётся.
Тут я скорее хотел подсветить тот факт, что если есть даже теоретическая необходимость в том, что какие-то данные нужно будет удалять из системы (эвентов) и тп, то нужно предусмотреть и продумать именно процесс решения такой задачи, примерно понимать необходимый уровень работы, который потребуется сделать.
Удалить и изменить данные конечно можно, примерно такие шаги можно предпринять:
Сделать новую версию эвентов и поправить код для работы с этой версией эвентов
Начать работать с новыми эвентами
Старые эвенты скопировать в новый сторедж, приведя к новой версии
Удалить старые эвенты
Ну, это я так, утрированно. Вопрос лишь в кол-ве работы которое придётся проделать. Ну и про ПД всё же тут можно продумать, как и про данные которые в скоуп pci-dss попадают. Можно самые очевидные вещи — карточные данные или персональные данные сразу не хранить в сервисе, который за них не отвечает, а запрашивать по-необходимости.
Про facebook смешно и это вполне рабочий вариант, без шуток :-)
Про доменные и интеграционные эвенты — ну да, всё так, я называю доменными то, что внутри домена (домен может обслуживать один сервис или группа сервисов), а те эвенты, что используются для интеграции с другими сервисами — интеграционными.
Я думаю, что использовать доменные эвенты для интеграции не хорошо, по нескольким причинам:
Внешние сервисы могут требовать больше информации, чем содержится в конкретном эвенте. Допустим, можно представить, что у нас есть пара эвентов — о том, что платёж создан (в этом эвенте будет фигурировать orderId, который пришел в запросе создания платежа), и о том, что платёж авторизован (в этом платеже мы зафиксировали факт оплаты orderId фигурировать не будет). В нашем домене мы данные не дублируем, и условно каждый эвент содержит только некоторую дельту данных Если внешнему сервису интересен только факт авторизации платежа для некоторого orderId, то ему придётся консьюмить два эвента и created и authorized (и все промежуточные, в реальном мире от создания платежа до авторизации эвентов будет с десяток) и самому как-то их объединять, т.е. воспроизводить логику из нашего домена. Для интеграции удобно иметь эвент который содержит те данные которые нужны для интеграции :-)
Это ограничивает наши возможности по изменению нашего сервиса. Условно, если нам нужно будет переделать как-то эвенты, убрать одни, добавить другие, то тут может возникнуть проблема, что интеграция сломается. Ну либо идти и менять все зависимые сервисы. Жесткая связность. Думаю, можно интегрироваться и на доменных эвентах, но нужно отдавать отчет в том, какую связность это вносит и поддерживать некоторый баланс.
В статье есть про то что джойнить данные больше не получится — нужны проекции, но, согласен, что можно было бы это подсветить, так как для многих может быть актуальным вопросом.
Отвечу тут.
На большом кол-ве данных в oltp делать запросы для построения отчетов — это путь вникуда. Я думаю что эвент-сорсинг для мелких приложений вряд ли стоит применять, поэтому предполагаю, что это наш кейс приложение с большим кол-вом данных. Большинство решений задачи в таком случае сводится к переливке данных из oltp с помощью change data capture в olap хранилище и там уже строятся отчеты. Особенно актуально в системах с большим количеством сервисов, когда нужны отчеты по данным множества сервисов.
С эвент-сорсингом можно делать это прямо в своем приложении с помощью проекций, при этом отчеты будут всегда актуальными и не будут требовать вычислительных ресурсов в момент запроса, потому что они всегда готовы.
Моё мнение — писать в эвент-сорсинговом приложении консьюмеры, которые в бэкграунде строят какие угодно отчеты и при этом не аффектят oltp нагрузку не такая большая проблема, и более того я считаю это преимуществом такой архитектуры.
Так как эту задачу можно решить и без ES, например писать логи дополнительно или хранить ревизии, то это не такой и плохой пример.
Вообще, я считаю, что любая стейт-машина, fsm, хорошо играет вместе с эвент-сорсингом. Допустим, если у нас есть заказ и мы храним историю переходов между состояниями, то мы можем получить некоторые инсайты о том, как клиенты взаимодействуют с сайтом и на этом построить некоторую логику.
Так же имея именно эвенты, а не снимки состояний мы можем почти в реальном времени строить какие-то отчеты для разных нужд, метрики для понимания того, как система работает, или метрики для бизнеса.
Если я правильно понял, под таблицей журнала вы имеете ввиду append-only табличку где вы будете хранить целиком версии объектов при каждом изменении.
Нормальный подход, особенно, для блогов или каких-то объектов настроек, потому что они меняются редко и [почти] целиком при каждой записи, к тому же там нет разных причин изменения состояний. Условно, при работе с такими данными есть просто одно действие — сохранить новую версию данных и поэтому моделировать какие-то эвенты — оверхед.
Если стейт-машина сложная и много всяких разных воздействий и состояний, то лучше хранить эвенты, потому что это [сильно] дешевле, к тому же так как с эвентами нет дублей данных, то они с меньшей вероятностью "разьедутся", в эвент-сорсинге же каждый кусочек данных это источник правды и просто необходим. Ещё кажется что эвент-сорсинг предлагает более дженериковый подход к работе с данными, добавляя новый агрегат не придётся менять ничего в write базе данных, вроде создания новых табличек или коллекций, и вы сразу получите историю состояний с причиной изменений и прочими деталями. Ну и ещё поинт, что если вы захотите CQRS, отдельную read модель, то вам придётся примерно все те же механизмы написать что и для эвент-сорсинга, только у вас в базе будет храниться больше данных.
Аудиторы придираются и говорят, что к криптограммам нужно относиться как к данным карты :-)
Возможно, из-за рисков утечки приватного ключа у провайдера, например, но там странная история, ведь в этом случае данные и так будут скомпрометированы. Я не сильно погружен в обсуждение этого вопроса, но думаю, что можно поспорить с аудиторами на этот счет, ну, или хотя бы уточнить причину :-)
О, не знал что такое есть, спасибо :-)
Да, кринж, починим :-)
Напиши, пожалуйста, в лс какой-нибудь какую-нибудь инфу о заказе, подтолкну возврат :-)
Спасибо за ответы. Вообще, я про исо знаю, но пока не приходилось поработать с апи сделанным по исо. Отсюда и все эти вопросы :-)
Да
Спасибо за инфу :-)