пока что в проекте нет eventual consistency, поведение ближе к стандартном поведению многих баз данных. Есть предложения на тему как лучше всего «заложить» это в проект заранее? Я пока себе это представляю как набор требований выставляемых «поставщиком» конкретной команды — насколько ему важно гарантия проиндексированных данных, или хватит гарантии журналирования, чтобы перейти к следующим шагам быстрее.
да, пока нет конфигурации на тему когда индексирование должно происходить, индексы будут просаживать производительность записи приблизительно также как и в традиционных реляционных бд
С моей личной практической точки зрения, это тот «низкий» порог «угадывания» который меня устроил. Мне не нужно угадывать какие будут структуры моделей, как нужно со временем менять модели и мигрировать данные, мне нужно только время от времени добавлять индексы к полям, причем совсем необязательно перед тем как события записаны — индексы можно добавить в любой момент.
Да, это «вывернутая наизнанку» доменная модель, однако в этой модели мне не надо угадывать что будет в будущем, просто честно собирать данные и «разворачивать» доменную модель так как мне нужно.
1. Явно выраженных гарантий по поводу индексов еще нет (но скорее всего будут), пока это факт реализации и некоторых тестов — индексы появляются по факту коммита транзакции (scope транзакций — команда), перед тем как контроль «вернется» к отправителю команды, то есть по сути идут вместе с транзакцией.
2. Только в некотором смысле — в том плане что я сохраняю данные в событиях в таком виде в котором использование индексов для того чтобы найти эти события было настолько тривиальным насколько это возможно. Случаи, когда таки приходится делать агрегацию событий для оптимизации конечно происходят, но я стараюсь это свести к минимуму.
Конечно, на поверхности! Ничего сверх-нового. Мои усилия на тему чтения истории агрегата сейчас таковы: 1) оптимизация поиска (индексы используют CQengine, память/диск) 2) организация события в таком виде при котором легко запрашивать без over-fetching.
Я не писал, что нужна обязательно реляционная база данных, выше в комментариях я написал «часто это реляционная база данных». Доменную модель и правда можно хранить где угодно. Если доменная модель в памяти, это не значит что read side нету, просто она в памяти.
Можно прекрасно делать то что вы описываете («кешировать в памяти доменную модель из которой и брать нужные вещи, In-memory cache можно восстанавливать по событиям при старте приложения») однако это не решает ту задачу которая была передо мной — избежать планирования доменной модели («предугадывание будущего»), и дорогостоящих «переигрываний» событий.
масштабируется — да. но это не решает проблему (которая для кого-то проблема, а для кого-то — нет) с нежеланием предугадывать будущее (соотв., строить read side модели). у меня это было задачей :)
пока что ничего сильно сложного (но проект еще очень молодой). сейчас writedb (журнал) реализуется через MVStore (движок от H2), так как в моей текущей модели я разрабатываю приложения со «встроенным» хранилищем (через интерфейс можно, конечно, добавить любые другие реализации. например, более раннии инкарнации этого проекта использовали postgresql по умолчанию).
если разбивать файлы в которых лежат необходимые ключи (например, consistent hashing или на исторические «отрезки») и хранить на независимых устройствах (в терминах дисков ли, или сетевых устройств) то можно обеспечить сценарий в котором чтение из writedb практически независимо от записи. пока что этого ф-ционала нет, но это интересная тема!
по итогам:
1. более актуальная информация чем в традиционном варианте — уже лучше.
2. как я упоминал в статье, конечно есть случаи когда массовые выборки будут медленными, и так или иначе агрегировать и/или кешировать данные надо. идеального мира нет :)
3. не обязательно, это зависит от того как она устроена. append only дает определенные преимущества.
по сути, да. индексы содержат все проиндексированные данные и соотв. ссылки по которым быстро достаются любые события и откуда можно узнать все данные которые были записаны в событии.
Идея в том что не строится state db согласной некой модели данных, а только записываются события и они же индексируются (простые индексы по полям, или более сложные композитные индексы). вместо того чтобы записывать изменения в таблицу Users (например), и искать пользователя там, мы просто ищем события которые дают нам минимально необходимое понимание о том что произошло (в случае примера в статье, UserCreated(id) и последний EmailChanged(user: id). Ищем их не перебором, а по индексам (индексы могут быть определены как заранее, так и после записи событий).
При этой модели, state db в классическом понимании нет, как нету и «единой» модели данных.
мне кажется, важно вот какое замечание сделать: разделение на write side и read side было и остается, но read side представляет собой не около-конечную модель данных а «сырые индексы» и сборка моделей происходит (в большинстве случаев) в рантайме. Соответственно, нет необходимости «предугадывать» будущее.
В существующей реализации, event store на самом деле (внутри) — две базы, одна — журнал, другая — индекс. Можно рассматривать их совокупность как одну event store, либо как event store + state db, где стейт — это просто индексы событий.
AigizK, запрос на чтение в «традиционной» модели отправляется в state db (часто это реляционная база даннных); в ленивой модели запрос уходит в event store (который не только журналирует события, но и индексирует их). так понятней?
Спасибо!
С моей личной практической точки зрения, это тот «низкий» порог «угадывания» который меня устроил. Мне не нужно угадывать какие будут структуры моделей, как нужно со временем менять модели и мигрировать данные, мне нужно только время от времени добавлять индексы к полям, причем совсем необязательно перед тем как события записаны — индексы можно добавить в любой момент.
2. Только в некотором смысле — в том плане что я сохраняю данные в событиях в таком виде в котором использование индексов для того чтобы найти эти события было настолько тривиальным насколько это возможно. Случаи, когда таки приходится делать агрегацию событий для оптимизации конечно происходят, но я стараюсь это свести к минимуму.
Я не писал, что нужна обязательно реляционная база данных, выше в комментариях я написал «часто это реляционная база данных». Доменную модель и правда можно хранить где угодно. Если доменная модель в памяти, это не значит что read side нету, просто она в памяти.
Можно прекрасно делать то что вы описываете («кешировать в памяти доменную модель из которой и брать нужные вещи, In-memory cache можно восстанавливать по событиям при старте приложения») однако это не решает ту задачу которая была передо мной — избежать планирования доменной модели («предугадывание будущего»), и дорогостоящих «переигрываний» событий.
если разбивать файлы в которых лежат необходимые ключи (например, consistent hashing или на исторические «отрезки») и хранить на независимых устройствах (в терминах дисков ли, или сетевых устройств) то можно обеспечить сценарий в котором чтение из writedb практически независимо от записи. пока что этого ф-ционала нет, но это интересная тема!
по итогам:
1. более актуальная информация чем в традиционном варианте — уже лучше.
2. как я упоминал в статье, конечно есть случаи когда массовые выборки будут медленными, и так или иначе агрегировать и/или кешировать данные надо. идеального мира нет :)
3. не обязательно, это зависит от того как она устроена. append only дает определенные преимущества.
При этой модели, state db в классическом понимании нет, как нету и «единой» модели данных.
Так понятней, или все еще плохо объяснил?