Нужно подобрать хранилище в которое будет поступать большой объем однотипных событий (до 3 миллионов в секунду).
Глубина хранения 1 месяц - это примерно 3 триллиона событий.
Выборка событий будет происходить с использованием фильтров по полям в среднем раз в секунду.
Соответственно хранилище должно уметь горизонтально масштабироваться на 100-1000 узлов, быть надежным и проверенным решением, быть устойчивым к отказам узлов, делать быстро выборку по разным критериям с возможностью сортировки, поддерживать java клиента.
"быстро" - поиск не более 5-10 секунд за конкретную дату и не более 30-60 если поиск производится за месяц.
"устойчивым к отказам узлов" - при отказе узла данные не должны теряться, т.е. нужна авто репликация данных
"быть надежным и проверенным решением" - малоизвестное решение, которое не решало схожего масштаба задачи не рассматривается
И оценочную $ - бесплатное и opensource решение
Биржевые тики?
А зачем их хранить так долго? Если в реальном времени не хватает скорости на их обработку, то и в дальнем времени на это не будет. Оправданна очередь на обработку максимум в несколько минут, чтобы сгладить профиль вычислительной нагрузки в моменты "штормов".
Я ради интереса подпишусь, но не думаю что будет бесплатное и opensource которое по факту решало такие задачи. Это все-таки ну очень специфическая задача при высокой нагрузке - если кто то себе и напишет - вряд ли отдадут в паблик.
Blowspirit: в рамках оффтопика - у вас объем хранилища без индексов ~2ПБайт, это как бы не дешево весьма по железу. Почему при этом накладывается ограничение что софт должен быть бесплатным?
У меня есть пока следующие соображения:
1. поскольку при поиске данных всегда фигурирует id устройства и временной диапазон, то можно это дело хранить в hdfs в структуре типа /id_устройства/день/файл_с_данными. Соответственно нужный файл (~400мб) или файлы мы можем быстро найти, а затем данные в нем мы фильтруем с помощью чего-либо (spark, flink или hive??).
2. Можно хранить данные в кластере с elasticsearch выпилив ненужные поисковые причиндалы (full-text) из структуры данных. Идея такая: создаем каждый день новый индекс(аля база данных в реляционных терминах) где к названии индекса будем в постфиксе добавлять текущую дату. В индексе будет будет где-то 130-150 шардов (т.к. 1 шард это максимум ~2 миллиарда событий). Поисковый запрос в elasticsearch позволяет искать сразу в нескольких индексах (можно использовать соответствующие паттерны в запросе). Плюс в эластике каждое поле уже автоматом является индексом что большой плюс. Тут очень интересно насколько адекватно такой кластер с таким количеством шардов будет работать
Clickhouse конечно хорош, но это OLAP решение, а мы аналитические запросы не будем делать, нам нужна только фильтрация. Плюс там есть ограничение - результат выполнения запроса должен помещаться в оперативку на одном сервере.
Aerospike - это kev/value БД, т.е. сортировку и поиск по критериями уже не выполнить. Возможно ошибаюсь, т.к. с этой базой глубоко не знаком.
DynamoDB - платная, руководство такое врядли пропустит, плюс это также key/value БД
Tarantool и AeroSpike ? Или возможно стоит посмотреть в сторону time series database? https://www.influxdata.com/influxdb-vs-cassandra-b...
Может ещё кассандра справится с безумным количеством серверов, но вообще больше миллиона записей в секунду это на данный момент слабо реализуемо.
Одно событие весит примерно 150 байт. С учетом необходимость большого количества ssd это под вопросом. А если разливать события вручную на диск, то фактически вы предлагаете использовать полностью самописное решение для шардинга, репликации, индексации и тд, что конечно же не комильфо
Blowspirit: > С учетом необходимость большого количества ssd это под вопросом
Можно на HDD, будет медленнее, но тоже быстро, или вы как планировали?, если заливать в БД то размер будет ещё больше.
> полностью самописное
Не полностью (для шардинга и репликации можно gridfs например), но да, для большой нагрузки все делают кастомные решения, думаете поиск гугла или яндекса на каком нибудь sphinx/elastic работает что ли?
Хотя можете попробовать что-то готовое "тормозное", (покажите мне хоть один сервер БД который может 27 млн/сек на одной ноде)
Akumuli может записывать 4.5 миллиона событий в секунду на единственном m3.2xlarge инстансе (если события представимы в виде комбинации набора тегов, метки времени и числа с плавающей точкой).
