|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
24.01.2018, 12:53 | #11 | |
Регистрация: 23.01.2018
Сообщений: 8
|
Цитата:
Я именно вам о биржевой аналитике и говорил Неплохой вариант, надо у пользователей будет спросить - насколько им свечки понравятся Похоже я опять на те же вилы, только в бОльшем масштабе. Буду оптимизировать, разбивать, усреднять, обрезать Походу, больше никак. Может тоже свой движок запилить эффективнее будет. Байтовые структуры, 1:1 под данные. И на каждого юзера просто файл. Вариант. Но сперва проверю Postgres+JSONB по таблице на пользователя. Последний раз редактировалось Osolemio; 24.01.2018 в 13:28. |
|
24.01.2018, 18:16 | #12 | |
Регистрация: 23.01.2018
Сообщений: 8
|
Цитата:
Вот мой типичный пример описан: https://www.mongodb.com/blog/post/sc...ata-in-mongodb Буду сразу на клиенте формировать один JSON документ/запись и сразу на сервере его загонять. Ключ для шардинга вроде должен по user_id + device_id получиться. В теории пока все красиво. За исключением того, что для Ларавеля придется 2 БД иметь: SQL + NoSQL. Говорят, вроде можно. Надо пробовать, короче Железо само собой. Планируется железный выделенный сервер + .... Еще раз спасибо за общение. Последний раз редактировалось Osolemio; 24.01.2018 в 18:22. |
|
25.01.2018, 08:14 | #13 | |
Старожил
Регистрация: 25.02.2007
Сообщений: 4,160
|
Цитата:
|
|
25.01.2018, 13:13 | #14 | |
Регистрация: 23.01.2018
Сообщений: 8
|
Цитата:
Попробовал Mongo на моих структурах. Похоже - то, что мне надо. Особенно с подходом, описанным по ссылке. Могу создавать сразу на клиенте минутный документ с вложенными объектами и самое главное - массивами измерений. Какие-то значения, которые в течение минуты не меняются могут быть по одному. Например, значения температуры за минуту вполне достаточно одного. А какие-то массивом по 60. На каждого пользователя по коллекции. Коллекцию можно ограничить и легко создать индекс по временным меткам. Самое главное - не надо держать пустых структур под неиспользуемое оборудование. И еще одна штука: в процессе эксплуатации оборудование может наращиваться и данные меняться. С реляционной будет гемор. А здесь просто начнут добавляться новые подобъекты. Похоже с таким подходом одни плюсы: Коллекции получаются не сильно большие, на будущее шардинг легко индексируется, нет пустых заполнителей и документы минутные, не отменяющие посекундные измерения исключительно того, что необходимо. В процессе эксплуатации будет легко добавить новые поля (хоть все уже более-менее статично, но по клиентам я проживал период постоянных апдейтов прошивок оборудования и добавление новых полей). Пока на макете у меня все красиво. Сейчас надо все дописать нормально и погонять на реальных данных. Я честно говоря скептически был настроен изначально на noSQL для этого проекта. Но вот этот подход группировки нужных измерений в массивы и эффективное запихивание данных произвел на меня впечатление Потому как иначе, даже учитывая internal JSONB, все же получалась бы неповоротливая огромадина. Последний раз редактировалось Osolemio; 25.01.2018 в 13:27. |
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Проектирование ИС | dzuga777 | Помощь студентам | 0 | 21.03.2014 15:47 |
Проектирование ИС | Foxx111 | Помощь студентам | 0 | 24.12.2013 21:36 |
Проектирование БД | Morgusha | SQL, базы данных | 1 | 03.06.2012 10:22 |
проектирование бд | NieL | Помощь студентам | 1 | 28.04.2011 18:04 |
может убрать репу совсем ? | wm_leviathan | Свободное общение | 3 | 11.02.2011 00:12 |