LINUX.ORG.RU

NoSQL БД для временных рядов. Посоветуйте подход к проектированию или готовую.

 , , временные ряды,


1

4

Уже был один топик — Посоветуйте БД для кучи данных по мониторингу. Но требования упростились.

Итак, 3 сейсмостанции на объекте присылают по 450 байт бинарных данных каждые пол-секунды. Надо писать все приходящие данные в базу данных (т.е. в среднем 6 записей в секунду общим весом 2.7 КиБ) с отметками времени. Также необходимо сжатие данных, которые кладутся на хард, на лету.

Плюс со всех объектов (их будет около 15) надо в реальном времени складировать входящие данные на сервера хранения (их два), то есть на сервера хранения будет поступать уже 90 записей в секунду общим весом 40 КиБ (т.е. около 3 млрд записей на 1 ТиБ в год, если не учитывать сжатие). Это не обязательно должна делать сама БД, я это могу реализовать прослойкой, в т.ч. клиент-серверной.

Что касается чтения: нужен буфер последних нескольких секунд (но это не обязательно должно быть в самой БД, могу сделать прослойку, которая будет класть все новые данные в БД + держать кеш в памяти) и возможность быстро получить все данные по одной или нескольким сейсмостанциям за заданный период.

Система должна работать годами без всяческого вмешательства.

Есть ли что-либо готовое, что удовлетворит таким требованиям? Смотрю в сторону SciDB, но пока не особо разбирался, мутноватая она какая-то.

Или, может быть, порекомендуете, как лучше реализовать такое самому? В каком формате хранить данные на харде (HDF5?), как сжимать, как дублировать на сервера хранения?

★★★★★

Ответ на: комментарий от anonymous

Нужен только свободный софт, это требование заказчика.

Obey-Kun ★★★★★
() автор топика

В каком формате хранить данные на харде (HDF5?),

Если формат одной записи известен и длина фиксирована, то тупо друг за другом.

как сжимать,

zlib?

как дублировать на сервера хранения?

Если скажем посуточные бэкапы, то тупо копировать файл записанный за сутки, каждые сутки создается новый файл.

Если непрерывно, то дублировать на сервер входящие данные и делать там все то же самое.

AIv ★★★★★
()

Можно посмотреть в сторону CouchDB.

unfo ★★★★★
()

Такой поток потянет практически любая СУБД, но все они требуют периодического обслуживания. Так что в очередной раз советую сделать руками binary log.

В каком формате хранить данные на харде (HDF5?)

простой бинарный лог типа { (HEADER, data, TAIL) } + ротация файлов при достижении определённого размера или кол-ва записей + сжатие старых файлов (последние несколько держим для быстрого доступа). Т.е. практически syslog c logrotate, но только для бинарных данных.

TAIL это ~ размер блока, для чтения файла в обратном направлении.

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

индекс будет через именования файлов, типа OBJ_ID/20101010T1400

как дублировать на сервера хранения

в двух словах, через очереди, что-то типа ZMQ или свои реализации. Всё зависит от насколько автономно всё должно работать и как важны данные.

mashina ★★★★★
()
Ответ на: комментарий от mashina

простой бинарный лог типа { (HEADER, data, TAIL) } + ротация файлов при достижении определённого размера или кол-ва записей

Какого размера? Как много файлов можно держать в директории, В файловой системе? Не поможет ли древовидность директорий?

Obey-Kun ★★★★★
() автор топика
Ответ на: комментарий от Reset

Судя по всему, классная вещь. Даже сможет оповещать наш софт о новых данных, т.е. не придётся делать для этого прослойку. Надо изучить. И компрессия есть. В общем, видимо, это нам подходит, большое спасибо!

Obey-Kun ★★★★★
() автор топика
Ответ на: комментарий от Obey-Kun

Увы, не годится. Нам надо хранить всё с милисекундами, но...

Can I store sub-second precision timestamps in OpenTSDB?

No. Right now timestamps are encoded on 4 bytes so this is not possible. Note that this is not typically needed for OpenTSDB's main use case, which consists in monitoring large clusters of commodity machines. If you think you really need sub-second precision, please reach out to our mailing list for advices: opentsdb@googlegroups.com

Плюс в ней бинарные данные, как я понял, нельзя хранить — только числа.

Obey-Kun ★★★★★
() автор топика
Ответ на: комментарий от Obey-Kun

Какого размера?

от нескольких мб до десятков.

Как много файлов можно держать в директории

зависит от ФС. Все более-менее современные ФС могут хорошо переваривать десятки/сотни тыс. файлов (ext3/4, xfs и т.п.).

Не поможет ли древовидность директорий?

поможет, если придётся работать когда-либо с файлами человеческими руками.

mashina ★★★★★
()
Ответ на: комментарий от mashina

Постгрес - это наше все !

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

Задача у вас самая обычная для постгреса, никаких особых челенджей не вижу.

megera
()

Задача самая обычная для постгреса, не вижу ничего такого особого.

megera
()
Ответ на: Постгрес - это наше все ! от megera

Не хочу я релятивную БД для этого. По идеологии не подходит. Вот сам подумай, есть данные за 3 года, а нам нужно взять кусок с 2013-10-10 14:10:15 по 2013-10-10 14:20:21. NoSQL БД, заточенная под временные ряды, заведомо будет делать такую операцию быстрее.

Obey-Kun ★★★★★
() автор топика
Последнее исправление: Obey-Kun (всего исправлений: 2)
Ответ на: комментарий от Obey-Kun

Не хочу я релятивную БД для этого

Реляционную же.

encyrtid ★★★★★
()
Ответ на: комментарий от Obey-Kun

Вот сам подумай, есть данные за 3 года, а нам нужно взять кусок с 2013-10-10 14:10:15 по 2013-10-10 14:20:21.

Создаешь интовый столбец с time_t, строишь по нему индекс, дальше простым селектом получаешь данные за интервал

annulen ★★★★★
()
Ответ на: комментарий от Obey-Kun

Да складывайте в бинарные файлы, как mashina советует. Названия файлов - какая-то функция от таймстампов (ну там таймстамп со сброшенными последними битами, например), будет компактно и с быстрым выделением диапазонов

Deleted
()
Ответ на: Постгрес - это наше все ! от megera

Постгрес - это наше все !

ничего страшного, детский максимализм проходит, хотя не у всех.

mashina ★★★★★
()
Ответ на: комментарий от annulen

Создаешь интовый столбец с time_t, строишь по нему индекс, дальше простым селектом получаешь данные за интервал

отлично придумал. Ещё стоит сказать, что его оценочный 1 ТиБ/год увеличится до 2-6 на пустом месте

mashina ★★★★★
()
Ответ на: комментарий от mashina

Но не может 'работать годами без всяческого вмешательства'

пруфлинк в студию

true_admin ★★★★★
()
Ответ на: комментарий от Obey-Kun

ошибаешься 8) она будет быстрее в некоторых других случаях

Deleted
()
Ответ на: комментарий от true_admin

Тогда data partitioning.

и как это поможет избавиться от лишних Тб? Тем болеев Pg партиционированое настоящщий гемор, навряд ли получится его автоматизировать на N лет так, чтобы совсем не нужно было обслуживвать.

mashina ★★★★★
()
Ответ на: комментарий от Deleted

махровый nosql с индексами выжрет также, или будет дооолго думать на запросах 8)

понимаешь в чём дело.. индексы здесь для быстрых выборок не нужны. По крайней мере такие горомоздкие и совсем GP, как в реляционных СУБД.

mashina ★★★★★
()
Ответ на: комментарий от mashina

и как это поможет избавиться от лишних Тб?

я думал ты писал про увеличение ДБ в два-три раза из-за расстановки индексов. Предложил вариант как ускорить селект без индекса.

навряд ли получится его автоматизировать на N лет так, чтобы совсем не нужно было обслуживвать.

Судя по докам, правил придётся нагенерить много (на N лет вперёд), это, безусловное, слабое место постгреса.

Что ты подразумеваешься под «обслуживанием»? С чего ему ломаться?

true_admin ★★★★★
()
Ответ на: комментарий от mashina

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

А может ты просто не знаешь что такое b-tree и метанируешь начитавшись хабра?

Deleted
()

MongoDB - элементарно работать. Cassandra - куча данных, no single point of failure, высокая производительность. Чрезвычайно высокая производительность если потеря данных иногда (очень редко) - это нормально

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от vertexua

Что касается чтения: нужен буфер последних нескольких секунд

MongoDB capped collection

vertexua ★★★★★
()
Ответ на: комментарий от true_admin

ну давайте альтернативы что ли, разрешенные. а то я вашего брата хорошо знаю - стоит мне начать использовать «Вы изволили оскорбить мой слух и обоняние» как это быстро станет запрещенным. плавали знаем

Deleted
()
Ответ на: комментарий от vertexua

через 10 лет о них всех забудут, и речи нет о столь долгой поддержке формата баз, закопать

Deleted
()
Ответ на: комментарий от Deleted

Ваш диалог достоин второго класса младшей школы. «Будет быстрее - Нет не будет - Нет будет». Причем тут вообще она реляционка или нет на одной то коллекции или таблице? Важно что внутри

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)

Компрессию может поддерживать твоя файловая система, надо посмотреть чтобы это не мешало базе

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от Deleted

автор хочет автоматизьму

автор хочет один раз сделать и забить, а это подрузамевает работу сервисов в локалке и годы без обновлений («работает — не трогай»).

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Я тоже так подумал. Если у тебя база 10 летней давности, то можно ее средствами сделать дамп в какой-то простой формат. А потом уже импортировать в супер-пупер базу 2025 года

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

Вы какраз пересказал мой пост - на указанно запросе разницы не будет, если будут индексы.

Deleted
()
Ответ на: комментарий от vertexua

Разница будет, но совершенно в непредсказуемую сторону.

Признайся Вам просто нечего сказать было.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.