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

Question

Моя программа получает тысячи событий в секунду от разных типов. Например, 100 тыс. API-доступа в секунду от пользователей с миллионами разных IP-адресов. Я хочу вести статистику и ограничить количество обращений за 1 минуту, 1 час, 1 день и так далее. Поэтому мне нужно количество событий в последнюю минуту, час или день для каждого пользователя, и я хочу, чтобы оно было как скользящее окно В этом случае тип события - это адрес пользователя.

Я начал использовать базу данных временных рядов InfluxDB; но ему не удалось вставить 100 тыс. событий в секунду, а агрегированные запросы для поиска количества событий за минуту или час еще хуже. Я уверен, что InfluxDB не способен вставлять 100 тыс. Событий в секунду и одновременно выполнять агрегированные 300 тыс. Запросов.

Я не хочу, чтобы события извлекались из базы данных, потому что они являются простым адресом. Я просто хочу посчитать их как можно быстрее в разные промежутки времени. Я хочу получить количество событий типа x за определенный промежуток времени (например, за последние 1 час).

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

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

Существует ли какая-либо хорошая структура данных или даже база данных для этой цели?

Answer 1

Вы не предоставили достаточно информации о формате ввода событий и о том, как события могут быть доставлены в бэкэнд статистики: это поток сообщений udp, запросы http put / post или что-то еще.

Одним из возможных решений было бы использование базы данных Yandex Clickhouse . Грубое описание предлагаемой модели:

1. Загрузка входящих необработанных событий из вашего приложения в основанную на памяти таблицу События с Buffer storage engine
2. Создание материализованного представления с поминутной агрегацией в другом основанная на памяти таблица EventsPerMinute с механизмом буфера
3. Сделайте то же самое для ежечасной агрегации данных в EventsPerHour
4. По желанию, используйте Grafana с плагином для источника данных clickhouse Щитки

В Clickhouse DB Buffer механизм хранения, не связанный ни с одной таблицей на диске, будет полностью храниться в памяти, а более старые данные будут автоматически заменяться на новые. Это даст вам простую уборку необработанных данных.

Таблицы (материализованные представления) EventsPerMinute и EventsPerHour также могут быть созданы с помощью механизма хранения MergeTree, если вы хотите сохранить статистику на диске. Clickhouse может легко обрабатывать миллиарды записей.

При 100 тыс. Событий в секунду перед базой данных может потребоваться какой-либо формирователь / балансировщик нагрузки.

Answer 2

вы можете думать о кластере Hazelcast вместо простого барана. Я также думаю, что серый журнал или простой упругий поиск, но с такой нагрузкой вы должны проверить. Вы также можете подумать о своей структуре данных. Вы можете построить часовую карту для каждого адреса и поместить событие в часовую корзину. И когда время проходит час, вы можете рассчитать количество и кеш в корзине этого часа. Когда вам нужна минутная детализация, вы переходите к списку часов и подсчитываете события в списке этого часа.