Какую посоветуете базу данных с динамическим набором полей?

Question

[cjitkul33]

Посоветуйте, пожалуйста, базу данных, где не нужно определять набор полей заранее.
Т.е. данные поступают от датчиков в виде "идентификатор,параметр:значение,параметр:значение", количество таких параметров может быть один, а может быть много. И не известно вообще какие могут параметры.

По нагрузке - записей достаточно много - несколько миллионов в сутки.

Из базы потом хочется удобно извлекать данные запросами, оперируя значениями параметров, например "where sensID = '555' and param1 > 123 and param2 < 123 and datetime between ()"

Или вообще лучше как-то иначе сделать?

Answer 1

[Евгений Бухарев]

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

Comments

[cjitkul33]

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

Answer 2

[xmoonlight]

mysql >=5.7 + json

Comments

[cjitkul33]

Слышал, что json-поля в mysql - не лучшее решение. Вы сами используете их? Есть какие-то косяки? Как со скоростью?

[xmoonlight]

cjitkul33: Если что-то слышали - говорите: "где именно и что". А то мне это напоминает лай собаки при шуме ветра.)
Да, я работаю с json - проблем никаких со скоростью: главное - не забывать индексацию полей ставить и создавать индексы. косяков нет. это просто подуровень объекта json. А в целом: такая же таблица (только виртуальная, в системном индексе)

[Alexander Pushkarev]

cjitkul33: раньше было не очень их использовать, когда не было поддержки json. Все пихали его в text поле и манипуляций с ним нельзя было делать. Сейчас всё изменилось.

[cjitkul33]

xmoonlight: т.е. если слышал, но не помню где, то нужно промолчать об этом и тупо следовать совету, так что ли? И опять же, если бы помнил, то возможно и вопрос бы не задавал. К тому же, ваше сравнение было бы уместно, если бы я что-то утверждал, а в данном случае это было неким пояснением - откуда ноги у вопроса растут.

А как с большими объемами данных дела обстоят? Тоже проблем не возникает? Я почему-то вариант mysql вообще не рассматривал изначально. Наверное попробую.

[xmoonlight]

cjitkul33: Абсолютно нет проблем, т.к. это доп.логика внутри основной. (понятнее стало?!)

[cjitkul33]

xmoonlight: нет, понятнее не стало, но это повод пойти найти что почитать. Спасибо.

[xmoonlight]

cjitkul33: советую читать родную документацию к mysql.

[cjitkul33]

xmoonlight: в родной документации не говорят о том, что все плохо :) Реальный отзыв всегда ценен.

[xmoonlight]

cjitkul33: ну вообще да, но в данный момент - всё честно :)

Answer 3

[d-stream]

Тут как бы одно из двух - либо достаточно жесткую регулярность в виде классических таблиц с жестко задекларированными полями (что дает возможность строить специфичные хинты для поиска, отбора, сортировки - индексы), либо получать некую "гибкость", но теряя возможности регулярных операций.

На мой взгляд озвученная задача вполне вписывается в классику реляционных структур:
id, порядковый номер параметра, значение параметра
или даже
id, порядковый номер параметра, тип параметра, значение параметра

соответственно тогда все вкусности сортировки, группировки, агрегирования, поиска - будут доступны во всей красе

Comments

[cjitkul33]

Но мне кажется, что то, что я описал, вообще не вписывается в подобную схему.

[d-stream]

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

А при наличии информации о типе параметра и допустимых значениях - можно будет еще и отсеивать "плохие". Любые варианты "упаковки" этого в json или просто строки - просто потребуют при каждом обращении распаковки собственно в тот же вид, что я описал.

[cjitkul33]

d-stream: вот именно, что хотелось избежать схемы "одна строка на один параметр". Удобно для записи, но не очень-то удобно для последующей работы, особенно с очень большими объемами.

[d-stream]

cjitkul33: почему? какие сложности?
а сборка их "в кучу" - это значит на каждом телодвижении разбирать/распарсивать эту кучу...

из муки, сахара, молока, дрожжей, воды, соли - можно сделать блинчики, можно пирожки, можно брагу в конце концов, а вот из их смеси - что-то одно (в зависимости от того как и что с чем смешали)

[cjitkul33]

d-stream: все же таки не парсить, а делать выборку запросом. Причем простым, без лишних join-ов. Как в этой схеме сделать простейшую выборку как приводил пример в вопросе - "select param 3 from table where sensID = '555' and param1 > 123 and param2 < 123 and datetime between ()"?
Я, если честно, не очень понимаю.

[d-stream]

cjitkul33: ну к примеру пришли мы к нечто типа id и кучка параметров в одну строку:

1 t:20; u:15; i:200
2 i:18;z;48

где и что искать - хз

в ситуации же типа id, тип_датчика, значение (пока не заглубляясь в типы значений) получим
1,1,20
1,2,15
1,3,200
2,3,18
2,4,48

и оттуда уже можно получить либо список показаний конкретного датчика в виде
select * from ... where id=...

или показания конкретного типа
select * from ... where тип_датчика=...

ну и далее

притом "свернуть" это в строку (например для печати) - без проблем

[cjitkul33]

d-stream: к сожалению, я совершенно не понял вашу мысль. Боюсь предположить, но у меня складывается ощущение, что вы вместо одного простого запроса предлагаете сделать сделать несколько, создать временную таблицу поместить туда результаты и уже по ним сделать тот самый искомый простой запрос? Вы находите это менее сложным, чем пример моего запроса? Или я правда вас не так понял?

[d-stream]

cjitkul33: скорее всего - не поняли.
Попробую еще раз свое видение:
1. ориентируемся на классические "прямоугольные" таблицы
2. структура таблиц вида:
- id датчика
- тип параметра
- значение параметра
3. получая данные с датчиков - мы однократно разбираем строку списка на отдельные параметры и помещаем в базу по строчке на параметр

Собственно все.
Дальнейшие запросы на все случаи жизни будут совершенно элементарными.

Притом что характерно - эти запросы будут отлично пониматься оптимизатором SQL и отрабатываться максимально эффективно.

Далее, развив конструкцию - можно добавить "настроечные таблицы" где будут заданы для каждого типа параметров допустимые диапазоны - опять же простейшим запросом аж с одним join получить грубо говоря разбивку по исправному/сбойному состоянию

Развив конструкцию еще на шаг - добавим таблицу групп оборудования и опять же одно-пара-строчно получим "степень сбойности" посчитав соотношение параметров группы датчиков в допуске и вне допуска

[cjitkul33]

d-stream: "и помещаем в базу по строчке на параметр" - и все-таки, можете привести пример запроса при таком подходе, аналогичный примеру из моего вопроса:
"select param 3 from table where sensID = '555' and param1 > 123 and param2 < 123 and datetime between ()"
param1, param2, param3 - этот как раз те параметры, которые вы предлагаете разбить по разным строчкам таблицы.
При этом учесть, что в таблице много-много миллионов записей. Если разбивать на "1 параметр - 1 запись", то таблица распухнет в Х раз.

[d-stream]

cjitkul33: таблица-то распухнет, но каждое поле будет в индексе => это будет быстро, а поиск в неких строках или их эквивалентах - это перебрать все строки и поискать в каждой. Примерно как искать в толстой книжке по глоссарию или же перелистывать все страницы.

а запрос собственно примитивен:

select
*
from table
where
sensId=555
and (param_id=1 and param_value>123)
and (param_id=2 and param_value<123)
and datetime between date_from and date_to

различие в условии лишь в том, что вместо paramX ? val фигурирует (param_id=X and param_value ? val)

p/s/ И да, арифметика распухания:
param1 - это 6 байт, двоеточие - еще байт, точка с запятой - еще, ну и если значения гуляют в пределах 256 значений - еще байт... то бишь 9 байт, а
id параметра - пусть 4 байта+1 байт на значение = 5 байт

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

[cjitkul33]

d-stream: Оставим пока распухание, но как в вашем запросе в выборку попадет искомое значение param3, или, придерживаясь вашего варианта, param_value с param_id равный 3-м? Ваш запрос в таком виде вообще должен отработать как-то странно.

[d-stream]

cjitkul33: проверить проще простого: создать табличку, забить туда пару десятков строк и попробовать запрос

[cjitkul33]

d-stream: понятно, что не работает подобный запрос, но я все-равно попробовал, да.