Является ли Event Hub предназначенным для использования в архитектуре Event Sourcing / только для добавления в журнал
Концентраторы событий не позволяют хранить сообщения более 7 (возможно, до 30) дней. Какая архитектура Azure предлагается для PaaS Event Sourcing с этими ограничениями? Если это Event Hub + моментальный снимок, что произойдет, если нам нужно каким-то образом восстановить это состояние? Дополнительно, является ли Event Hub ответом на KSQL/Spark Azure Stream Analytics?
3 ответа
Отличный вопрос!
Да, EventHubs предназначен для использования в Event Sourcing или же Append-only log шаблон. EventHubs могут быть использованы в качестве источника / приемника для потоковой обработки и аналитики, таких как SPARK, и, следовательно, не его конкурент. В общем, EventHubs предлагает те же возможности, что и Apache Kafka.
& Да, чтобы выполнить перестройку транзакций из журнала только для добавления Snapshotting безусловно, рекомендуемый подход!
Во время формирования EventHubs как предложение продукта, наши соображения по назначению значения по умолчанию для retentionPeriod - мы -
- большинство критических систем создают моментальные снимки каждые несколько минут.
- большинство шаблонов проектирования вокруг этого предполагают сохранение старых снимков для восстановления
Таким образом, стало ясно, что нам не нужен бесконечный журнал, и для большинства вариантов использования подойдет временной интервал в один день. Следовательно, мы начали с 1 дня по умолчанию - и дали ручку до 7 дней.
Если вы думаете, у вас будет случай, когда вам придется вернуться назад во времени на>7 дней, чтобы восстановить моментальный снимок (например, для отладки, что обычно не является сценарием на 99%), но согласился, что разработка и адаптация это очень разумно), рекомендуемый подход - отправить данные в архив.
Когда наш usage Metrics показал, что многие из наших клиентов имеют один EventHubs consumer group предназначенный для передачи данных в архивное хранилище - мы хотели включить эту возможность "из коробки", а затем начали предлагать - функцию захвата концентраторов событий.
Концентраторы событий должны использоваться для временного хранения событий при перемещении их между экземплярами хранилища данных. Вам придется загрузить их в какое-то постоянное хранилище для использования в течение неопределенного периода времени, например, Cosmos DB.
KSQL в некоторой степени сопоставим с Azure Stream Analytics. Spark - гораздо более широкий продукт, но вы можете использовать Spark для обработки данных концентраторов событий.
PS Я не официальный спикер Microsoft, так что это только мое мнение.
Во многих случаях Cosmos DB является лучшим хранилищем событий при использовании шаблона источников событий, чем концентратор событий. Причина в том, что Cosmos DB не удаляет данные автоматически. С помощью концентратора событий вы можете использовать функцию захвата для копирования старых данных в хранилище BLOB-объектов Azure, но тогда при доступе к более старым событиям вам потребуется иметь возможность читать события как из концентратора событий, так и из хранилища BLOB-объектов, что усложняет реализацию.
В отличие от Cosmos DB, вы можете хранить события вместе с ключом раздела и меткой времени. Затем вы можете легко фильтровать события или использовать канал изменений Cosmos DB для получения уведомлений.
Однако и в Cosmos DB дамп событий в хранилище BLOB-объектов может быть полезен, если часто требуется полное воспроизведение событий и если это обходится дорого или занимает много времени. Хотя для доменов с разумным количеством событий лучше всего использовать базу данных в качестве единственного хранилища.