Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Проектирование БД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3]      все
 Re: БД для объектов с разным количеством параметров  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34630
Vladimir A.K.
SERG1257
ЕЕ

Как расшифролвывается ЕЕ?


Никак. Это название песни. (10-ая).
4 фев 14, 02:34    [15513786]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
SERG1257
Опять же танцуйте от печки. Определитесь с запросами и подгоняйте структуру под удобство/скорость запросов.

Это понятно. Будем копать :)
SERG1257
Если у вас популярный запрос - выведите мне состояние объекта ХХХ на время ЧЧ.ММ.СС, то собирание состояния объекта по параметрам может занимать слишком много времени. Дешевле собрать ее один раз во время загрузки.

Скорее будут вариации селекта: выбрать поля A, B, X, XY ... ZZZ в интервале времени при такх-то значенияз входов D, E ...
или просто в заданном интервале времени.
SERG1257
Здесь 15489997 я приводил список моих претензий к EAV структуре.

И все-таки, правильно ли я понимаю, что EAV, это растащить мою задачу на таблицу, где каждая запись:
id_записи, время_измерения, id_параметра, измеренное_значение?
SERG1257
По поводу загрузки. Как мне кажется загрузка должна быть в два этапа.
Делай раз - закидываем очередной файл в стейджинговую (временную) таблицу БД.
Делай два - одним (страшным) запросом рассовываем данные в постоянные таблицы. Тут важно обойтись без цикла, так будет быстрее и дешевле.

?
У меня на входе файл с несколькими тысячами записей (в каждой более сотни измеренных параметров на одно и то же время) с одного тепловоза (одна конфигурация). Потом другой файл. Может с этого, а может с другого тепловоза.
SERG1257
Далее - дата-время съема параметра для вашей структуры будет ключевым полем (первым полем первичного ключа). По этому полю надо будет обязательно кластеризовать (в Оракле это IOT) чтобы упростить очистку устаревших данных.

Одна "строка" (запись) во входящем файле содержит более сотни измеренных параметров. Время измерения для них одинаково.

SERG1257, читая ветку, нашел тут тему со схожей задачей (пусть она и проще), в которой Вы принимали активное участие: https://www.sql.ru/forum/789033/hranenie-parametrov-priborov?hl=???????
Мне показалось, что мое решение может быть походим: отдельный прибор (у меня АСУ) - отдельная таблица.
4 фев 14, 14:02    [15516373]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
йцуке
Если какие-либо данные в первой или во второй базе могут правиться руками, то со временем базы начнут "ехать". Например, один тепловоз обозвали по-разному в разных базах и т.д..

Это будет грубой ошибкой.
Наименование серий, нумерация экземпляров - вещь нормируемая.
В принципе задумка: при создании в приложении-менеджере формируется конфигурация АСУ: все входы выходы, с требуемыми характеристиками (коэффициенты, масштабирования, нумерация байт в записи из входного файла, типы и т.п.). По окончании в обоих базах делаются Create table по правилам каждой СУБД. В случае необходимости изменения конфигурации АСУ: считали из БД в мэнеджер, изменили, проверили корректность: alter table. Ну и, по необходимости вьюверы и т.п.
Пользователю сия возможность будет недоступна. только админу.
йцуке
Если потребуется сравнивать параметры разных конфигураций, может быть неудобно.

Спасибо. Подумаю над этим.
Хотя, с первого взгляда, скорее может потребоваться сравнение агрегатированных итогов обработки разных объектов, чем одномоментно измеренных параметров.
4 фев 14, 14:11    [15516455]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
MasterZiv
Никак. Это название песни. (10-ая).

5 Баллов!
Хорошая команда.
Купила мама коника ... :)
4 фев 14, 14:13    [15516470]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
йцуке
Member

Откуда:
Сообщений: 102
Vladimir A.K.,

1) Забудьте о EAV. Это не ваш случай.
2) Делить данные на несколько баз нужно лишь в случае четкого понимания необходимости этого. Например, в одной идет активная текущая работа (добавление/изменение) в другой интенсивный анализ, и делать это в одной базе одновременно не хватает производительности.
3) По загрузке, у каждого производителя есть утилиты/команды для массового импорта данных. Например, в MS SQL это bcp и bulk insert. Готовите данные, и ночью, пакетом, грузите.
4 фев 14, 16:41    [15517859]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
SERG1257
Member

Откуда:
Сообщений: 2790
автор
Скорее будут вариации селекта: выбрать поля A, B, X, XY ... ZZZ в интервале времени при такх-то значенияз входов D, E ...
или просто в заданном интервале времени.
Если при этом поля A, B, X, XY ... ZZZ и D, E будут в одной таблице то это выполнится быстрее чем если в нескольких.
Vladimir A.K.
И все-таки, правильно ли я понимаю, что EAV, это растащить мою задачу на таблицу, где каждая запись:
id_записи, время_измерения, id_параметра, измеренное_значение?
Да. Пожалуй я бы добавил id_объекта до кучи. Такая структура позволяет легко добавлять новые параметры, другими словами, добавление нового параметра не приводит к DDL операциям. Это ее основное достоинство, ну и входной файл имеет похожую структуру - импорт будет легко делать. Недостатки я описал.
Vladimir A.K.
Мне показалось, что мое решение может быть походим: отдельный прибор (у меня АСУ) - отдельная таблица.
Это уже лучше предыдущего подхода с одной таблицей на всех. Каждой такой таблице добавьте первичный ключ вида время_измерения + id_объекта и получите базу с вертикальным секционированием.

С другой стороны я не верю, что все параметры равнозначны. Например на приборной панели автомобиля водитель гораздо чаще смотрит на спидометр, чем на уровень бензина или километры пробега. Поработайте с пользователями чтобы объединить наиболее часто встречающиеся комбинации в общую таблицу типа время_измерения, id_объекта, параметр, параметр .... (см A, B, X, XY ... ZZZ и D, E выше). Остальное (менее популярное) можно сделать отдельными таблицами.
Vladimir A.K.
У меня на входе файл с несколькими тысячами записей (в каждой более сотни измеренных параметров на одно и то же время) с одного тепловоза (одна конфигурация). Потом другой файл. Может с этого, а может с другого тепловоза.
Именно. Я предостерегал от соблазна устроить цикл по записям.
Предположим что входной файл имеет структуру типа время_измерения, id_объекта, параметр, тогда для заполнения таблицы с несколькими параметрами параметр1 и параметр2 запрос будет типа
select event_datetime, id_object, max(param1),max(param2) from temp_table group by event_datetime, id_object

и уже этот запрос вы сливаете (merge) с вашей базой.

Vladimir A.K.
В принципе задумка: при создании в приложении-менеджере формируется конфигурация АСУ: все входы выходы, с требуемыми характеристиками (коэффициенты, масштабирования, нумерация байт в записи из входного файла, типы и т.п.). По окончании в обоих базах делаются Create table по правилам каждой СУБД. В случае необходимости изменения конфигурации АСУ: считали из БД в мэнеджер, изменили, проверили корректность: alter table.
Плохая идея. Нет, независимость от субд это, конечно, большой плюс для приложения, ошибкой является думать что достаточно правильно сделать Create table. У вас, по любому, будет отдельное приложение для каждой поддерживаемой СУБД. В общем, задача сложнее, чем кажется, советую сейчас с этим не заморачиватся.
4 фев 14, 17:59    [15518400]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
йцуке
Vladimir A.K.,

1) Забудьте о EAV. Это не ваш случай.

Да, спасибо. С помощью подсказок, в т.ч. и Ваших я уже понял, что это такое, и что это меня не устраивает :)
йцуке
2) Делить данные на несколько баз нужно лишь в случае четкого понимания необходимости этого. Например, в одной идет активная текущая работа (добавление/изменение) в другой интенсивный анализ, и делать это в одной базе одновременно не хватает производительности.

Понимание есть. Даже если это будут разные таблицы, то смысловая нагрузка у них разная.
Более конкретно:
1-я база. Назовем БД Эксплуатации. Та, в которой данных меньше и которые будут храниться постоянно (или очень долго).
Нужна для оценки оценки производственных показателей (типа тонно-километры, расход топлива и т.п) за разные отрезки времени. Или какие-то сходные статистические задачи.
В настоящий момент не используется. Требует доступности из внешнего мира: т.е. веб-сервер + БД.
Помните я рассказывал, что сервер купили черти когда, но его еще в глаза не видели? :)

2-я база. БД диагностики. Та в который данные за сравнительно небольшой отрезок времени, но в полном объеме.
Прогонка через алгоритмы, с выдачей неких итогов. Итоги, вполне возможно, будут накапливаться в специальных таблицах.
Причем существует большая вероятность, что при появлении нового алгоритма или модификации старого, когда-то уже обработанные данные будут опять импортироваться в БД и прогоняться по новой.
Тут БД интересно наверное скорее не как хранилище, а как некий универсальный механизм выборки данных по заданным критериям и выдачи их на вход алгоритма.
йцуке
3) По загрузке, у каждого производителя есть утилиты/команды для массового импорта данных. Например, в MS SQL это bcp и bulk insert. Готовите данные, и ночью, пакетом, грузите.

Спасибо за ценную информацию.
Зарубку сделал :)
5 фев 14, 09:30    [15520506]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
SERG1257
Если при этом поля A, B, X, XY ... ZZZ и D, E будут в одной таблице то это выполнится быстрее чем если в нескольких.

Забыл уточнить. С вероятностью близкой к единице могу предполагать, что конкретный запрос будет выбирать информацию из одной таблицы. Т.е. наиболее вероятна выборка для одного объекта (тепловоза) или максимум: для однотипных объектов.
SERG1257
Да. Пожалуй я бы добавил id_объекта до кучи.

Да точно. Ступил :)
SERG1257
Такая структура позволяет легко добавлять новые параметры, другими словами, добавление нового параметра не приводит к DDL операциям. Это ее основное достоинство, ну и входной файл имеет похожую структуру - импорт будет легко делать. Недостатки я описал.

Читал. Понял, что не мое.
SERG1257
Это уже лучше предыдущего подхода с одной таблицей на всех. Каждой такой таблице добавьте первичный ключ вида время_измерения + id_объекта и получите базу с вертикальным секционированием.

Да, конечно, время измерения + id_объекта обязательно будут присутствовать.
Инфу по ссылке изучу.
SERG1257
С другой стороны я не верю, что все параметры равнозначны. Например на приборной панели автомобиля водитель гораздо чаще смотрит на спидометр, чем на уровень бензина или километры пробега. Поработайте с пользователями чтобы объединить наиболее часто встречающиеся комбинации в общую таблицу типа время_измерения, id_объекта, параметр, параметр .... (см A, B, X, XY ... ZZZ и D, E выше). Остальное (менее популярное) можно сделать отдельными таблицами.

Я наверное опять не все корректно рассказал.
Входной файл представляет из себя ту же самую таблицу (2-мерную матрицу) со строками вида:
время_измерения, параметр_1, параметр_2, параметр_3 ... параметр_N.

Только вот количество N и типы параметров у разных объектов (АСУ тепловозов) - разные.
SERG1257
Плохая идея. Нет, независимость от субд это, конечно, большой плюс для приложения, ошибкой является думать что достаточно правильно сделать Create table. У вас, по любому, будет отдельное приложение для каждой поддерживаемой СУБД. В общем, задача сложнее, чем кажется, советую сейчас с этим не заморачиватся.

Хорошо. Забыли идею.
Одно или два приложения будет, для меня уж точно не является принципиальным вопросом :)
5 фев 14, 09:56    [15520599]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
йцуке
Member

Откуда:
Сообщений: 102
Vladimir A.K.
Понимание есть. Даже если это будут разные таблицы, то смысловая нагрузка у них разная.
Более конкретно:
1-я база. Назовем БД Эксплуатации. Та, в которой данных меньше и которые будут храниться постоянно (или очень долго).
Нужна для оценки оценки производственных показателей (типа тонно-километры, расход топлива и т.п) за разные отрезки времени. Или какие-то сходные статистические задачи.

2-я база. БД диагностики. Та в который данные за сравнительно небольшой отрезок времени, но в полном объеме.
Прогонка через алгоритмы, с выдачей неких итогов. Итоги, вполне возможно, будут накапливаться в специальных таблицах.
Причем существует большая вероятность, что при появлении нового алгоритма или модификации старого, когда-то уже обработанные данные будут опять импортироваться в БД и прогоняться по новой.
Тут БД интересно наверное скорее не как хранилище, а как некий универсальный механизм выборки данных по заданным критериям и выдачи их на вход алгоритма.

И, все-таки, делайте вначале одну базу. Разделить её на несколько, при необходимости, более чем просто. А вот объединись несколько баз в одну может быть весьма наоборот.
Упорно рекомендую попробовать промышленные базы. В них решен вопрос очень компактного хранения необходимых вам параметров (то, что у вас входит во 2-ю базу). Вполне вероятна ситуация, когда на одном и том же железе пром. база будет держать все данные лет за 5-10, а в самодельном решении затыкаться на данных за год.
5 фев 14, 13:29    [15522257]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
Уважаемые консультанты.
Есть идея по хранению описанных выше данных в БД. Возможно бредовая. Возможно не реализуемая.
Возникла так.
Есть новый АСУ. Пока в разработке-отладке. Данные с АСУ по мобильным сетям сразу скидываются в БД. У провайдера хостинга арендуется виртуальный сервер с PostgreSQL.

На данном этапе прорабатываю вариант импорта данных с этого сервера и заливки в нашу БД. В дальнейшем конечно же будет организована передача данных непосредственно на наш сервер, минуя посредников.
Запись (та самая, с кучей аналоговых и дискретных параметров) хранится в таблице в виде поля формата bytea: байтовый массив.
Первоначальная мысль: брать этот массив и запихивать в таблицу с кучей полей.
Но, может быть возможен такой вариант: хранить байтовый массив. Но написать вювер(ы) или хранимую процедуру(ы), которые будут брать этот массив и преобразовывать его в "таблицу", уже содержащую те самые поля с аналоговыми и дискретными полями.
Тогда фактически запросы будут нормальные, с именами полей вьювера, но хранение данных - оптимальное.

Насколько бредовая идея?
Я пока не представляю, насколько такое преобразование ресурсо-затратно. Видится, что работа с дисковой подсистемой будет гораздо проще: меньше полей читать, да и байт, соответственно, тоже меньше.
Так же не представляю, возможно ли вообще осуществление таких преобразований (разбор массива на байты и операции с ними) средствами SQL, т.к. с таким типом данных пока не работал вообще.

Потому и решил воспользоваться вашими знаниями для оценки "уровня бредовости" затеи :)
12 фев 14, 09:48    [15554966]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
WebSharper
Member

Откуда:
Сообщений: 521
Vladimir A.K.
Уважаемые консультанты.
Есть идея по хранению описанных выше данных в БД. Возможно бредовая.


Если СУБД не будет знать о полях, как она сможет построить по ним индексы? По крайней мере, те поля, по которым надо искать нужно вводить явно, я считаю.
12 фев 14, 10:25    [15555116]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
WebSharper
Vladimir A.K.
Уважаемые консультанты.
Есть идея по хранению описанных выше данных в БД. Возможно бредовая.


Если СУБД не будет знать о полях, как она сможет построить по ним индексы? По крайней мере, те поля, по которым надо искать нужно вводить явно, я считаю.

Логично. Слона-то я и не заметил :(
Спасибо!
12 фев 14, 12:07    [15555940]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Бредятина
Member [заблокирован]

Откуда: Москва
Сообщений: 2497
Vladimir A.K.
Логично. Слона-то я и не заметил :(
Спасибо!

О слонах Вы, пока, мало что знаете))
http://www.spaceops2012.org/proceedings/documents/id1275512-Paper-003.pdf
Возьмите MUMPS и сделайте все, что требуется. Никаких других технологий БД, пока, не изобрели))
16 фев 14, 22:29    [15574796]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1943
Vladimir A.K.
Запись (та самая, с кучей аналоговых и дискретных параметров) хранится в таблице в виде поля формата bytea: байтовый массив.


Я не тормоз, я только прочитал. Мысли вслух...

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

Можно взять какую-нибудь NoSQL, например MongoDB. В неё поток льёт абстрактные данные (JSON). Атомарность операций есть, а большего и не надо. БД бесплатная, можно создавать кластер. API кривоват, но что делать.

Второй уровень- показания читаются, парсятся и раскладываются в SQL (Oracle) по отдельным таблицам, можно делать выборки и т.п.
Можно грузить кучами.

Недавно за сутки с небольшим в Монгу 200млн записей запихали (кроме других операций в ней). Не тормозило ничего.
4 мар 14, 20:56    [15672648]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51796

Alexey Tomin
Недавно за сутки с небольшим в Монгу 200млн записей запихали (кроме
других операций в ней). Не тормозило ничего.

Вставка 2 тысяч записей в секунду нынче в натуре считается HiLoad или вы это делали на
обычном писюке?..

Posted via ActualForum NNTP Server 1.5

4 мар 14, 21:06    [15672690]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Alexey Tomin
Member

Откуда: Самара
Сообщений: 1943
Dimitry Sibiryakov
Alexey Tomin
Недавно за сутки с небольшим в Монгу 200млн записей запихали (кроме
других операций в ней). Не тормозило ничего.

Вставка 2 тысяч записей в секунду нынче в натуре считается HiLoad или вы это делали на
обычном писюке?..


Это фоновая задача, при этом много больше того, что у автора.
И да, обычная персоналка.
5 мар 14, 09:17    [15674173]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3]      все
Все форумы / Проектирование БД Ответить