Какое подобрать хранилище 3 триллионов событий?

Question

[Blowspirit]

Нужно подобрать хранилище в которое будет поступать большой объем однотипных событий (до 3 миллионов в секунду).
Глубина хранения 1 месяц - это примерно 3 триллиона событий.
Выборка событий будет происходить с использованием фильтров по полям в среднем раз в секунду.
Соответственно хранилище должно уметь горизонтально масштабироваться на 100-1000 узлов, быть надежным и проверенным решением, быть устойчивым к отказам узлов, делать быстро выборку по разным критериям с возможностью сортировки, поддерживать java клиента.

Comments

[sim3x]

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

И оценочную $

[Blowspirit]

"быстро" - поиск не более 5-10 секунд за конкретную дату и не более 30-60 если поиск производится за месяц.
"устойчивым к отказам узлов" - при отказе узла данные не должны теряться, т.е. нужна авто репликация данных
"быть надежным и проверенным решением" - малоизвестное решение, которое не решало схожего масштаба задачи не рассматривается
И оценочную $ - бесплатное и opensource решение

[lega]

Blowspirit: > малоизвестное решение, которое не решало схожего масштаба задачи не рассматривается

Тогда вам только велосипедить, что многие и делают

[nirvimel]

до 3 миллионов в секунду

Биржевые тики?
А зачем их хранить так долго? Если в реальном времени не хватает скорости на их обработку, то и в дальнем времени на это не будет. Оправданна очередь на обработку максимум в несколько минут, чтобы сгладить профиль вычислительной нагрузки в моменты "штормов".

[Tsimur_S]

nirvimel: еще возможен Iot и миллион сенсоров)

[Blowspirit]

nirvimel: хранятся не тики, а события от устройств. Обработка в реальном времени не нужна, поэтому и храним за месяц

[lega]

Blowspirit: > а события от устройств
от wifi точек?

[Дмитрий Энтелис]

Я ради интереса подпишусь, но не думаю что будет бесплатное и opensource которое по факту решало такие задачи. Это все-таки ну очень специфическая задача при высокой нагрузке - если кто то себе и напишет - вряд ли отдадут в паблик.

[Дмитрий Энтелис]

Blowspirit: в рамках оффтопика - у вас объем хранилища без индексов ~2ПБайт, это как бы не дешево весьма по железу. Почему при этом накладывается ограничение что софт должен быть бесплатным?

[lega]

Дмитрий Энтелис: Вот и я про тоже

[profesor08]

Дмитрий Энтелис: похалявить

[Blowspirit]

У меня есть пока следующие соображения:
1. поскольку при поиске данных всегда фигурирует id устройства и временной диапазон, то можно это дело хранить в hdfs в структуре типа /id_устройства/день/файл_с_данными. Соответственно нужный файл (~400мб) или файлы мы можем быстро найти, а затем данные в нем мы фильтруем с помощью чего-либо (spark, flink или hive??).
2. Можно хранить данные в кластере с elasticsearch выпилив ненужные поисковые причиндалы (full-text) из структуры данных. Идея такая: создаем каждый день новый индекс(аля база данных в реляционных терминах) где к названии индекса будем в постфиксе добавлять текущую дату. В индексе будет будет где-то 130-150 шардов (т.к. 1 шард это максимум ~2 миллиарда событий). Поисковый запрос в elasticsearch позволяет искать сразу в нескольких индексах (можно использовать соответствующие паттерны в запросе). Плюс в эластике каждое поле уже автоматом является индексом что большой плюс. Тут очень интересно насколько адекватно такой кластер с таким количеством шардов будет работать

[Blowspirit]

Итог: попробовали несколько макетов, самым интересным оказался hadoop.
hdfs - используем для хранения данных, MapReduce - для аналитики

Answer 1

[Dimonchik]

Yandex Clickhouse (тут на веру Яндексу только, зато как раз под задачу)
Aerospike
еще начать можно с DynamoDB, там готово все, только плати

только с 3 трлн и 5-10 сек очень не уверен, так или иначе придется что-то предобрабатывать

Comments

[Blowspirit]

Clickhouse конечно хорош, но это OLAP решение, а мы аналитические запросы не будем делать, нам нужна только фильтрация. Плюс там есть ограничение - результат выполнения запроса должен помещаться в оперативку на одном сервере.
Aerospike - это kev/value БД, т.е. сортировку и поиск по критериями уже не выполнить. Возможно ошибаюсь, т.к. с этой базой глубоко не знаком.
DynamoDB - платная, руководство такое врядли пропустит, плюс это также key/value БД

Answer 2

[Tsimur_S]

Tarantool и AeroSpike ? Или возможно стоит посмотреть в сторону time series database?
https://www.influxdata.com/influxdb-vs-cassandra-b...
Может ещё кассандра справится с безумным количеством серверов, но вообще больше миллиона записей в секунду это на данный момент слабо реализуемо.

Answer 3

[lega]

Скорость ssd до 550Mb/sec, если события по 20б, то можете по файликам разливать ~27 млн событий в сек (одного канала не хватит чтобы нагрузить)

Выборка событий будет происходить с использованием фильтров по полям в среднем раз в секунду.

Разливайте в "доль" фильтров и будет норм.

Comments

[Blowspirit]

Одно событие весит примерно 150 байт. С учетом необходимость большого количества ssd это под вопросом. А если разливать события вручную на диск, то фактически вы предлагаете использовать полностью самописное решение для шардинга, репликации, индексации и тд, что конечно же не комильфо

[lega]

Blowspirit: > С учетом необходимость большого количества ssd это под вопросом
Можно на HDD, будет медленнее, но тоже быстро, или вы как планировали?, если заливать в БД то размер будет ещё больше.

> полностью самописное
Не полностью (для шардинга и репликации можно gridfs например), но да, для большой нагрузки все делают кастомные решения, думаете поиск гугла или яндекса на каком нибудь sphinx/elastic работает что ли?

Хотя можете попробовать что-то готовое "тормозное", (покажите мне хоть один сервер БД который может 27 млн/сек на одной ноде)

[Дмитрий Энтелис]

lega sdd с "файликами" упрется в iops очень быстро

[lega]

Дмитрий Энтелис: Упрется в последнюю очередь, другие решения упрутся гораздо раньше в 99%.
+ некто не отменял кеширование и балансинг.

Answer 4

[index0h]

KDB+

Answer 5

[ELazin]

Akumuli может записывать 4.5 миллиона событий в секунду на единственном m3.2xlarge инстансе (если события представимы в виде комбинации набора тегов, метки времени и числа с плавающей точкой).

Answer 6

[Максим Тимофеев]

https://www.oracle.com/database/solutions/index.html

Answer 7

[Петр]

Azure Datalake