Агрегация данных в реальном времени по временным интервалам

Question

У меня есть требование, и я смотрю, есть ли уже решение для такой проблемы.

У меня есть поток целочисленных данных, назовем его x, поступающего из источника с отметкой времени , Мне нужно агрегировать максимальное и минимальное значение x во временном интервале 2 minutes, 5 minutes, 15 minutes и т. Д. c и сохранять его в БД.

Я думал об агрегировании в памяти и сохраните совокупный результат в БД в конце каждого временного интервала. Но если приложение cra sh или перезапустится, я потеряю эти данные. Это заставило меня задуматься о том, есть ли уже решение для такой проблемы.

Редактировать : немного больше деталей

Данные представляют собой крупномасштабные данные с одной меткой, например {label, x, timestamp} , Я не хочу хранить все данные, которые я получаю. Мне нужно сохранить только мин и макс для каждого временного окна.

Например, следующий поток данных.

time  label  value
1     A       200
1     A       12 
1     B       23 
2     A       23
2     B       400
3     A       23
3     B       2
4     A       4
4     B       12


Output needed

For the first five minute
A min: 4 max: 200
B min: 2 max: 400

Next five minute
.....
.....

Answer 1

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

В вашем конкретном примере вы привели пример системы торгов. Если вы агрегируете ставки, как узнать, у кого самая высокая или самая низкая цена? Эта система только для аналитических целей или сама система заявок?

У вас есть пара вариантов.

Вы можете хранить агрегаты в базе данных, например MySQL или Postgres. Вы должны убедиться, что это настройка HA (например, ведущий-ведомый), чтобы обеспечить работоспособность во время сбоя узла. Недостатком этого подхода является то, что ваша таблица начнет снижать производительность, как только она попадет в диапазон 5М-10М. При 5 000 за 5 минут вы накопите около 1,4 млн. В день. Это может быстро столкнуться с проблемами масштабирования в будущем. Я видел системы, которые go обходили это с помощью ручных разделов и шардинга, что добавляет немало накладных расходов. Вам также придется обрабатывать данные, чтобы сэкономить место.

Другой вариант - попробовать базу данных временных рядов, разработанную для таких рабочих нагрузок, как, например, Hyprcubd . Отказ от ответственности: я основатель. Я бы не советовал, если он не подходит для вашего случая использования. Если вам нужны транзакции, это не очень подходит, поскольку Hyprcubd не поддерживает транзакции. Если вы отслеживаете только (time, label, bid), это может сработать. Вы даже можете хранить каждую необработанную ставку без агрегирования (time, label, bid, user), что значительно упростит ваш код. Ваш код станет без гражданства.