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

Откуда:
Сообщений: 34
Добрый день.
Пытаюсь найти решение для следующей задачи.

Есть объекты. Нескольких типов.
Количество типов: единицы, потом, возможно, десятки.
У них измеряются (практически постоянно) некие параметры. Аналоговые и дискретные.
У каждого типа перечень и количество измеряемых параметров разные. Подмножества конечно пересекаются, но это мало что меняет.
Суммарное количество измеряемых параметров для одного типа объекта: сотни.
Частота измерений 1-2 раза в секунду.
Соответственно, количество записей большое. Я бы даже сказал, очень большое.

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

Никак не могу придумать, каким образом грамотно организовать структуру такого вида.

Пока что пришло на ум:
1. Общая таблица записей "измерений". Будет содержать:
- тип объекта
- его номер
- дата-время записи
2. На каждый тип объекта создаются две таблицы, ссылающиеся на первую:
а). С данными постоянного хранения.
б). С данными временного хранения, в поля которой не будут включены поля из таблицы "а".

Насколько правилен и удобен такой подход?
Или есть уже готовые решения для таких задач, а я пытаюсь "изобрести велосипед"?

Заранее признателен за помощь.

P.S. На данный момент (разработка - отработка) будет использована Firebird.
В дальнейшем, скорее всего, другая СУБД.
30 янв 14, 10:37    [15492835]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Shtock
Member

Откуда: СПб
Сообщений: 3049
Мне одному кажется, что это уже 3-й топик про eav за эту неделю? у писателей универсальных систем посленовогоднее обострение? поищите по слову eav на форуме, а для трэша почитайте свежак этой недели.
30 янв 14, 14:04    [15494565]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Злой Бобр
Member

Откуда: Украина, Кривой Рог
Сообщений: 3525
Shtock,

Ты не одинок. Автор заморачивается структурой в то время как сначала нужно выбрать субд которая потянет подобный объем на запись. Ну и ладно ...
30 янв 14, 14:28    [15494738]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
Shtock
Мне одному кажется, что это уже 3-й топик про eav за эту неделю? у писателей универсальных систем посленовогоднее обострение? поищите по слову eav на форуме, а для трэша почитайте свежак этой недели.

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

Откуда:
Сообщений: 34
Злой Бобр,
Заморачиваюсь.
Но, во-первых, боюсь, если начну задавать его в этом разделе, буду неправильно понят :)
Во-вторых, выбор и приобретение потребуют некоторого времени. А кое-какие пробы и наработки хотелось бы начать делать сейчас.
P.S. Таки задам.
Что Вы посоветуете?
30 янв 14, 14:51    [15494923]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
_мод
Guest
Vladimir A.K.
Насколько правилен и удобен такой подход?
Или есть уже готовые решения для таких задач, а я пытаюсь "изобрести велосипед"?

Каждая задача в чем-то оригинальна. Ваше решение правильно. Никакого eav.
30 янв 14, 14:58    [15494969]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Злой Бобр
Member

Откуда: Украина, Кривой Рог
Сообщений: 3525
Vladimir A.K.
Что Вы посоветуете?

Смотрите в сторону DB2 или Oracle. Первый вариант шутрее в плане записи, второй медленнее но имеет больший функционал в плане администрирования и анализа.
30 янв 14, 15:04    [15495010]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
Злой Бобр, спасибо.
В принципе смотрю в сторону Oracle.
Первую в глаза не видел. Со второй несколько лет общался.
Но не как админ или проектировщик. Просто, в основном, пользовался: запросы, вьюверы и т.п. Иногда инициировал некоторые изменения в структуре.

Как проектировщик опыта нет. Кроме мелких десктопных решений.
Вот сейчас новый для себя термин услышал: EAV.
Я конечно уже гугль уже открыл. Но все же:
- та структура, которую описал, EAV или с точностью наоборот?
- прекрасно знаю, что лучший помощник: поиск по форуму. Но т.к. не владею терминами, просьба подсказать, по каким ключевым словам искать-то то, чего добиваюсь.
30 янв 14, 15:19    [15495134]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Злой Бобр
Member

Откуда: Украина, Кривой Рог
Сообщений: 3525
Vladimir A.K.,

Приведите пример, т.к. честно говоря я немного непонял структуру. Т.е. объекты, типы, ... замените на конкретные данные. Ну например: сейсмодатчики, каждый датчик считывает 30 показаний в секунду, ... Так можно будет более четко дать направление куда копать.
30 янв 14, 15:31    [15495261]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

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

Приведите пример, т.к. честно говоря я немного непонял структуру. Т.е. объекты, типы, ... замените на конкретные данные. Ну например: сейсмодатчики, каждый датчик считывает 30 показаний в секунду, ... Так можно будет более четко дать направление куда копать.

Попробую.

Частота измерений к делу отношения не имеет.
Измерение производит некоторая АСУ.

Измеренные данные АСУ записывает в файлы.
Частота записей: 1-2 раза в секунду.

Потом файлы или по каналам связи или на носителях передаются на сервер, где, собственно происходит импорт в БД.

Имеется несколько типов таких АСУ.
Каждый тип АСУ стоит на N-ном количестве объектов, которым АСУ управляет.

Структура данных одного типа АСУ (для примера):
- 101 аналоговый канал (часть данных может быть представлена как целочисленные, остальные - с плавающей точкой).
- 160 дискретных входов.
- 48 дискретных выходов.
- время записи.

У остальных типов АСУ - похоже. Но количество аналоговых каналов и дискретных входов-выходов отличается.
30 янв 14, 15:52    [15495464]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
rockclimber
Member

Откуда: у меня в голове опилки?
Сообщений: 11085
Vladimir A.K.
Во-вторых, выбор и приобретение потребуют некоторого времени. А кое-какие пробы и наработки хотелось бы начать делать сейчас.
Ну так начинайте, любая платная СУБД имеет ознакомительную версию, которая лежит прямо на сайте производителя. У оракла например есть образ системы для виртуальной машины, где уже готовая ОС с установленным ораклом и кучей средств разработки.
30 янв 14, 16:00    [15495524]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Злой Бобр
Member

Откуда: Украина, Кривой Рог
Сообщений: 3525
Vladimir A.K.,

Да EAV вам в помощь, судя по примеру (хотя до меня так и недошло толком).
30 янв 14, 16:05    [15495559]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Dimitry Sibiryakov
Member

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

Vladimir A.K.
Предполагается два "хранилища" (пока условно назову так):

Советую: выбирайте для этих хранилищ разные СУБД. И ни в коем случае не используйте
для второго Firebird.

Posted via ActualForum NNTP Server 1.5

30 янв 14, 16:17    [15495622]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
Dimitry Sibiryakov
Vladimir A.K.
Предполагается два "хранилища" (пока условно назову так):

Советую: выбирайте для этих хранилищ разные СУБД. И ни в коем случае не используйте
для второго Firebird.

Почему разные?
"Хранилища" - понятие условное.
Предполагалась пара таблиц на каждый тип АСУ.
30 янв 14, 16:21    [15495644]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Dimitry Sibiryakov
Member

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

Vladimir A.K.
Почему разные?

Потому что требования к СУБД у них диаметрально противоположные.

Posted via ActualForum NNTP Server 1.5

30 янв 14, 16:32    [15495724]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Злой Бобр
Member

Откуда: Украина, Кривой Рог
Сообщений: 3525
Dimitry Sibiryakov,

Оракл вполне справится по функционалу. И поскольку данные уже в виде файла для импорта даже MS SQL потянет. Вопрос только в железе. Сервер начального уровня даже и рядом нестоял. Так что по железу это отдельная тема. Но автор уже сейчас может спокойно лепить таблицы и писать скрипты.
30 янв 14, 17:26    [15496073]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Dimitry Sibiryakov
Member

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

Злой Бобр
Оракл вполне справится по функционалу.

Да, но для беспроблемного удаления первички нужно секционирование, а это уже ЕЕ редакция.

Posted via ActualForum NNTP Server 1.5

30 янв 14, 17:29    [15496103]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
SERG1257
Member

Откуда:
Сообщений: 2790
Ищите по форуму по слову датчики.
Краткий пересказ:
У вашей задачи есть минимум три слоя
1 Прием оперативных данных - СУБД очень не любит поток одиночных инсертов. СУБД вполне может лечь, куда тогда будут поступать данные. Вам потребуется буфер например в виде плоского файла из которого оптом данные заливаются в СУБД по таймеру.
2 Оперативная база, например за несколько дней
3 Аналитика - смотрите в сторону хранилища, DWH, OLAP и т.д.

Dimitry Sibiryakov
Да, но для беспроблемного удаления первички нужно секционирование, а это уже ЕЕ редакция.
Секционирование на базе вьюх вполне делается без ЕЕ.
30 янв 14, 18:02    [15496327]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Iliyam
Member

Откуда:
Сообщений: 112
SERG1257,

удалять тоже через view будете? а если таблица начнет разрастаться, несмотря на то, что вы регулярно удаляете устаревшие данные? хорошо, если сам себе и программист и админ, а то разное бывает...
30 янв 14, 18:43    [15496551]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Злой Бобр
Member

Откуда: Украина, Кривой Рог
Сообщений: 3525
Dimitry Sibiryakov
Злой Бобр
Оракл вполне справится по функционалу.

Да, но для беспроблемного удаления первички нужно секционирование, а это уже ЕЕ редакция.

Незная точных задач сложно что-то утверждать. Возможно что для отображения вполне хватит и вьюх. А насчет удаления - я б пока незаморачивался. На этапе импорта можно использовать временные таблицы. Ну а дальше нужно уже знать ТЗ автора. Гадать бесполезно.
30 янв 14, 18:51    [15496585]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
SERG1257
Member

Откуда:
Сообщений: 2790
Iliyam
удалять тоже через view будете?
Конечно

create table new_table as select .....

alter view allTables
select * from one_table
union all
select * from new_table

суть в том что вся предварительная работа идет в фоне, а для клиента это мгновенно через alter view
30 янв 14, 19:01    [15496634]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Iliyam
Member

Откуда:
Сообщений: 112
SERG1257,

так речь была о двух БД, в одной из которых данные будут удаляться.
или вы собираетесь делать, допустим, каждый день create new_table... drop old_table... alter view... ? ну-ну
30 янв 14, 19:09    [15496676]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
Огромное спасибо всем. Принявшим участие в обсуждении.
Я с Вашего позволения, попробую описать ситуацию подробнее.

Для начала маленькое лирическое отступление о текущем состоянии дел.

Я здесь недавно.
В настоящий момент здесь уже есть кое-какие "наработки" по обсуждаемой теме. И идея создания общей БД не нова.
Есть эксплуатируемые (по всей стране) объекты с АСУ на них. АСУ пишут информацию в файлы.
Более того. Есть некая "БД". Точнее, есть некоторая структура БД. Реализована в Firebird (отдельная песня).
Структура БД - :'(

Для информации под аналитику одна таблица, в которой:
250 полей типа float - аналоговые входы.
250 полей типа smallint - дискретные входы\выходы.
И еще несколько служебных полей: время измерения, время записи в БД, идентификаторы типа АСУ (символьный), идентификатор объекта, на котором стоит АСУ (символьный) и т.п.

Для информации, хранящейся постоянно, другая таблица:
50 полей типа float, плюс служебная информация.

Индексы в этих таблицах ... из нескольких полей. Причем часть из них: символьные и дата-время. :(
Первичные ключи: пять полей, в т.ч. символьные, дата-время ...
Внешние ключи отсутствуют как класс.

У каждого типа АСУ есть своя конфигурация, в которой описаны все входы-выходы. Причем конфигурация хранится в другом файле БД.

У одного АСУ м.б. 200 аналоговых каналов и 200 дискретных, у другого 100 и 100 соответственно, т.д.
У одного АСУ во вторую таблицу пишется 10 параметров, у второго 20.

В связи с этим таблицах с данными измерений (и в первой и второй) огромная избыточность. Большинство полей после вставки - NULL.

Все это работает ужасно медленно, информация вставляется ужасно долго. Информация за месяц на десктопе вставляется пару суток :(

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

И по факту имеется куча отдельных файлов БД, в которые заносится информация за месяц и делается кое-какая, на данный момент элементарная, обработка. Следующий месяц - следующий файл. И т.д.

ТЗ нет. Есть "намерения".
Вот я и пытаюсь преобразовать эти намерения в конкретные решения.
31 янв 14, 10:03    [15498493]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
Теперь по серверу и СУБД.
Вопрос о том, что может нужно ориентироваться на что-то серьезное встал сразу.
На него я ответил: "Ребята, Вы сами не можете мне полностью объяснить, какую задачу нужно решить. Давайте сперва более-мене разберемся в задаче и под нее подберем СУБД"
Можно сейчас что-то купить. И даже если не ошибся с выбором, то деньги лягут мертвым грузом.
Потому как надо будет определиться со структурой, сделать кое-какие наработки, подготовиться профессионально (возможно обучение пройти) etc.

Из более-мощных СУБД я имел дело с Oracle (уже говорил об этом) и, перед этим, лет шесть работал в телекоммуникационной компании с MS SQL Server 6.5, 7.0, 2000.
Других и в глаза не видел.
Ориентируюсь на Oracle. Ваши рекомендации вроде как одобряют выбор.
Но все равно, покопаю пока в этом направлении.

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


Ну и отступление про firebird. Здесь почти все пишут на Delphi. Причем 2002-м. С БД работа большинства не связана, но полагаю, что выбор firebird-а обусловлен борландовскими корнями интербейза.

Тут еще небольшая задачка есть. Базенка по ремонтам для локальной сети. Маленькая. Транзакции редкие.
Ее пока буду делать на MySQL, с web-клиентами. Но это так, для справки.
31 янв 14, 10:23    [15498609]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
SERG1257
Ищите по форуму по слову датчики.

Спасибо. Поищу.
SERG1257
Краткий пересказ:
У вашей задачи есть минимум три слоя
1 Прием оперативных данных - СУБД очень не любит поток одиночных инсертов. СУБД вполне может лечь, куда тогда будут поступать данные. Вам потребуется буфер например в виде плоского файла из которого оптом данные заливаются в СУБД по таймеру.

Что имеется ввиду?
Бодаясь с имеющейся firebird-овской базой, разбираясь с импортом, пробовал хоть как-то убыстрить процесс вставки данных.
Множественной вставки ФБ не знает. Из-за огромного количества полей и ограничения длины пакета в 64к, много строк через EXECUTE BLOCK не вставишь.
В одном из вариантов попробовал сперва делать вставку в таблицы внешних файлов а из них одним select-ом уже в таблицу БД.
Вы не что-то подобное подразумевали?
SERG1257
2 Оперативная база, например за несколько дней
3 Аналитика - смотрите в сторону хранилища, DWH, OLAP и т.д.

Вы таки считаете, что это должны быть две раздельные БД?
Ведь еще нужны таблицы с конфигурациями АСУ, и ряд других таблиц (список всех АСУ, список всех объектов, на которых эти АСУ стоят, иерархия подразделений etc.).
Получается, все это надо держать в двух базах и реплицировать изменения.
SERG1257
ЕЕ

Как расшифролвывается ЕЕ?
31 янв 14, 10:36    [15498714]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
rockclimber
Member

Откуда: у меня в голове опилки?
Сообщений: 11085
Vladimir A.K.
SERG1257
ЕЕ

Как расшифролвывается ЕЕ?
Энтерпрайз эдишен - топовая комплектация оракла.
Покупать пока действительно ничего не надо, большую часть можно делать на бесплатном XE (будут ограничения: 1 процессор, сколько-то гигов памяти и размер БД 11 гигов).
Разработку (до ввода в эксплуатацию) можно вести (вроде бы) на любой версии, а лицензию можно купить потом, при вводе в промышленную эксплуатацию. Но тут я в деталях не знаю, уточните лучше на оракловом форуме.
31 янв 14, 11:08    [15498948]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
rockclimber
Member

Откуда: у меня в голове опилки?
Сообщений: 11085
Vladimir A.K.
Вы таки считаете, что это должны быть две раздельные БД?
Это, как сейчас модно говорить, "best practice".
Причем, скорее всего, это даже будут два раздельных физических сервера.
31 янв 14, 11:14    [15498987]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
rockclimber
Энтерпрайз эдишен - топовая комплектация оракла.
Покупать пока действительно ничего не надо, большую часть можно делать на бесплатном XE (будут ограничения: 1 процессор, сколько-то гигов памяти и размер БД 11 гигов).

Спасибо.
Железка только какая под этот бесплатный ХЕ потребуется?
rockclimber
Причем, скорее всего, это даже будут два раздельных физических сервера.

Не пугайте меня сразу так сильно :)
31 янв 14, 11:58    [15499404]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
rockclimber
Member

Откуда: у меня в голове опилки?
Сообщений: 11085
Vladimir A.K.
rockclimber
Энтерпрайз эдишен - топовая комплектация оракла.
Покупать пока действительно ничего не надо, большую часть можно делать на бесплатном XE (будут ограничения: 1 процессор, сколько-то гигов памяти и размер БД 11 гигов).

Спасибо.
Железка только какая под этот бесплатный ХЕ потребуется?
Любая, оракл просто не будет использовать лишнее сверх этих ограничений.

Vladimir A.K.
Не пугайте меня сразу так сильно :)
Так от нагрузки же зависит. Моя первая "промышленная" БД, написанная мной на одном из первых мест работы, после года эксплуатации имела размер 64 мегабайта, что в 2010-м году, сами понимаете, было копейками. Сервер был на обычной офисной машине с 512 МБ оперативки, и мне ни разу не удалось написать осмысленный запрос, который бы работал дольше секунды. А на теперешнем месте у меня база несколько терабайт. Логично предположить, что в первом случае можно делать промышленную среду, тестовую, хранилише и кучу чего еще на одной железке, а на второй - не стоит. Ваш случай к какому ближе?
31 янв 14, 12:28    [15499679]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
йцуке
Member

Откуда:
Сообщений: 102
Vladimir A.K.
Для информации под аналитику одна таблица, в которой:
250 полей типа float - аналоговые входы.
250 полей типа smallint - дискретные входы\выходы.
И еще несколько служебных полей: время измерения, время записи в БД, идентификаторы типа АСУ (символьный), идентификатор объекта, на котором стоит АСУ (символьный) и т.п.

Для информации, хранящейся постоянно, другая таблица:
50 полей типа float, плюс служебная информация.

У каждого типа АСУ есть своя конфигурация, в которой описаны все входы-выходы. Причем конфигурация хранится в другом файле БД.

У одного АСУ м.б. 200 аналоговых каналов и 200 дискретных, у другого 100 и 100 соответственно, т.д.
У одного АСУ во вторую таблицу пишется 10 параметров, у второго 20.

В связи с этим таблицах с данными измерений (и в первой и второй) огромная избыточность. Большинство полей после вставки - NULL
И по факту имеется куча отдельных файлов БД, в которые заносится информация за месяц и делается кое-какая, на данный момент элементарная, обработка. Следующий месяц - следующий файл. И т.д.

1) В архиве нет смысла хранить все, что приходит из "поля". Разумно сохранять все значения 1 раз в час, к примеру, а в остальное время в базу писать только те значения, что изменились.
2) Для аналоговых каналов нет необходимости хранить все значения. Они обычно "дребезжат", и можно ввести зону нечувствительности, изменениями в рамках которой можно пренебречь. К примеру, для значений тока 32,521 А и 32,522 А вполне возможно отбросить последний разряд.
3)
Vladimir A.K.
250 полей типа smallint - дискретные входы\выходы.
В этих полях значения находятся в каждом бите числа, или это всего 250 бит (250 входов/выходов)? Если второе, то их можно упаковать.

Поищите описания работы СУБД, используемых для хранения тегов в АСУ ТП. К примеру, Wonderware Historian.
Кстати, требования в железу и СУБД, при использовании подходов, принятых в специализированных СУБД, средние. Тот же Wonderware еще 10 лет назад, если не ошибаюсь, гарантировал запись 100 000 тегов в сек. на своей базе, построенной на основе MS SQL 2000.
31 янв 14, 13:06    [15500012]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

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

Не получится. Тепловоз :) Подавляющее большинство измеряемых параметров постоянно изменяются.
Но дело не в этом. И то, что дискретные входы-выходы надо паковать в битовые поля и многое-многое другое я знаю.
Я описал, что есть сейчас: эдакий образчик "проектантского нигилизма" :)
А мне надо найти оптимальную структуру.
йцуке
Поищите описания работы СУБД, используемых для хранения тегов в АСУ ТП.

Хорошо. О чем речь представляю. Где-то дома даже сертификатик одной из СКАДА валяется. Она именно такими темпами пишет.
Но в структуру не вдавался.
31 янв 14, 13:33    [15500201]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
йцуке
Member

Откуда:
Сообщений: 102
Vladimir A.K.
йцуке
1) В архиве нет смысла хранить все, что приходит из "поля". Разумно сохранять все значения 1 раз в час, к примеру, а в остальное время в базу писать только те значения, что изменились.

Не получится. Тепловоз :) Подавляющее большинство измеряемых параметров постоянно изменяются.

В АСУ тоже подавляющее большинство параметров постоянно меняются. Подход с загрублением аналоговых параметров и сохранением только изменений позволяет хорошо сэкономить на объеме записываемых данных.
31 янв 14, 13:43    [15500292]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
йцуке
Member

Откуда:
Сообщений: 102
[quot Vladimir A.K.]
йцуке
Я описал, что есть сейчас: эдакий образчик "проектантского нигилизма" :)
А мне надо найти оптимальную структуру.

Спроектируйте нормализованную базу, проведите тесты, по результатам, при необходимости, денормализуйте.
31 янв 14, 13:48    [15500322]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
[quot йцуке]
Vladimir A.K.
В АСУ тоже подавляющее большинство параметров постоянно меняются. Подход с загрублением аналоговых параметров и сохранением только изменений позволяет хорошо сэкономить на объеме записываемых данных.

Уточню: значительно меняются :) В разы, порой на порядки.
йцуке
Спроектируйте нормализованную базу ...

Полез в гугль )))
31 янв 14, 14:19    [15500562]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
rockclimber
Member

Откуда: у меня в голове опилки?
Сообщений: 11085
Vladimir A.K.
йцуке
Спроектируйте нормализованную базу ...

Полез в гугль )))
Ох ты ж ё
Нормальная форма
На intuit.ru посмотрите лекции по основам реляционных БД
31 янв 14, 14:26    [15500612]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
rockclimber
Полез в гугль )))
Ох ты ж ё [/quot]
Не-не.
Не все так плохо :)
Оказалось, что все знакомо.
А вот с терминами, видать, слабоват на память :(
31 янв 14, 14:33    [15500671]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Злой Бобр
Member

Откуда: Украина, Кривой Рог
Сообщений: 3525
Vladimir A.K.,

Все замечательно. Только непонятна цель все этой суеты. Ну допустим будете вы писать в БД данные из файлов. Это вроде как не проблема. Что дальше? Кто и какими данными будет пользоваться? Для чего весь этот движ создается?
На этапе разработки берите обычный десктоп с памятью 8+ Гиг. Для разработки вам за глаза хватит. Да, будет потеря в скорости. Но это не так критично. По крайней мере сможете понять какие объемы, узкие места и пр. Потом уже исходя из наработок купите железку под сервак.
31 янв 14, 14:43    [15500764]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Vladimir A.K.
Member

Откуда:
Сообщений: 34
Злой Бобр
Все замечательно. Только непонятна цель все этой суеты. Ну допустим будете вы писать в БД данные из файлов. Это вроде как не проблема. Что дальше? Кто и какими данными будет пользоваться? Для чего весь этот движ создается?

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

Да, спасибо. Cегодня ХЕ качать не стал. Но, что пойду по этому пути, уже определился.
31 янв 14, 14:52    [15500838]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
Злой Бобр
Member

Откуда: Украина, Кривой Рог
Сообщений: 3525
Vladimir A.K.,

Ну тогда я думаю будет достаточно отдельных таблиц в одной БД. Тут главное правильно спроектировать и проставить индексы. И железку брать с минимум 30% запасом, что б года 3 незаглядывать в железо.
31 янв 14, 15:01    [15500903]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
йцуке
Member

Откуда:
Сообщений: 102
Vladimir A.K.
Да, спасибо. Cегодня ХЕ качать не стал. Но, что пойду по этому пути, уже определился.

Неплохо бы было начать с проектирования. Посчитать общий объем базы, количество инсертов в секунду, прикинуть типовые запросы, определиться с индексами. По результатам выбрать сервер.
Скорей всего, запросы будут простенькими, а проблема будет только в размере таблиц, скорости вставки и скорости выборки. И, в результате, подойдет любой сервер, хоть MySQL.
Если для вас не проблема покупка оракла, то почему бы не посмотреть на промышленные решения, используемые в АСУ. Они оптимизированы именно под работу с большими массивами аналоговых/дискретных параметров.
И форум для вопросов вы неудачно выбрали. Спрашивать надо на форумах асушников. Для них это типовая задача.
31 янв 14, 17:25    [15501973]     Ответить | Цитировать Сообщить модератору
 Re: БД для объектов с разным количеством параметров  [new]
йцуке
Member

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

О, нашел древнюю, 1999 г., статью об асушном решении

Цитаты:
"Что делает IndustrialSQL Server?
  • Сохраняет некритичную во времени информацию в БД Microsoft SQL Server. Вся технологическая информация сохраняется в специальных таблицах расширения.
  • Поддерживает пропускную способность, т.е. обеспечивает сохранение огромных потоков информации с высокой разрешающей способностью.
  • Поддерживает целостность данных, то есть обеспечивает запись больших объемов информации без потерь.
  • Добавляет в Microsoft SQL Server свойства сервера реального времени.

    ...Уменьшение объема хранения IndustrialSQL Server позволяет хранить данные на пространстве, составляющем небольшую долю от соответствующего объема обычной РБД. Фактический размер требуемого для хранения производственной информации дискового пространства определяется размером и сущностью операций предприятия, а также интервалом хранения предыстории его функционирования. Например, двухмесячный архив предприятия с 4000 параметров, опрашиваемых с периодичностью от нескольких секунд до нескольких минут, будет занимать около 2 Мбайт дискового пространства. Используемый алгоритм упаковки информации является алгоритмом сжатия без потерь, сохраняющим высокое разрешение и качество данных."
  • 31 янв 14, 17:54    [15502225]     Ответить | Цитировать Сообщить модератору
     Re: БД для объектов с разным количеством параметров  [new]
    SERG1257
    Member

    Откуда:
    Сообщений: 2790
    Танцуйте от печки. т.е от пользователей. Что они (пользователи) хотят, как хотят, и чем готовы заплатить. Посмотрите на демки имеющихся продуктов. Вот после того как в голове сложится образ идеального приложения (aka ТЗ) надо переходить к анализу запросов этого идеального приложения и проектированию структур подходящих этим запросам.
    Пока я вижу только "плач Ярославны"
    Vladimir A.K.
    В связи с этим таблицах с данными измерений (и в первой и второй) огромная избыточность. Большинство полей после вставки - NULL.
    Это детали реализации. В приличных СУБД NULL занимает минимальное количество места (а то и нисколько), стало быть нет никакой избыточности.

    Vladimir A.K.
    Вы таки считаете, что это должны быть две раздельные БД?
    У этих двух БД два принципиально разных режима работы. Первая держит "руку на пульсе" постоянно получая свежую инфу, но имеет фиксированные запросы и ограничена в глубину на несколько дней (недель, месяцев...), вторая обновляется (пополняется) максимум раз в день (в ночь), содержит ВСЕ данные, и запросы к ней "ведает только аллах". Вполне возможно, что вторая база будет реализована в виде архивированных плоских файлов, лежащих в дальнем пыльном забытом подвале и ждущих своего часа, пополняемых перед удалением данных из первой.
    31 янв 14, 18:12    [15502349]     Ответить | Цитировать Сообщить модератору
     Re: БД для объектов с разным количеством параметров  [new]
    Vladimir A.K.
    Member

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

    Согласен.
    В этом направлении конечно же двигаюсь.
    По инсертам.
    Пока: время от времени залив огромного количества записей, привезенных на внешних хардах.
    йцуке
    Скорей всего, запросы будут простенькими, а проблема будет только в размере таблиц, скорости вставки и скорости выборки. И, в результате, подойдет любой сервер, хоть MySQL.

    Да, пока я не вижу сложных вопросов.
    Вопросы (точнее проблемы) пока скорее в моих знаниях возможностей СУБД и проектировании таких БД.
    йцуке
    И форум для вопросов вы неудачно выбрали. Спрашивать надо на форумах асушников. Для них это типовая задача.

    Может быть.

    Спасибо!
    1 фев 14, 14:29    [15504384]     Ответить | Цитировать Сообщить модератору
     Re: БД для объектов с разным количеством параметров  [new]
    Vladimir A.K.
    Member

    Откуда:
    Сообщений: 34
    SERG1257
    Танцуйте от печки. т.е от пользователей. Что они (пользователи) хотят, как хотят, и чем готовы заплатить.

    Безусловно "танцую".
    Но пока трудновато. Бум работать :)
    SERG1257
    Пока я вижу только "плач Ярославны"
    Это детали реализации. В приличных СУБД NULL занимает минимальное количество места (а то и нисколько), стало быть нет никакой избыточности.

    Это радует.
    SERG1257
    У этих двух БД два принципиально разных режима работы. Первая держит "руку на пульсе" постоянно получая свежую инфу, но имеет фиксированные запросы и ограничена в глубину на несколько дней (недель, месяцев...), вторая обновляется (пополняется) максимум раз в день (в ночь), содержит ВСЕ данные, и запросы к ней "ведает только аллах".

    Не совсем так. Скорее всего я плохо объяснял.
    Но "утро вечера мудренее" и идея с двумя базами мне теперь понятна.
    1 фев 14, 16:43    [15504664]     Ответить | Цитировать Сообщить модератору
     Re: БД для объектов с разным количеством параметров  [new]
    Vladimir A.K.
    Member

    Откуда:
    Сообщений: 34
    С вашего позволения я продолжу.

    1. Разделение "подзадач" на две БД (возможно с разными СУБД, физически разнесенных и т.п.) обдумано, обсуждено и утверждено.
    Сокращенная информация с длительным сроком хранения будет вынесена в отдельную БД.
    Спасибо за правильный вектор.

    2. Теперь по структуре БД, в которую будут импортироваться все измеренные данные за некоторый временной промежуток для обработки по неким аналитическим алгоритмам.

    Имеем: несколько конфигураций.
    Каждая i-я конфигурация содержит Ni аналоговых параметров и Mi дискретных параметров.
    Все-таки, что видится оптимальным:
    - общая таблица с количеством полей, равным максимальному количеству полей из всех конфигураций. С учетом подсказки SERG1257 о том, что хранение избыточных NULL не занимает большого места.
    - раздельные таблицы для каждой конфигурации.

    Интересует оценка как с точки зрения быстродействия и ресурсоемкости, так и удобства написания запросов, процедур etc.
    3 фев 14, 10:37    [15508684]     Ответить | Цитировать Сообщить модератору
     Re: БД для объектов с разным количеством параметров  [new]
    Злой Бобр
    Member

    Откуда: Украина, Кривой Рог
    Сообщений: 3525
    Vladimir A.K.,

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

    Откуда:
    Сообщений: 34
    Злой Бобр
    Vladimir A.K.,
    Если с точки зрения максимально быстрого ввода то одна таблица. Если же учесть что структура может поменяться то этот вариант приведет к тому что нужно будет менять подход. Поэтому если структура будет постоянна то одна таблица, иначе несколько.

    Структура, если я правильно понял то, о чем Вы говорите, может меняться.
    Могут добавляться новые измеряемые параметры.
    Сейчас читаю темы с проблематикой, близкой к моей. Поиск по слову "датчики", как здесь посоветовали :)
    Пока направление к нескольким БД выглядит наиболее логичным.
    Встречаются похожие задачи, и при их обсуждении вектор как раз к такому решению приходит.

    Еще один плюс такого решения, который не отметил раньше.
    Аналоговые параметры могут быть как с плавающей точкой, так и целочисленные.
    Для некоторых параметров вообще байта достаточно.
    И мне как ножом по сердцу (или серпом по чему-то еще) было бы все хранить как float :)
    3 фев 14, 14:41    [15510562]     Ответить | Цитировать Сообщить модератору
     Re: БД для объектов с разным количеством параметров  [new]
    Vladimir A.K.
    Member

    Откуда:
    Сообщений: 34
    Детский вопросик.

    К теме проектирования БД отношение, впрочем, имеет :)

    Что посоветуете для прорисовки графической структуры БД?
    3 фев 14, 14:47    [15510618]     Ответить | Цитировать Сообщить модератору
     Re: БД для объектов с разным количеством параметров  [new]
    SERG1257
    Member

    Откуда:
    Сообщений: 2790
    Vladimir A.K.
    Интересует оценка как с точки зрения быстродействия и ресурсоемкости, так и удобства написания запросов, процедур etc.
    Опять же танцуйте от печки. Определитесь с запросами и подгоняйте структуру под удобство/скорость запросов. Если у вас популярный запрос - выведите мне состояние объекта ХХХ на время ЧЧ.ММ.СС, то собирание состояния объекта по параметрам может занимать слишком много времени. Дешевле собрать ее один раз во время загрузки. Здесь 15489997 я приводил список моих претензий к EAV структуре.
    Злой Бобр
    Если же учесть что структура может поменяться то этот вариант приведет к тому что нужно будет менять подход
    А вот и неправда. Добавить поле ничуть не сложнее (главное не наткнутся на ограничение на количество полей). Другое дело если пользователю не надо (редко требуется) разворачивать состояние объекта "в строчку" (например каждый параметр имеет свою временную метку) тогда удобнее хранить так как запрашивается. Возможен также и гибридный подход - главная таблица об объекте с параметрами "в строчку", плюс несколько дополнительных с параметрами "в столбик".

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

    Далее - дата-время съема параметра для вашей структуры будет ключевым полем (первым полем первичного ключа). По этому полю надо будет обязательно кластеризовать (в Оракле это IOT) чтобы упростить очистку устаревших данных.
    3 фев 14, 18:05    [15512126]     Ответить | Цитировать Сообщить модератору
     Re: БД для объектов с разным количеством параметров  [new]
    йцуке
    Member

    Откуда:
    Сообщений: 102
    Vladimir A.K.
    1. Разделение "подзадач" на две БД (возможно с разными СУБД, физически разнесенных и т.п.) обдумано, обсуждено и утверждено.
    Сокращенная информация с длительным сроком хранения будет вынесена в отдельную БД.

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

    Vladimir A.K.
    Имеем: несколько конфигураций.
    Каждая i-я конфигурация содержит Ni аналоговых параметров и Mi дискретных параметров.
    Все-таки, что видится оптимальным:
    - общая таблица с количеством полей, равным максимальному количеству полей из всех конфигураций. С учетом подсказки SERG1257 о том, что хранение избыточных NULL не занимает большого места.

    Попробуйте загрузить, и оцените рост базы. Было бы интересно посмотреть. Загрузка ежесекундных данных один-в-один, и без оптимизаций.
    Vladimir A.K.
    - раздельные таблицы для каждой конфигурации.

    Если потребуется сравнивать параметры разных конфигураций, может быть неудобно.
    3 фев 14, 19:44    [15512607]     Ответить | Цитировать Сообщить модератору
     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]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: 1 2 3      [все]
    Все форумы / Проектирование БД Ответить