Проектирование большой БД. Чешу репу

[Osolemio]

Сообщение от ADSoft

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

Слава Богу, мне дискретные данные отображать не нужно. Максимум - в виде таблицы.
Я именно вам о биржевой аналитике и говорил Неплохой вариант, надо у пользователей будет спросить - насколько им свечки понравятся
Похоже я опять на те же вилы, только в бОльшем масштабе. Буду оптимизировать, разбивать, усреднять, обрезать Походу, больше никак.
Может тоже свой движок запилить эффективнее будет. Байтовые структуры, 1:1 под данные. И на каждого юзера просто файл. Вариант.
Но сперва проверю Postgres+JSONB по таблице на пользователя.

[Osolemio]

Сообщение от ADSoft

p.s - ну и как бы не извращались при таких объемах - железо должно быть на уровне, на стареньком компе в кладовке вряд ли получится все быстро и красиво )

Похоже надо в сторону MongoDB все же смотреть. По отзывам весьма шустро big data логов обрабатывает по временнЫм выборкам. Это как раз у меня основное. Да и шардинг. И данные переделывать не придется.
Вот мой типичный пример описан:
https://www.mongodb.com/blog/post/sc...ata-in-mongodb

Буду сразу на клиенте формировать один JSON документ/запись и сразу на сервере его загонять. Ключ для шардинга вроде должен по user_id + device_id получиться. В теории пока все красиво. За исключением того, что для Ларавеля придется 2 БД иметь: SQL + NoSQL. Говорят, вроде можно. Надо пробовать, короче

Железо само собой. Планируется железный выделенный сервер + ....

Еще раз спасибо за общение.

[ADSoft]

что для Ларавеля придется 2 БД иметь: SQL + NoSQL.

это нормально..... + еще какая нить очередь бывает иногда типа RabbitMQ и другое зверье )))

[Osolemio]

Сообщение от ADSoft

это нормально..... + еще какая нить очередь бывает иногда типа RabbitMQ и другое зверье )))

Уже установил, все живет мирно. Спасибо

Попробовал Mongo на моих структурах. Похоже - то, что мне надо. Особенно с подходом, описанным по ссылке. Могу создавать сразу на клиенте минутный документ с вложенными объектами и самое главное - массивами измерений. Какие-то значения, которые в течение минуты не меняются могут быть по одному. Например, значения температуры за минуту вполне достаточно одного. А какие-то массивом по 60. На каждого пользователя по коллекции. Коллекцию можно ограничить и легко создать индекс по временным меткам.
Самое главное - не надо держать пустых структур под неиспользуемое оборудование. И еще одна штука: в процессе эксплуатации оборудование может наращиваться и данные меняться. С реляционной будет гемор. А здесь просто начнут добавляться новые подобъекты. Похоже с таким подходом одни плюсы: Коллекции получаются не сильно большие, на будущее шардинг легко индексируется, нет пустых заполнителей и документы минутные, не отменяющие посекундные измерения исключительно того, что необходимо. В процессе эксплуатации будет легко добавить новые поля (хоть все уже более-менее статично, но по клиентам я проживал период постоянных апдейтов прошивок оборудования и добавление новых полей).
Пока на макете у меня все красиво. Сейчас надо все дописать нормально и погонять на реальных данных. Я честно говоря скептически был настроен изначально на noSQL для этого проекта. Но вот этот подход группировки нужных измерений в массивы и эффективное запихивание данных произвел на меня впечатление Потому как иначе, даже учитывая internal JSONB, все же получалась бы неповоротливая огромадина.