Проблемы производительности с большими наборами данных

Question

Есть ли способ фильтрации событий в проекции, связанной с моделью чтения, по aggregateId?

В проведенных тестах мы всегда получаем все зарегистрированных событий.Можно ли применить фильтры на предыдущем этапе?

У нас есть 100 000 aggregateId, и каждому id соответствует 15 000 events.Невозможно отфильтровать по aggregateId, наши проекции должны повторяться по all events.

Answer 1

Таким образом, у вас есть 100 000 агрегатов с 15.000 событиями в каждом.

Вы можете использовать ReadModel или ViewModel :

Читать модель :

Модель чтения может рассматриваться как база данных чтения для вашего приложения.Поэтому, если вы хотите сохранить некоторые данные о каждом агрегате, вы должны вставить / обновить строку или запись в какой-либо таблице для каждого агрегата, см. Пример Hacker News, прочитайте код модели .

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

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

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

Настройка адаптеров плохо документирована, мы исправим это .Вот что вам нужно записать в соответствующем конфигурационном файле для mongoDB:

readModelAdapters: [
  {
    name: 'default',
    module: 'resolve-readmodel-mongo',
    options: {
      url: 'mongodb://127.0.0.1:27017/MyDatabaseName',
    }
  }
]

Поскольку у вас есть ядро ​​базы данных, вы можете использовать его и для хранилища событий:

storageAdapter: {
  module: 'resolve-storage-mongo',
  options: {
    url: 'mongodb://127.0.0.1:27017/MyDatabaseName',
    collectionName: 'Events'
  }
}

ViewModel ViewModel создается на лету во время запроса.Не требует хранения, но читает все события для данного aggregateId.

reSolve view модели используют снимки.Таким образом, если у вас есть 15.000 событий для данного агрегата, то при первом запросе все эти события будут применены для первого расчета состояния соперников.После этого это состояние будет сохранено, и все последующие запросы будут считывать снимок и все последующие события.По умолчанию снимок делается на 100 событий.Таким образом, во втором запросе reSolve прочитает снимок для этой модели представления и применит к нему не более 100 событий.

Опять-таки, имейте в виду, что если вы хотите, чтобы хранилище снимков было постоянным, вы должны настроитьадаптер снимков:

snapshotAdapter: {
  module: 'resolve-snapshot-lite',
  options: {
    pathToFile: 'path/to/file',
    bucketSize: 100
  }
}

У ViewModel есть еще одно преимущество - если вы используете промежуточное программное обеспечение resol-redux на клиенте, оно будет там постоянно обновляться, реактивно применяя события, которые приложение получает через веб-сокеты.