[Перевод] Сможет ли Event Sourcing перерасти базы данных?27.02.2023 17:31

Event sourcing — не новый термин. Если вы работаете с технологиями, то должны были с ним сталкиваться. Это мощный инструмент, используемый многими крупными организациями в качестве архитектуры баз данных. Он имеет возможность масштабирования и отвечает потребностям современной отрасли обработки данных.

В этой статье мы глубже рассмотрим ES и расскажем о причинах его популярности. Также мы поразмыслим над популярным вопросом: перерастёт ли event sourcing базы данных?

Что такое Event Sourcing?

Event sourcing — это архитектурный паттерн хранения данных в виде последовательности событий. Event (событие) — это всего лишь контекст бизнес-операции. Например, если покупатель запросил возврат средств, но вы не знаете причины, event sourcing предоставляет контекст того, почему был сделан возврат.

Давайте разберёмся в ключевых понятиях, связанных с event sourcing:

▍ События

События представляют изменение в состоянии данных. Это неизменяемые факты, предоставляющие бизнесу контекст. Для примера возьмём онлайн-магазин. Все изменения данных сохраняются в виде событий, например, ProductAdded, ProductOrdered, ProductShipped, PaymentReceived и так далее.

События записываются с глаголами в прошлом времени, представляя собой источник истины текущего состояния бизнеса. Кроме контекста — события также хранят метаданные, чтобы предоставлять дополнительную информацию.

▍ База данных Event Source

База данных event source записывает все события в базу данных, куда возможно только добавление. В БД event source история изменений хранится в хронологическом порядке.

БД event source могут также называть логами событий (event log). Их нельзя редактировать, поскольку события неизменяемы. Однако есть и другое мнение: что БД event source можно изменить добавлением другого события; состояние БД event source или его результат меняются.

БД event source онлайн-магазина фиксирует каждое событие и соответствующие ему метаданные. Допустим, в БД event source товара есть два события, и в неё добавляется третий товар. Этот добавленный товар не является новым, а возвращён покупателем, то есть контекст события — это возвращённый товар, а количество событий обновляется. БД event source хранит все эти события в хронологическом порядке.

Контекст и хронологический порядок событий предоставляют полезную информацию для глубинного анализа.

▍ Потоки

Потоки событий (event stream) предоставляют полную историю изменений, связанных с конкретным событием. События хранятся в базе данных event source, а потоки событий описывают порядок, в котором происходили события. В зависимости от конкретной ситуации потоки событий могут храниться кратковременно или длительно. События внутри потока событий идентифицируются по уникальному числовому значению, а при обновлении событий выполняется инкремент их значений. При помощи этих идентификаторов можно получить исходное состояние событий. В примере с онлайн-магазином платёж является отдельным объектом сущности/предметной области. Объект платежа имеет собственный уникальный идентификатор, а его поток событий будет выглядеть так: Платёж подтверждён → Платёж получен → Запрошен возврат → Вычтена сумма возврата.

▍ Представление запросов

В event sourcing модели запросов (query model) описывают логический переход от модели записи к модели чтения источника. Также их называют проекциями (Projection) или моделями представлений (View Model). В представлении запросов (query view) существует два типа концепций: модель чтения и модель записи. Вернёмся к примеру с онлайн-магазином, где события модели записи, добавляемый в представление запросов, имеют следующий вид: «сформирован заказ», «получен платёж», «отправлен заказ», «вычтен товар»; можно использовать представление запросов для генерации в модели чтения сводки всех сделанных заказов и полученных платежей.

Зачем нужен Event Sourcing?

Event sourcing — превосходный выбор для различных областей применения. Давайте рассмотрим несколько ситуаций, в которых event sourcing станет приемлемым решением.

Event sourcing полезен в системах аудита, где логи могут храниться в хронологическом порядке и существует опция резервного копирования по запросу.
Традиционные методики собирают данные в конкретные места и используются только при необходимости. Благодаря быстрому реагированию на новую появляющуюся информацию — методика на основе событий может быть более эффективной. Подписавшись на поток, организация может получать обновления о новых происшествиях и незамедлительно на них реагировать. Это упрощает моделирование и создание сложных бизнес-процедур.
Можно выполнять миграцию легаси-систем на современные распределённые архитектуры медленно, постепенно заменяя отдельную функциональность сервисами на основе ES. Пока операции записи направляются в сервисы, можно продолжать использовать уже существующие пути чтения легаси-систем.
Зависимые системы могут «навёрстывать упущенное», когда исходный сервис восстанавливает свою работу после сбоя. После возврата в строй каждого сервиса можно выполнять синхронизацию, поскольку события в потоке хранятся в конкретном порядке.
В системе с ES благодаря отдельным моделям чтения и обновления данные перемещаются в одном направлении. Благодаря тому, что каждая часть потока данных имеет единственную ответственность, упрощаются анализ данных и устранение проблем.

Чем база данных Event Source отличается от традиционных баз данных?

В традиционных базах данных данные сохраняются при помощи CRUD-операций, то есть Create, Read, Update и Delete. В случае возникновения изменения запись обновляется в базе данных, сохраняя текущее состояние системы. Во всех реляционных и нереляционных БД записи можно удалять, из-за чего состояние системы теряется.

В БД event source события неизменяемы; их нельзя удалять или модифицировать. БД event source сохраняет историю логов в хронологическом порядке. Благодаря отслеживанию изменений — мы избегаем расхождения в данных аудита и данных транзакций. Как и в архитектуре CRUD-систем, event sourcing хранит события в таблицах, но в хронологическом порядке. Так как данные расположены по порядку и последние данные находятся наверху, фильтрация при event sourcing выполняется проще по сравнению с традиционными БД.

Перерастёт ли Event Sourcing базы данных?

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

Также event sourcing предоставляет контекст происходящего в базе данных изменения, что помогает отвечать на вопросы бизнеса. Event sourcing лучше работает с микросервисами и позволяет надёжным образом обмениваться данными с другими сервисами.

Вот несколько преимуществ event sourcing по сравнению с традиционными базами данных:

События можно сохранять операциями, обеспечивающими только добавление; события являются неизменяемыми. Задачи, связанные с событиями, могут выполняться в фоновом режиме, пока продолжается работа запустившего их пользовательского интерфейса, потока или процесса. Это, а также отсутствие конфликтов при обработке транзакций, способно существенно повысить показатели и возможности масштабирования приложения, особенно на уровне презентации или пользовательского интерфейса.
События — это простые объекты, которые могут объяснять произошедшее действие и давать дополнительную информацию, необходимую для полного описания действия, представленного событием. Хранилище данных не обновляется событиями напрямую. Они просто записываются для обработки по необходимости. Это может упростить администрирование и реализацию.
Для специалиста в предметной области события чаще понятнее. Однако объектно-реляционная рассогласованность интерфейсов может усложнить восприятие сложных таблиц баз данных. Таблицы — это вымышленные объекты, отображающие текущее состояние системы, а не действительные события.
Так как event sourcing не требует обновления объектов хранилища данных напрямую, он может способствовать предотвращению конфликтов, вызванных одновременными модификациями. Впрочем, модель предметной области всё равно должна строиться таким образом, чтобы противостоять запросам, способным вызвать несогласованное состояние.
Задачи реагируют на события, выполняя действия в процессе появления событий в БД event source.
Задачи и события разделены, что обеспечивает гибкость и возможность расширения. Задачи всегда знают о типе произошедшего события и его данных, но не о вызвавшей событие операции.
Кроме того, каждое событие может обрабатываться множеством разных задач. Это позволяет с лёгкостью интегрировать дополнительные сервисы и системы, которые занимаются только мониторингом новых событий, генерируемых БД event source. Однако события event sourcing часто бывают очень низкоуровневыми, поэтому вместо них может потребоваться создание специальных событий интеграции.

Проблемы Event Sourcing

Несмотря на множество преимуществ, event sourcing имеет и множество проблем. Давайте обсудим некоторые из них.

БД event source неизменяема и служит в качестве постоянного репозитория данных. Данные событий никогда не должны модифицироваться. Добавление нового события в БД event source — это единственная возможность обновления сущности для отката модификации. Могут возникать трудности при смешивании текущих событий в хранилище с новой версией в случае необходимости смены формата (но не содержимого) постоянно хранимых событий, например, в случае миграции. Возможно, потребуется добавление новых событий, использующих новый формат, или циклический обход всех имеющихся событий и внесение изменений, чтобы они соответствовали новому формату. Чтобы сохранить форму и старых, и новых событий, можно попробовать использовать метку версии в каждой итерации схемы событий.
Запросы данных или считывание данных из хранилищ данных event source могут быть сложными процессами, поскольку отсутствует стандартный механизм SQL. Для чтения данных поток событий извлекается согласно идентификатору события.
БД event source может содержать события, сохраняемые многопоточными программами или несколькими экземплярами приложений. Критически важны и согласованность событий в БД event source, и тайминг событий, влияющих на конкретную сущность (порядок изменений, происходящих с сущностью, влияет на её текущее состояние). Каждое событие должно иметь метку времени, позволяющую избегать проблем. Ещё одна распространённая техника — присвоение инкрементного идентификатора каждому событию, вызванному запросом. БД event source может отклонить событие, соответствующее уже существующему идентификатору сущности и идентификатору события, если две операции пытаются одновременно добавить события одной сущности.
Event sourcing снижает вероятность возникновения конфликтов в изменениях данных, однако приложение всё равно должно иметь возможность обрабатывать рассогласованность, вызванную неустойчивым состоянием и отсутствием транзакций. Например, может возникнуть необходимость уведомления покупателя или создания невыполненного заказа, если во время размещения заказа товара в хранилище данных возникает событие, указывающее на уменьшение в наличных запасах.
После того, как системы event source какое-то время фиксировали события, может возникнуть ещё одно затруднение. Становится жизненно необходимо найти технику обработки исторических событий, потому что простой фиксации всех событий в системе недостаточно; невозможность понимания истории делает лог событий совершенно бесполезным. При восстановлении системы после сбоя или во время миграции хранилищ отложенных состояний может потребоваться повторная обработка всего лога событий, чтобы обеспечить актуальность структуры данных системы. В системах, обрабатывающих большие объёмы событий, могут также оказаться необходимыми периодические снэпшоты состояния системы, поскольку повторная обработка всего лога событий окажется слишком длительным процессом; благодаря снэпшотам восстановление можно начинать с более недавнего хорошего состояния. Компании должны учитывать способ формирования событий, потому что эта структура может сильно изменяться со временем: меняются наборы полей и способы обработки событий со старыми структурами в новой бизнес-логике. Необходимо обеспечить защиту от будущих изменений в фиксации событий, разработав чёткую расширяемую схему событий; возможно, также понадобится добавить в новую бизнес-логику дополнительные правила обработки, чтобы обеспечить понятность старых структур событий. Периодические снэпшоты также можно использовать для разделения между существенными изменениями в структуре событий, когда затраты на поддержку предыдущих событий оказываются выше, чем их собственная ценность.

Заключение

Мы подробно изучили концепции event sourcing, его достоинства и недостатки. Подведём итог: event sourcing — отличный архитектурный паттерн хранения данных. Однако он способен быть ценным только при правильной реализации. В некоторых случаях лучшим выбором остаются традиционные базы данных. В ближайшие годы event sourcing ждёт массовое применение, но он не сможет заменить традиционные базы данных. Базы данных на основе CRUD останутся с нами и будут обслуживать множество реальных областей применения.

Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх