powered by simpleCommunicator - 2.0.40     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / БД для объектов с разным количеством параметров
6 сообщений из 6, страница 1 из 1
БД для объектов с разным количеством параметров
    #40125980
Andi_WEB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Уважаемые участники!
Добрый день.

Есть потребность сделать базу данных для системы по типу "умный дом". Устройства разные, у каждого может быть от 5 до 10 контроллируемых технологических параметров. Устройств пока до 10 штук, потом может быть больше. Сохранять значения параметров нужно, скажем, каждую минуту. В целом, темп поступления данных в базу как будто бы не очень большой, но на самом деле все не так просто, о чем ниже.

Первое, что приходит в голову (если опустить детали) - это сделать две таблицы. Главная таблица, где для каждого сбора измерений от конкретного устройства есть запись с уникальным UUID. И вторая таблица, где для этого же UUID имеется некоторое число записей (5-10 по числу технологических параметров от устройства) с идентификатором типа параметра и самими данными в varchar, там в основном числа с двумя знаками после запятой и немного true/false, преобразовывать как потребуется можно уже потом, при выборке. В обоих таблицах, разумеется, не помешают и timestamp. Это схема простая и очевидная, но: берем калькулятор и получаем, что за год число записей от уже имеющихся устройств может перевалить за 30 миллионов.

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

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

Есть вариант данные не клать в отдельные строки, а упаковать в типы "массив" и тогда раз в ~десять можно сократить общее число записей. Все данные хранить (как и в первом варианте) в виде массивов переменной длины из varchar. Общее число строк сократится (это плюс), сложности при выборке возрастут, и мне ведь еще в принципе не известно, как быстро будет все это работать с массивами.

Скажите, пожалуйста - что на Ваш взгляд лучше? Первый вариант, второй, или посоветуете в принципе другой метод?
...
Рейтинг: 0 / 0
БД для объектов с разным количеством параметров
    #40126008
D0KX
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
используйте комбинацию типовых колонок (id устройства, время снятия данных и т.д.) + колонку с jsonb
...
Рейтинг: 0 / 0
БД для объектов с разным количеством параметров
    #40126011
Andi_WEB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
D0KX, думал насчет чего то подобного, по типу пар "параметр-значение". А PG умеет работать с jsonb, как потом быть с выборками? Это ведь как-то не совсем к СУБД? P.S. Да, вижу, тип такой есть. Интересно, на практике удобно, быстро ли?
...
Рейтинг: 0 / 0
БД для объектов с разным количеством параметров
    #40126050
Andi_WEB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
D0KX, спасибо за совет. Мне определенно стоит подумать. Во всяком случае, что-то по типу:

Код: plsql
1.
SELECT (data->>'id_param')::int, (data->>'value')::real FROM cards



вполне дает то, что нужно пока.
...
Рейтинг: 0 / 0
БД для объектов с разным количеством параметров
    #40126189
fte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
D0KX,

Почитайте timescaledb
...
Рейтинг: 0 / 0
БД для объектов с разным количеством параметров
    #40126191
PizzaPizza
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Andi_WEB
но: берем калькулятор и получаем, что за год число записей от уже имеющихся устройств может перевалить за 30 миллионов.


В чем проблема для базы работать с 30м записей вида число / число / число

Andi_WEB

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


То есть не надо работать с 30м записей? В чем тогда сомнения и зачем вьюхи?

Andi_WEB

данными в varchar, там в основном числа с двумя знаками после запятой и немного true/false, преобразовывать как потребуется можно уже потом, при выборке


Разработка в стиле garbage in - garbage out ? Что бы посчитать количество trueв придется вычитывать буквально все данные, "преобразовывать" и только потом считать.

Andi_WEB

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


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

Andi_WEB

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

Вам не не выбирать надо, а только хранить данные? Тогда да. Упаковывайте. Распаковывать то не надо.
...
Рейтинг: 0 / 0
6 сообщений из 6, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / БД для объектов с разным количеством параметров
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]