|
|
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Есть 50 установок, разбросанных по всему миру, который выполняют некоторые задачи. К каждой приставлен оператор, который следит за работой установок, данные с 16 датчиков кодируются в бинарном виде и ходят в интернет на единый сервер, расшифровываются и складываются в базу mysql. Данные с каждой установки отправляются каждые 10 минут. Длина каждой посылки 47 байт. Данные с датчиков будут вида: 12.123 с округлением до тысячных, либо целые значения: 12. (Всего 50 таблиц с параметрами для каждой установки ??) На сервере должен быть написан веб-клиент - мониторирование всех параметров всех устройств. Оператор клиента должен наблюдать 16 параметров для каждой из 50 установок на одной странице (а значит выборка из 50 таблиц за раз ??), и при выходе параметра за диапазон разрешенных значений (например, температура одной из установок слишком высокая) видеть уведомление о выходе за диапазон, страница обновляется каждые несколько минут. История должна хранится за все время существования установок. Проект рассчитан на 5 - 10 лет. Через несколько лет размер таблиц будет немаленький, как не наделать ошибок ? Нужны ли какие нибудь вспомогательные таблицы ? Так как предусмотрена статистика, например количество моточасов за месяц / год, то выборки из базы могут быть довольно объемными. Можно ли заставить mysql сравнивать значения с датчиков и отдавать в php ключ, превысил ли параметр значения или нет, или это бессмысленно и можно предоставить это самому php ? Данные о верхних и нижних границах значений для каждой установки будут храниться в двух таблицах, min и max. Есть ли смысл делать таблицу актуальных значений ? Данные с датчиков каждые десять минут складываются в актуальную базу и в базу истории для каждой установки. И при обновлении клиента-монитора шевелить не огромную гигабайтную базу а маленькую актуальную ? Какие типы полей стоит выбрать ? Кодировка предполагается utf-8 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 08:50 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Илья Александрович 2, Парметры для каждой установки одинаковые? Если да, то зачем 50 таблиц? Если нет, то как минимум есть общие параметры и т.д. надо анализировать. авторМожно ли заставить mysql сравнивать значения с датчиков и отдавать в php ключ, нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 09:13 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Максим Н, Параметры одинаковые. Предлагаете складывать все в одну таблицу с указанием id установки ?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 09:24 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Илья Александрович 2Параметры одинаковые. Предлагаете складывать все в одну таблицу с указанием id установки ??Разумеется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 09:35 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Илья Александрович 2, угу, если нагрузки возрастут, то разбивка по таблицам наврядли вас спасет. А вот сопровождать и поддерживать будет неудобно. Что если у вас добавится еще 50 установок, а потом еще и еще? полуОФФ: с мускулем вы точно уже определились, а то сдесь мог бы подойти какой-ть ноусиквел? Чего-нибудь документоориентированное. Где то видел презентацию, там у парня датчики напрямую писали свои данные в коучдб по http ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 09:45 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Илья Александрович 2данные с 16 датчиков кодируются в бинарном виде и ходят в интернет на единый сервер, расшифровываются и складываются в базу mysql. Данные с каждой установки отправляются каждые 10 минут. Длина каждой посылки 47 байт .Это на каждый датчик выходит меньше 3 байт, или я чего-то не понял? Илья Александрович 2Проект рассчитан на 5 - 10 лет. Через несколько лет размер таблиц будет немаленькийКаждые 10 минут по 47 байт (допустим, всё так и есть), 50 посылок = каждый час 47*6*50=14100 байт, каждые сутки 338400 байт, каждый год - 123 516 000 байт. То есть 123 мегабайта данных в год. Ну накинем ещё на служебную инфу, индексы и т.п., пусть будет 250Мб в год. К гигабайту вы подберётесь где-то как раз через 5 лет :) Илья Александрович 2Кодировка предполагается utf-8А при чём тут вообще кодировка, у вас же числовые параметры, или я ещё что-то пропустил? Илья Александрович 2Есть ли смысл делать таблицу актуальных значений ? Данные с датчиков каждые десять минут складываются в актуальную базу и в базу истории для каждой установки. И при обновлении клиента-монитора шевелить не огромную гигабайтную базу а маленькую актуальную ?Да нагенерите тестовых данных гига три (т.е. с запасом), сделайте нужные индексы и погоняйте запросы (на железе, сравнимом с продакшеном). Будет медленно - тогда можно и подумать об отделении истории... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 10:09 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Илья Александрович 2Максим Н, Параметры одинаковые. Предлагаете складывать все в одну таблицу с указанием id установки ?? Если параметры "разные", или завтра окажется что их количество увеличится то рекомендуется завести отдельно таблицу параметров и в таблице резальтатов ID параметра. В этом случае таблице результатов упрощается. Вместо полей для каждого их паратметров достаточно двух полей (в дополнение к полю со временем снятия параметра): - id параметра - значение параметра. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 10:12 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Илья Александрович 2, Код: sql 1. Поддерживаю предложение с одной таблицей (ИД-установки, ИД-параметра, дата-время замера, значение). Код: sql 1. Две колонки min и max в одной таблице. Код: sql 1. 2. 3. Такой подход применяется. Возможно, при формировании отчетов он удобен. При Ваших объемах данных и частоте формирования отчетов и записи в базу, имхо, непринципиально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 10:36 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Илья Александрович 2, Таблица установок, таблица параметров, таблица полученных значений. Возможно еще потребуется таблица пользователей и т.п., но Вы об этом пока умалчиваете или недогадываетесь. Возможно еще что-то ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 10:42 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
tanglir, Да, 47 байт, большая часть датчиков логические и передают по одному байту, а аналоговые датчики передают информацию в 16ричном виде. Пока неясно стоит ли писать 16ричные коды или все же преобразовывать их и писать числа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 11:04 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Как бы пост типа "я ничего не знаю, я ничего не умею, расскажите мне, как, а я сделаю может быть и беготни за это получу". Не, так не делается, не получится. Если борешься за дело, ты должен как-либо то что-то уметь уже делать подобное, хотя бы учебные примеры какие-то. А ты даже базовые принципы проектирования бд не понимаешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 12:07 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Илья Александрович 2Оператор клиента должен наблюдать 16 параметров для каждой из 50 установок на одной странице (а значит выборка из 50 таблиц за раз ??), и при выходе параметра за диапазон разрешенных значений (например, температура одной из установок слишком высокая) видеть уведомление о выходе за диапазон, страница обновляется каждые несколько минут. А установка выдержит работать несколько минут с перегревом?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 12:23 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Вам отношения повыяснять захотелось ? Я на звание мастера mysql не претендую, но учусь. И учусь от людей которые написали выше, а от вас я только время теряю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 12:26 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovА установка выдержит работать несколько минут с перегревом?.. Да пофиг. Даешь второй Чернобыль!.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 12:27 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, Установка выдержит, некритично ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 12:27 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Илья Александрович 2Установка выдержит, некритично Ну вот, взял и обламал. Эх... Там кстати может народ еще график захочет видеть. График изменения параметра за определенное время имею ввиду. Просто цифра интересна для текущего состояния, а вот посмотреть за период более воспринимается графика а не цифры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 12:31 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
В любом случае, на мой взгляд обычное desktop-приложение, получающее данные в режиме реального времени прямо от сервера сбора информации, а не из базы, будет удобнее, менее требовательно к ресурсам и оперативнее. В этом случае проектирование БД перестаёт быть критичным, поскольку она работает как тупое хранилище архивных данных и единственное остающееся к ней требование - надёжность (AKA durability). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 12:44 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Илья Александрович 2, Я у себя телеметрию пихал в блоб поле. То есть в бинарный массив, в котором было порядка сорока тысяч отсчетов в формате short int (2 байта). Такой массив соответствовл примерно 1,5 сек работы системы. Тут нужно понимать, что отдельный отсчет, не представляет из себя независимой сущности, его важность (значение) идет в контексте Например, утром значение отсчета 12 - это нормально, а вечером, например, плохо. То есть привязка отсчетов ко универсальному штампу времени - очень важна, а просто набор каких-то чисел в порядке поступления - для конечного автомата важно, а для СУБД не важно, ибо данными в СУБД оперируют не в реальном времени, а используют их для последующего многократного анализа. То есть здесь вопрос к назначению СУБД зачем понадобилось писать телеметрию в базу? Первое Чаще всего, для временного сопоставления графиков с какими-то изветсными внешними событиями происходящими в это время - ага вот тут и появляется штамп времени! Второе Источники сигналов иногда обладают зависимостью (корреляцией) иногда нет, поэтому помимо самого числа нужно вести учет от какого источника оно получено. Третье В обычной СУБД, например, часто интересен запрос возвращающий ону запись - например "сколько у меня товара такого-то артикула на складе А" или "какова стоимость фин инструмента на дату Б". С отсчетами сигнала не так, они обрабатываются пачками. То есть, как минимум нужна будет не одна точка, а значения сигнала в окрестности. Соответственно, обычный подход - одна строка в таблице - одно значение, может оказаться неприменимым как с точки зрения производительности, так и с точки зрения информативности и логики использования информации. Как-то так пишите если что ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 12:57 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Илья Александрович 2 Я на звание мастера mysql не претендую, но учусь. И учусь от людей которые написали выше, а от вас я только время теряю Ты теряешь время уже создав этот пост и читая его. Читать надо книжки, учебники. А не форумы. На форумах научиться невозможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 12:57 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
MasterZivИлья Александрович 2Я на звание мастера mysql не претендую, но учусь. И учусь от людей которые написали выше, а от вас я только время теряю Ты теряешь время уже создав этот пост и читая его. Читать надо книжки, учебники. А не форумы. На форумах научиться невозможно. но можно получше рассмотреть грабли практической реализации ;) а выбор СУБД вторичен, да хоть на dbf-е ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 13:00 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Злой Бобр, Графики будут, да, народ требует зрелищ :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 13:19 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, Клиент хочет веб. Под все это дело будет стоять железный сервер и хоститься будет на нем же ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 13:20 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Илья Александрович 2Клиент хочет веб. Под все это дело будет стоять железный сервер и хоститься будет на нем же Да все равно нагрузка на БД не нужна. Данные поступают на app-server, там анализируются (благо одновременно нужна маленькая выборка) и асинхронно пишутся в БД (на всякий случай и если придется сервер перезагрузить). Там всей работы, по описанию, на несколько недель. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 13:57 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Разбивку по таблицам лучше делать горизонталько (aka секционирование, партиционирование) Есть подозрение что старые данные будут затребованы ОЧЕНЬ редко. Если ваш mysql это не умеет то можно сделать это вручную типа create table data2013 (data, check entry_date between '01.01.2013' and '31.12.2013') create table data2014 (data, check entry_date between '01.01.2014' and '31.12.2014') create table data2015 (data, check entry_date between '01.01.2015' and '31.12.2015') create view data as select * from data2013 where check entry_date between '01.01.2013' and '31.12.2013' union all select * from data2014 where check entry_date between '01.01.2014' and '31.12.2014' union all select * from data2015 where check entry_date between '01.01.2015' and '31.12.2015' Фильтры на дату нужны чтобы облегчить оптимизатору отсекание ненужных партиций Здесь разбивка по годам только для примера. Самая изощренная реализация которую я видел - в течении месяца по дням, в течении года по месяцам, остальное по годам. Перенос данных происходит мгновенно тк делается путем alter view само собой вставлять надо в реальную таблицу и разруливая синонимом или обновляемой вьюхой Проработайте момент типа: установка шлет данные, а база лежит или выдает ошибки и т.д. Как раз для этих целей вводят брокера который всегда жив и умеет только принять данные и засунуть их куда нибудь в файл. Хранить все 16 параметров "в строчку" или "в столбик" не принципиально. Таки да, если все установки разные, то в столбик удобнее. Если все одинаково, то в строчку будет проще удобнее и быстрее, но при добавлении другой установки придется делать alter table. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 20:00 |
|
||
|
Посоветуйте, как проектировать базу
|
|||
|---|---|---|---|
|
#18+
Илья Александрович 2Пока неясно стоит ли писать 16ричные коды или все же преобразовывать их и писать числа.Зависит от того, будет ли какая то логика на уровне СУБД Например, условия в запросах, расчёты и т.д. Если СУБД только хранит, то можно и 16ричные коды (а ещё лучше бинарные данные, это в 2 раза меньше места). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2013, 23:18 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38339001&tid=1541167]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
151ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 248ms |
| total: | 505ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...