Выбор БД для хранения показаний датчиков

[buddy]

Всем привет.

Плохо ориентируюсь в базах данных.
Порекомендуйте базу данных под следующие требования.
Один тип записи с ID датчика и меткой времени T.
Необходима выборка по ID последних N записей и выборка по ID за временной интервал T1-T2.
Хотелось самое простое и доступное в Erlang, то есть Mnesia, но, вероятно, такой тип использования не для нее.
Для disc_only_copies ограничение на нефрагментированную таблицу 2GB (это терпимо) и не поддерживается тип
ordered_set, что затруднит выборку (это уже хуже).

Или ответ простой - PostgreSQL?

[Max Lapshin]

postgresql — это очень хорошо.

Ещё могу порекомендовать clickhouse от яндекса, он крутой.

[Andy]

RRD?

понедельник, 11 июля 2016 г., 12:42:29 UTC+3 пользователь Max Lapshin написал:

[Yuri Zhloba]

Вообще для всех случаев, когда "Плохо ориентируюсь в базах данных.", PostgreSQL будет хорошим выбором :)

11 июля 2016 г., 12:57 пользователь Andy <agre...@gmail.com> написал:

--
Вы получили это сообщение, поскольку подписаны на группу "Erlang по-русски".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес erlang-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--

Yuri Zhloba

skype: yzh44yzh
phone: +375 44 793 33 73

[Andy]

Совать во все проекты SQL - нынче модно, но стоит ли? Из постановки я не увидел ни малейшей потребности в нем. Хотя огульно отрицать SQL - ныне тоже модно :)

понедельник, 11 июля 2016 г., 13:53:55 UTC+3 пользователь Yuri Zhloba написал:

[Lev Walkin]

Не используйте мнезию для time-series. Пробовал, плевался. Проблемы с ростом количества данных.

-- 

Lev

On Jul 11, 2016, at 07:25, Evgeny M <donped...@gmail.com> wrote:

Если нет проблем с RAM можно использовать Mnesia с disc_copies, там есть ordered_set. Ключ - {Id, время в секундах}

Еще вариант rocksdb от фейсбука, https://github.com/barrel-db/barrel_rocksdb, ключ <<ID:фикс.длина, время:фикс.длина>>

понедельник, 11 июля 2016 г., 12:41:11 UTC+3 пользователь buddy написал:

--

[hiend]

Беспредметно как-то сформулировано, какая нагрузка-то хоть предполагается? А-то может вам и ets/dets выше крыши )

LevelDB, RocksDB, HyperLevelDB смотрели?

понедельник, 11 июля 2016 г., 13:41:11 UTC+4 пользователь buddy написал:

[Max Lapshin]

Нет особой проблемы в том, что бы огульно пихать везде постгрес и потом по мере необходимости от него отказываться =)

[Alexander Chemeris]

Полагаю, что тебе нужна time series DB - погугли по этой ключевой фразе.
Из самых популярный сейчас - InfluxDB и OpenTSDB. Недавно появился Prometheus.
Мы используем influxDB у себя, но не из Erlang, так что не могу ничего
сказать, если для него вменяемые либы.

> --
> Вы получили это сообщение, поскольку подписаны на группу "Erlang по-русски".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес
> erlang-russia...@googlegroups.com.
> Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный
> адрес erlang-...@googlegroups.com.
> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.

--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co

[buddy]

Всем спасибо за ответы. Немного уточнений.
Данные от одного источника могут приходить через произвольные (не равные) промежутки времени (минимум - секундные интервалы).
Также желательно наличие репликации.
Про disc_copies в Mnesia думал, но не хотелось бы упираться в RAM.
Объем данных точно оценить сложно, порядок примерно следующий.
Количество источников данных: десятки тысяч; количество хранимых записей от одного источника: сотни тысяч; размер одной записи: сотни байт.
Для каждого источника данных нужно периодически подрезать записи: либо по количеству, либо по времени.

[Aleksey Kluchnikov]

В качестве размышлений.

Сама по себе задача хранить данные с датчиков, тяжелая. В случае ее решения  влоб, (храним каждое данное), сырых данных много, выборка по ним тоже тяжелая. Как результат требуется мощное железо иногда несуразно мощное. 

Может быть задача позволяет введение какого то усреднения? На каждый датчик заводим процесс, туда валим данные с датчика и там делаем статистику.  Какую нибудь скользящую среднюю. 

А потом уже опрашиваем процесс раз в минуту и складываем данное в rrd. Получатся графики и очень дешево

11 июля 2016 г., 23:40 пользователь buddy <tauce...@gmail.com> написал:

[begemot_sun]

понедельник, 11 июля 2016 г., 12:42:29 UTC+3 пользователь Max Lapshin написал:

postgresql — это очень хорошо.

Ещё могу порекомендовать clickhouse от яндекса, он крутой.

Макс, почему ты свой pusledb не советуешь ? https://github.com/pulsedb/pulsedb 

[Vladimir Lashko]

@begemot_sun:

наверно из-за этого - https://github.com/pulsedb/pulsedb/blob/master/LICENSE.txt

12 июля 2016 г., 9:28 пользователь begemot_sun <logu...@gmail.com> написал:

--

Вы получили это сообщение, поскольку подписаны на группу "Erlang по-русски".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес erlang-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--

Best regards, Vladimir Lashko

email: ostr...@gmail.com

cell: +79262299812

[Igor Karymov]

Не рекомендую mnesia брать для этой задачи, так как:

Вкратце: это не time series bd.

Списком:

 * обычно такие данные требуют большого количества вторичных индексов. В mnesia с этим плохо (все индексы в памяти, при большом количестве данных,- ОЧЕНЬ долгий старт)

 * если данных много, то вам понадобиться реализация шардирования по времени. С mnesia вы это будете делать руками.

 * в mnesia вы сможете постучаться только из erlang, а это автоматом лишает вас всего готового тулинга для аналитики

 * язык запросов не sql (по большому счёту тоже самое что предыдущий пункт)

Что я могу посоветовать в вашей ситуации ("не очень разбираюсь в БД"):

 * если нет времени эксперементировать и порядок данных  сотни гигабайт то postgresql.

При необходимости вы сможете разбить таблицу на несколько TABLESPACE средствами базы.

Написать adhook агрегации, архивации, и удаление старых данных (SQL вам в этом поможет).

 * Если данных больше (терабайты), хранить их надо все всегда и надёжно и вас тянет к новому и неизведанному.

То посмотрите в сторону свежеушедщего в opensource решения от basho http://basho.com/products/riak-ts/

У меня не было шанса попробовать его в production, но само решение довольно простое и прозрачное

с точки зрения архитектуры, и судя по описанию умеет всё что вам надо.

 

[Roman Gafurov]

Возможно претендую на место К.О., но если не ошибаюсь в Redis есть упорядоченные множества, которые поддерживают ограничение кол-ва записей и поиск по диапазону. Если в вашем случае использовать ID в качестве ключа и временную ветку в качестве оценки, то "выборка по ID последних N записей" -> 

ZREVRANGE <key> 0 N-1, а "выборка по ID за временной интервал T1-T2" -> ZREVRANGEBYSCORE <key> <from> <to>. Вот подробно о том, что я имею ввиду http://redis.io/commands/zadd.

[Max Lapshin]

pulsedb — встраиваемая БД для хранения метрик, которую мы написали для своих внутренних нужд.

Когда мы сравнивали её с influxdb, то там, где клиенту пришлось поставить кластер из 4-х серверов, у нас один инстанс не напрягался, но мы не решали вопрос с мультисерверностью.

Плюс pulsedb — это именно для однородных временных рядов. Если есть поток событий, то для него оно не годится.

[Alexandre Beniaminov]

Горячие  данные держать в Redis или Tarantool.

Холодные данные имеет смысл писать в любую SQL базу, например тот же Postgresql, которая поддерживает быстрый bulk insert из файла, потому как для SQL баз данных вставка  уже 10000 записей в секунду обычным insert проблематична.

13 июля 2016 г., 10:51 пользователь Roman Gafurov <gafurov...@gmail.com> написал:

Возможно претендую на место К.О., но если не ошибаюсь в Redis есть упорядоченные множества, которые поддерживают ограничение кол-ва записей и поиск по диапазону. Если в вашем случае использовать ID в качестве ключа и временную ветку в качестве оценки, то "выборка по ID последних N записей" -> 

ZREVRANGE <key> 0 N-1, а "выборка по ID за временной интервал T1-T2" -> ZREVRANGEBYSCORE <key> <from> <to>. Вот подробно о том, что я имею ввиду http://redis.io/commands/zadd.

--

Вы получили это сообщение, поскольку подписаны на группу "Erlang по-русски".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес erlang-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--

С уважением,
Александр Бениаминов

[Vladimir Potapev]

Можно вот по этой табличке попробовать выбрать: https://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis. Там для каждой СУБД описаны типовые юзкейсы.

Если данных действительно очень много, то, скорее всего, и впрямь будет удобнее разбить данные на "горячие" и "холодные". А ещё есть шардинг.

понедельник, 11 июля 2016 г., 15:41:11 UTC+6 пользователь buddy написал: