Лучший способ включить агрегированные подсчеты документов как часть перколяционных запросов - PullRequest
Новая
       18

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

0 голосов
/ 03 июля 2018

Представьте, что у меня есть поток событий, каждое из которых имеет определенный тип события и относится к определенному пользователю / учетной записи

Пользователи могут настраивать оповещения в форме

  • Отправить уведомление, когда событие A произошло 3 раза в течение последнего года / месяца / дня и т. Д.

Я бы ожидал получать сотни таких событий в секунду

Я думал, что у меня будет отдельный индекс для каждого дня

Я также думал о том, будет ли каким-то образом необходимо предварительное агрегирование, поскольку выполнение отдельного запроса агрегации / подсчета для каждого входящего события кажется чрезмерным и не масштабируемым, но, возможно, это не проблема?

Как лучше всего подойти к этой проблеме?

1 Ответ

0 голосов
/ 03 июля 2018

Один подход, который приходит мне в голову:

  • Наличие индивидуального запроса для каждого пользователя с его настройками. Разрешение им добавлять события со словом «ошибка» к уровню ошибки, например.
  • Каждое событие индексируется в одном индексе для каждого клиента, и, возможно, если у вас много событий для каждого клиента, полезно иметь индекс для уровня каждого клиента, например events_clientId_alarm.

Тогда отображение события должно быть примерно таким: 

{
  "indexed_at": datetime,
  "level": keyword [fatal/error/debug/...],
  "log": string
}

Тогда у вас будет поток событий, приходящих на фильтрацию, после того, как событие будет перколировано, вы будете знать, где хранить событие.

Затем вы можете подходить кибана / графана и т. Д., Чтобы отслеживать данные ваших индексов и создавать аварийные сигналы, если в течение последних 5 минут было 4 события с аварийными сигналами уровня.

В худшем случае у вас будет один индекс с более или менее 8640000 * 365 документами (если у вас только один пользователь со 100 / событиями в секунду), это огромный индекс, но ElasticSearch может правильно управлять им (добавляя достаточное количество осколков для поиска / агрегации по уровню журнала и датам.

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

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

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

...