Какую БД использовать для быстро меняющихся данных?

Question

[GilbertAmethyst]

Здравствуйте!

Задача:
К серверу на NodeJS по Socket.IO подключается более двух тысяч устройств и передают данные с интервалом от 5 до 40 секунд. Данные нужно обновлять для каждого устройства в неком хранилище + вести историю (интервал давности: месяц, частота: ежедневные показатели) Система будет увеличиваться в последствии (устройств будет больше).

Наслышан о nosql базах, но дел пока с ними не имел, работал только с Mysql, но учитывая количество данных и потенциальный рост потребностей и их усложнение думаю начать изучать, особенно принимая во внимание явное увеличение длительности ответа текущей бд. Думаю о Redis или Mongo, но буду рад узнать и о других вариантах, если они здесь будут удачно применимы.

Суть вопроса:
Какую технологию выбрать?
На сколько сложна технология, каков шанс допускать критические ошибки при одновременном обучении и проектировке продакшена?
На какие ограничения стоит обратить внимание, чтобы не факапнуться, если выберу её в долгую?

Comments

[sim3x]

на NodeJS по Socket.IO

почему именно так?

[GilbertAmethyst]

sim3x, Требуется наибыстрейшая реакция сервера на передачу данных и отвал клиентов

[sim3x]

GilbertAmethyst, тогда тем более - нода не при чем

[d'Ivan]

GilbertAmethyst, какое решение в итоге было выбрано?

Answer 1

[d'Ivan]

подключается более двух тысяч устройств и передают данные с интервалом от 5 до 40 секунд.

вести историю (интервал давности: месяц, частота: ежедневные показатели)

Если речь лишь о периодическом добавлении каких-то одних и тех же метрик (числовых значений) во времени, то нужно выбирать что-то из Time Series баз данных типа InfluxDB, Prometheus и др.
Для IoT устройств нужно выбирать СУБД исходя из структуры хранимых данных, частоты добавления, способа извлечения данных.
Для часто обновляемых данных можно взять какую-нибудь быструю K/V СУБД (NoSQL) типа Tarantool, Aerospike или попсовую Redis. Туда стоит класть какие-то небольшие несырые данные, поскольку используется доступная RAM. Это должны быть часто используемые данные. Часто используются для кеша и очередей.

Советую получше изучить какие сырые данные будут передаваться, как будут вычисляться/аггрегироваться/обрабатываться и как часто. Прикинуть примерные объемы на ближайший срок и оставить возможность для роста на порядок. Оценить примерные объемы чистых хранимых данных, исходя их типов передаваемых данных, для того чтобы примерно можно было оценить объем хранилища.

Также подумать о применении систем обработки данных в очереди.

Answer 2

[Developer]

Redis - это очень хороший вариант.
Если сервис быстрорастущий, то нужно предусмотреть горизонтальное масштабирование и тогда надо будет использовать Redis Cluster https://redis.io/topics/cluster-tutorial

Comments

[Александр]

А вы сами кластер редиса-то вживую щупали?

Answer 3

[m0nym]

InfluxDB специализированная СУБД для подобных данных, если я правильно понял вашу задачу.
Или Tarantool - держит все в оперативной памяти, быстрее и не придумаешь.
Или Aerospike - типа Tarantool, но задействует диск, подходит, если оперативки маловато.

Comments

[d'Ivan]

Дублирует мой ответ.

[m0nym]

Роман Мирр,

Дублирует мой ответ.

О, как ревностно вы следите за тем, чтобы вас никто не обошел.

Но ваш ответ, извините, вода водянистая. Просто список технологий, без пояснений.

Prometheus в вашем ответе - это вообще о другом.

Чувствуется, что вы не понимаете, того, о чем пишете.

[d'Ivan]

m0nym, ну так у вас как-бы не развернутее, просто повторение.
А что насчет Prometheus, может я что-то упустил?

[Johny Smith]

Роман Мирр, не обращайте внимания, он мне тоже сегодня чтото совершенно бесполезное писал

[m0nym]

Роман Мирр, Прометей - не СУБД.
А система мониторинга

[m0nym]

Olek1, я не виноват, что вы еще недостаточно компетентны, чтобы понять ответы.

[d'Ivan]

m0nym, ну, хорошо, Прометей - это не чисто СУБД для хранения временных рядов, а имеет ещё и другие функции. Суть же от этого не меняется! Хранить историю метрик позволяет также как и InfluxDB. То есть позволяет вести историю ежедневных показателей, как автор и просил.

Prometheus в вашем ответе - это вообще о другом.

Так о чём же тогда?
https://prometheus.io/assets/architecture.svg

Answer 4

[Александр]

Смотрите, если у вас данные в виде Time-Series метрик, что-то подобное мониторингу, стоит использовать описанные выше Prometheus или Influxdb. Вторая на больших объемах хранимых данных не очень стабильна и довольно прожорлива. Но опять же, никто не отменял агрегацию данных, уменьшение частоты хранимых точек, т.е. через месяц посекундные данные агрегировать поминутно. Если записи много, а чтение не так часто, что-то вроде статистики, то можно заюзать кликхаус, у него очень впечатляющая скорость записи, неплохая возможность кластеризации, запросы похожи на обычный SQL. Стоит исходить из времени хранения, если данные будут жить условно сутки-двое, то конечно, можно использовать In-Memory базы типа редиса. Либо, как выше сказано, аэроспайк. Но то, что он умеет сбрасывать на диск, не значит, что его стоит использовать, как персистентное хранилище