IT в России и мире в реалиях мирового кризиса

Цитата: Lapsha от 01.02.2017 06:38:43Не думаю, что это обычная БД.

Надо будет про нее почитать где-нить.

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

Цитата: slavae от 01.02.2017 07:40:56Я могу понять для чего реальное время нужно по работе с датчиками - чтобы иметь нормальный контроль, управление и обратную связь.
А вот что удивительного в том, чтобы хранить историю датчиков в обычной БД, я не пойму )

Если данные с датчиков поступают с высокой частотой, то БД должна бы с таким же быстродействием записывать эти данные, что для обычных БД не характерно. Поэтому иногда краткую историю накапливают в ОЗУ, а на диски пишут лишь трэнды ( то есть с пропусками сколько успеют, указывая трубку колебаний по минимаксу )

Цитата: slavae от 01.02.2017 07:40:56Я могу понять для чего реальное время нужно по работе с датчиками - чтобы иметь нормальный контроль, управление и обратную связь.
А вот что удивительного в том, чтобы хранить историю датчиков в обычной БД, я не пойму )

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

Цитата: adolfus от 01.02.2017 09:08:14История датчиков, т.е. телеметрия, хранится для того, чтобы при необходимости ее "проиграть". Датчики бывают разные, одни могут хранить выборку, "защелкивая" ее в заданный момент времени, другие не могут -- они "отдают" значение в момент считывания. В результате значения датчика хранятся в виде пар "время:значение". Время играет роль ключа для последовательного доступа (через курсор). Поэтому хранить телеметрию приходится в базе данных. Вопрос лишь в том, зачем для этого именно реляционная БД. Для хранение телеметриии отлично подходит БД типа "ключ:значение" с поддержкой вторичных БД (ключей). Скорее всего, в то время, когда система разрабатывалась, оракл был просто моден. Это как туфли на шпильках -- неудобно, калично, но красиво.

Теория у вас хорошая, только на практике такие вещи я бы хранил в блобах большими кусками. А снаружи выставил бы статистику по этому диапазону.

Цитата: slavae от 01.02.2017 07:40:56Я могу понять для чего реальное время нужно по работе с датчиками - чтобы иметь нормальный контроль, управление и обратную связь.
А вот что удивительного в том, чтобы хранить историю датчиков в обычной БД, я не пойму )

Очень даже получается крайне удобно.
Если уж говорить то БД уссловно делятся на две группы - версионники и протоколисты. Оракл и др. как правило протоколисты - надежно и медленно. Версионники - быстро, но могут пропадать данные при сбросе зависания.
Поэтому версионники, как правило и ставят для сбора данных. К версионникам относят IBase/Firebird и Postgree/ У них есть классная штука - подписка на события (вставка, изменение, удаление) - можно обновлять просмотр данных по команде от сервака. Поэтому их используют для лабораторий и в танках (в тех же абрамсах).
Кстати, в IBase впервые появилась такая штука, как хранение массивов в ячейке. Попросила одна испытательная лаборатория, так и осталась эта приблуда. Правда работа с этим массивом не совсем тривиальная. А так да, BLOB можно, но так как количество датчиков постоянно, то городить блобы не удобно, проще в свою колонку, тем более 32 тысячи колонок - более чем достаточно для одного устройства (надо найти еще такое количество датчиков), а таблиц может быть много - для каждого узла/станка свой. Зато не надо парсить, сразу можно из БД рисовать графики и даже управление наладить Просто и удобно с протоколированием.
Так за бугром решили одну из задач по обработке больших данных (БигДата). Я сам так использую - очень удобно, быстро и надежно.

Цитата: adolfus от 01.02.2017 09:08:14История датчиков, т.е. телеметрия, хранится для того, чтобы при необходимости ее "проиграть". Датчики бывают разные, одни могут хранить выборку, "защелкивая" ее в заданный момент времени, другие не могут -- они "отдают" значение в момент считывания. В результате значения датчика хранятся в виде пар "время:значение". Время играет роль ключа для последовательного доступа (через курсор). Поэтому хранить телеметрию приходится в базе данных. Вопрос лишь в том, зачем для этого именно реляционная БД. Для хранение телеметриии отлично подходит БД типа "ключ:значение" с поддержкой вторичных БД (ключей). Скорее всего, в то время, когда система разрабатывалась, оракл был просто моден. Это как туфли на шпильках -- неудобно, калично, но красиво.

Разные компании используют разные БД в зависимости от ТЗ. Для АЭС и ракет - критично надежность сохранения данных - нужны протокольники, для танков - главное скорость - используют версионники. Хотя если бы можно сделать отказоустойчивый кластер на версионниках - то они предпочтительнее.

Цитата: Lapsha от 01.02.2017 06:38:43Не думаю, что это обычная БД.

Надо будет про нее почитать где-нить.

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

Цитата: Спецагент Купер от 31.01.2017 10:24:46В большинстве случаев задачи реального времени не решаются выбором операционной системы. ОС высокого уровня, такие как *NUX, обычно ставятся в конце цепочки обработки, там где пользовательский интерфейс, управление и другие подобные задачи.

Где возникает реалтайм, там самое место или микроконтроллеру, если нужна низкая латентность, или FPGA/DSP, или на крайний случай ARM процессор.

Такой жесткий реалтайм, про который Вы говорите нужен крайне редко - например в гиперзвуковых ракетах. где процессы протекают крайне быстро, а большинстве случает достаточно того же двухядерного *NIX, а иногда и одноядерного *NIX. Для станков, автомобилей
, промышленных установок достаточно и двухядерных OC. У нас на заводе станки с ЧПУ великолепно работают на ДОСе, WinCE, спец.версии Линукса, и двухсистемных (только что стоит в стойках управления - я не знаю, нужно почитать у Сименса, что он туда пихает).

Цитата: Superwad от 01.02.2017 15:18:26Очень даже получается крайне удобно.
Если уж говорить то БД уссловно делятся на две группы - версионники и протоколисты. Оракл и др. как правило протоколисты - надежно и медленно. Версионники - быстро, но могут пропадать данные при сбросе зависания.
Поэтому версионники, как правило и ставят для сбора данных. К версионникам относят IBase/Firebird и Postgree/ У них есть классная штука - подписка на события (вставка, изменение, удаление) - можно обновлять просмотр данных по команде от сервака. Поэтому их используют для лабораторий и в танках (в тех же абрамсах).
Кстати, в IBase впервые появилась такая штука, как хранение массивов в ячейке. Попросила одна испытательная лаборатория, так и осталась эта приблуда. Правда работа с этим массивом не совсем тривиальная. А так да, BLOB можно, но так как количество датчиков постоянно, то городить блобы не удобно, проще в свою колонку, тем более 32 тысячи колонок - более чем достаточно для одного устройства (надо найти еще такое количество датчиков), а таблиц может быть много - для каждого узла/станка свой. Зато не надо парсить, сразу можно из БД рисовать графики и даже управление наладить Просто и удобно с протоколированием.
Так за бугром решили одну из задач по обработке больших данных (БигДата). Я сам так использую - очень удобно, быстро и надежно.

Спасибо, конечно, за просвещение и повтор легенд про Интербейз )) И, насколько я помню, Джим Старки писал на форуме FB, когда они только взялись за опенсорс, что массивы он придумал для аэропорта.

В FB есть возможность группировать по номеру колонки, так же, как сортировать. Это было сделано по моему предложению, когда мы ещё сидели на ньюс-группах ) Это потому что я ленивый, а выписывать поля мне было лениво.

Не вздумайте кого-нибудь уверять, что Оракл - блокировочник, а не версионник )
В моей рабочей системе в таблице товаров TOV в районе 20 млн записей, и я могу сказать, что много данных дают возможность проявить свою изобретательность.

Вы с вашими 32 тыс колонок скорее упрётесь в реальную пропускную способность сети.
Сейчас для закачки больших данных в БД вместо параметрического insert-а я использую их закачку большим подготовленным блоком на большое количество записей как blob или clob, а уже на месте - разбор в процедуре и вставку. Но в случае с датчиками скорее всего никому не нужна подробнейшая детализация мгновенно, поэтому я сразу и предложил хранить данные сразу этими самыми большими кусками со статистикой, а если уж понадобится узнать конкретное значение конкретного датчика, блок можно и разобрать.

Цитата: slavae от 01.02.2017 10:00:29Теория у вас хорошая, только на практике такие вещи я бы хранил в блобах большими кусками. А снаружи выставил бы статистику по этому диапазону.

1) и какую же структуру блобов Вы бы выбрали?
2) статистику чего?

Цитата: Superwad от 01.02.2017 15:18:26К версионникам относят IBase/Firebird и Postgree/ У них есть классная штука - подписка на события (вставка, изменение, удаление) - можно обновлять просмотр данных по команде от сервака. Поэтому их используют для лабораторий и в танках (в тех же абрамсах).
Кстати, в IBase впервые появилась такая штука, как хранение массивов в ячейке.

Господа, какие массивы? Одномерные? Телеметрия -- всегда пары "время:значение". Каждый канал (датчик) по своему опрашивается и у каждого "свое" время, даже если они одного типа и стоят на одном блоке/объекте. Датчики бывают разные, одни могут быть крайне наворочены и иметь внутреннюю память. Такие они отдают данные фреймами. Другие просты как грабли -- преобразователь->АЦП->пара регистров. Как только пришел фронт по линии его управления, датчик защелкивает состояние АЦП в одном регистре а состояние шины времени в другом. Заберете -- будут ваши, нет -- перезапишутся следующим. Контроллер или программа данные с каждого датчика собирает в кадры для передачи на верхний уровень. Даже когда снимаются данные с одной точки парой датчиков в рамках резервирования, у них и время измерения и значение могут быть разные.

Цитата: Superwad от 01.02.2017 15:18:26Очень даже получается крайне удобно.
Если уж говорить то БД уссловно делятся на две группы - версионники и протоколисты. Оракл и др. как правило протоколисты - надежно и медленно. Версионники - быстро, но могут пропадать данные при сбросе зависания.
Поэтому версионники, как правило и ставят для сбора данных. К версионникам относят IBase/Firebird и Postgree/ У них есть классная штука - подписка на события (вставка, изменение, удаление) - можно обновлять просмотр данных по команде от сервака. Поэтому их используют для лабораторий и в танках (в тех же абрамсах).
Кстати, в IBase впервые появилась такая штука, как хранение массивов в ячейке. Попросила одна испытательная лаборатория, так и осталась эта приблуда. Правда работа с этим массивом не совсем тривиальная. А так да, BLOB можно, но так как количество датчиков постоянно, то городить блобы не удобно, проще в свою колонку, тем более 32 тысячи колонок - более чем достаточно для одного устройства (надо найти еще такое количество датчиков), а таблиц может быть много - для каждого узла/станка свой. Зато не надо парсить, сразу можно из БД рисовать графики и даже управление наладить Просто и удобно с протоколированием.
Так за бугром решили одну из задач по обработке больших данных (БигДата). Я сам так использую - очень удобно, быстро и надежно.

Вы извините, но выделенное звучит как-то странно. В Oracle и postgresql разные схемы хранения данных, но на общем функционале это не отражается с точки зрения API - обе базы реализуют MVCC - Multiversion Concurrency Control (параллельный достум к нескольким версиям данных). Если вы сказали COMMIT - значит данные сохранены. Выключат свет или нет - уже не важно - буффер сброшен на диск (да, это можно выключить - если у вас RAID массив с батарейкой и т.п., но по-умолчанию оно включено). Что вы называете "подписываться на события" - это триггеры БД? Это тоже не зависит от схемы хранения данных ("версионники"-"протоколисты").

Если вы имели ввиду что-то другое (не MVCC, Triggers), пожалуйста, напишите в общеупотребительных терминах.

Основная подготовка БД к работе с большим потоком данных - это убирание разных ненужных вещей с таблиц, чтобы база данных могла показать большую производительность. Так что на таблице с данными, куда собираются показатели с датчиков, точно не будет никаких триггеров, никаких индексов - ничего, что может помещать работе. А для оптимизации будет использовано партиционирование.

Знаю, что даже MSSQL используется для хранения такого рода данных. Что уж говорить о более серьезных БД вроде Oracle или PostgreSQL.

Цитата: Oleg K. от 02.02.2017 09:11:07Вы извините, но выделенное звучит как-то странно. В Oracle и postgresql разные схемы хранения данных, но на общем функционале это не отражается с точки зрения API - обе базы реализуют MVCC - Multiversion Concurrency Control (параллельный достум к нескольким версиям данных). Если вы сказали COMMIT - значит данные сохранены. Выключат свет или нет - уже не важно - буффер сброшен на диск (да, это можно выключить - если у вас RAID массив с батарейкой и т.п., но по-умолчанию оно включено). Что вы называете "подписываться на события" - это триггеры БД? Это тоже не зависит от схемы хранения данных ("версионники"-"протоколисты").

Если вы имели ввиду что-то другое (не MVCC, Triggers), пожалуйста, напишите в общеупотребительных терминах.

Основная подготовка БД к работе с большим потоком данных - это убирание разных ненужных вещей с таблиц, чтобы база данных могла показать большую производительность. Так что на таблице с данными, куда собираются показатели с датчиков, точно не будет никаких триггеров, никаких индексов - ничего, что может помещать работе. А для оптимизации будет использовано партиционирование.

Знаю, что даже MSSQL используется для хранения такого рода данных. Что уж говорить о более серьезных БД вроде Oracle или PostgreSQL.

Не знаю, как в других БД, но в IBase/Firebird и Postgree - это называется подписка на событие. Есть отдельный элемент управления. вы подписываетесь на определенное событие (Вставка, изменение или удаление - или на все вместе взятое), на конкретную таблицу. Допустим, одна программа сбора данных вставила новые данные в таблицу, а терминальная программа оператора получила по подписке сигнал об изменении в этой таблице и по этой команде - обновила отображаемые данные. Я так делал очень все хорошо и четко работает на Firebird.

Цитата: slavae от 01.02.2017 21:30:33Спасибо, конечно, за просвещение и повтор легенд про Интербейз )) И, насколько я помню, Джим Старки писал на форуме FB, когда они только взялись за опенсорс, что массивы он придумал для аэропорта.

В FB есть возможность группировать по номеру колонки, так же, как сортировать. Это было сделано по моему предложению, когда мы ещё сидели на ньюс-группах ) Это потому что я ленивый, а выписывать поля мне было лениво.

Не вздумайте кого-нибудь уверять, что Оракл - блокировочник, а не версионник )
В моей рабочей системе в таблице товаров TOV в районе 20 млн записей, и я могу сказать, что много данных дают возможность проявить свою изобретательность.

Вы с вашими 32 тыс колонок скорее упрётесь в реальную пропускную способность сети.
Сейчас для закачки больших данных в БД вместо параметрического insert-а я использую их закачку большим подготовленным блоком на большое количество записей как blob или clob, а уже на месте - разбор в процедуре и вставку. Но в случае с датчиками скорее всего никому не нужна подробнейшая детализация мгновенно, поэтому я сразу и предложил хранить данные сразу этими самыми большими кусками со статистикой, а если уж понадобится узнать конкретное значение конкретного датчика, блок можно и разобрать.

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

Цитата: Superwad от 02.02.2017 09:57:52Не знаю, как в других БД, но в IBase/Firebird и Postgree - это называется подписка на событие. Есть отдельный элемент управления. вы подписываетесь на определенное событие (Вставка, изменение или удаление - или на все вместе взятое), на конкретную таблицу. Допустим, одна программа сбора данных вставила новые данные в таблицу, а терминальная программа оператора получила по подписке сигнал об изменении в этой таблице и по этой команде - обновила отображаемые данные. Я так делал очень все хорошо и четко работает на Firebird.

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

Цитата: adolfus от 02.02.2017 08:32:50Господа, какие массивы? Одномерные? Телеметрия -- всегда пары "время:значение". Каждый канал (датчик) по своему опрашивается и у каждого "свое" время, даже если они одного типа и стоят на одном блоке/объекте. Датчики бывают разные, одни могут быть крайне наворочены и иметь внутреннюю память. Такие они отдают данные фреймами. Другие просты как грабли -- преобразователь->АЦП->пара регистров. Как только пришел фронт по линии его управления, датчик защелкивает состояние АЦП в одном регистре а состояние шины времени в другом. Заберете -- будут ваши, нет -- перезапишутся следующим. Контроллер или программа данные с каждого датчика собирает в кадры для передачи на верхний уровень. Даже когда снимаются данные с одной точки парой датчиков в рамках резервирования, у них и время измерения и значение могут быть разные.

"Элементарно. Ватсон" (с) Конан Дойль.
1) У Вас двухмерный массив Время:Данные. Записывать можно одномерный массив с данными, а ДатаВремя в отдельную колонку. Тут зависит только от ваше фантазии, что и как сделать.
2) Сбор данных, их периодичность и составление временного кадра с данными, опять же, описывается ТЗ и здравым смыслом. Можно тупо, периодичность опроса одних датчиков делать чаще, других реже (просто забивать в возвращаемом кадре предыдущие значения).
Это уже регламентируется логикой и физикой управляемого процесса (конечная цель ведь не сами данные, а управляемость заданного процесса в требуемых параметрах).
Так что все правильно говорите, но это совершенно не мешает составить правильно логику формирования временного кадра данных.

Цитата: Oleg K. от 02.02.2017 10:11:19Ну тогда я не знаю, как вы можете обоснованно рассуждать о работе в реальном времени, не понимая, как оно устроено до самого нижнего уровня. Вы же не знаете, что используете...
Ну то есть сделать вы это можете ("раз работало так раньше - то и сейчас будет работать"), но аргументированно что-либо утверждать - нет. И рассуждения ваши о базах данных и их применимости мне теперь кажутся пустыми.

1) Как работают в деталях БД - чтобы правильно ответить на все вопросы - нужно быть одним из разработчиков БД - тогда будешь знать все нюансы работы конкретного продукта. Я им не являюсь, а использую что есть. Написано в литературе подписка на события - я использую этот термин. Возможно, у других авторов документации/литературы может быть свои мнения. 
2) Реальную картину, как это работает, можно получить только в боевых условиях. Абсолютно все предусмотреть невозможно, хотя и необходимо. Потому как теория -это одно, а практика, как показывает жизнь - это совсем другое. То, что должно теоретически рабоать так как задумано, в реальности так не работает. Поэтому я очень много экспериментирую, прежде чем использую ту или иную вещь, алгоритм. У меня лежит много тестовых программ, на которых я отрабатываю отдельные элементы, выбирая оптимальный вариант для конкретной задачи.

Цитата: Superwad от 02.02.2017 10:28:121) Как работают в деталях БД - чтобы правильно ответить на все вопросы - нужно быть одним из разработчиков БД - тогда будешь знать все нюансы работы конкретного продукта. Я им не являюсь, а использую что есть. Написано в литературе подписка на события - я использую этот термин. Возможно, у других авторов документации/литературы может быть свои мнения. 
2) Реальную картину, как это работает, можно получить только в боевых условиях. Абсолютно все предусмотреть невозможно, хотя и необходимо. Потому как теория -это одно, а практика, как показывает жизнь - это совсем другое. То, что должно теоретически рабоать так как задумано, в реальности так не работает. Поэтому я очень много экспериментирую, прежде чем использую ту или иную вещь, алгоритм. У меня лежит много тестовых программ, на которых я отрабатываю отдельные элементы, выбирая оптимальный вариант для конкретной задачи.

Судя по всему, это специфическая для firebird вещь (я про POST EVENT). По крайней мере в других БД (Oracle, PostgreSQL) я такое не встречал, но может быть есть и такие механизмы или схожие.

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

Цитата: Oleg K. от 02.02.2017 10:44:09Судя по всему, это специфическая для firebird вещь (я про POST EVENT). По крайней мере в других БД (Oracle, PostgreSQL) я такое не встречал, но может быть есть и такие механизмы или схожие.

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

1) Эта специфическая вещь (POST EVENT) - это и есть подписка на события, характерна только для версионников (почему - тут к разработчикам) - присутсвует как в IBase/FireBird так и в PostgreSQL/ У меня в Lazarus стоит ZeosDB, там для работы с подписанными сообщениями (Post Event) есть отдельный элемент для одной и второй базы, для остальных такой штуки нет.
Насчет скорости обработки данных на задачах реального времени. Когда я опубликовал свое первое сообщение про ПО Росатома - я там указал, что используются два сервера БД - первая - это БД реального времени (что за она - не указана, видимо какая-то специфическая), из которой потом данные переносятся на ЛЮБУЮ обычную БД, например Оракл. Здесь время уже не критично.
Система построения выглядит следующим образом - первичный сервер реального времени, который собирает данные с датчиков, формирует временной кадр с данными (если надо, создает управляющую последовательность команд на исполнительные механизмы согласно заложенного алгоритма), данные помещаются в БД реального времени. После помещения в БД реального времени, данные для постоянного хранения передаются на другой сервер, где находится обычная БД, тот же Оракл.
Я когда писал свою программу для опроса данных с АЦП использовал аналогичное - на одной машине стояла программа-сервер, которая опрашивала с заданным интервалом данные с датчика, формировала кадр, помещала в аналог БД реального времени (тупо очередь с адресами выделенной памяти), потом данные тупо скидывались на обычный Firebird, где другая программа с другого компьютера была подписана на событие вставки новых данных и по команде SQL сервера обновляла запрос и рисовала график почти в режиме реального времени. так как задержки были приемлемыми. Все это, естественно, было мультипоточным и написано на Паскале, серверная часть на Линуксе, терминальная на Виндовсе.
Кстати, из-за этой специфической особенности, в свое время IBase была запрещена для поставок в страны exUSSR, так как использовалась (и возможно, до сих пор используется) в танках Абрамс. Ведь использую подписку легко создать систему управления на основе получаемых данных, которые автоматически буферизируются и анализируются простыми программными средствами без  специфических заморочек, типа парсинга - но не нужен, данные уже систематизированы и разложены по времени, а так как IBase/Firebird - маленькая, при сбое быстро скидывает зависшие транзакции и запускает новые не обременяя себя обработкой зависших подтвержденных транзакций (так утверждает литература!). Т.е. за скорость и быстродействие приходится платить тем, что возможна потеря некоторых данных/транзакций.
2) Да, потеря некоторых данных за небольшой период времени  это не критично было. Все определяется задачей, критическими моментами, который и выливаются в те или иные решения, которые обговариваются в ТЗ. Если условия позволяют, то систему мониторинга (а иногда и управления!) проще и дешевле реализовать через БД (реального времени или SQL - это уже нюансы).
3) Вот пример промышленного SQL сервера реального времени для хранения данных с датчиков Система сохранения данных TRACE MODE 6 и промышленная СУБД реального времени SIAD/SQL™ 6

Цитата: Superwad от 02.02.2017 10:28:12

Скрытый текст

Элементы механизма

Инициаторами событий являются операции изменения состояния базы данных - успешно выполненные операции INSERT, UPDATE и DELETE. Сигнализация о событии выполняется в триггерах или хранимых процедурах с помощью оператора PSQL
POST_EVENT.
Однако POST EVENT является только одним элементом этого механизма- изолированно он ничего не делает. Это просто посылка сигнала слушающим приложениям. Он не несет никакой информации, о каком событии базы данных он сигнализирует; задачей приложения является обеспечение собственного контекста для каждого события.
Сам механизм событий состоит из нескольких взаимодействий между серверной стороной и приложением.
Элементы на стороне сервера
Элементами на стороне сервера являются:
* один или более триггеров или хранимых процедур, которые выдают оператор
POST_EVENT;
* внутренняя таблица событий - адресат вызовов POST_EVENT - содержит список направленных ей событий процедурами и триггерами во время работы транзакций, при которых возникли события;
* подсистема управления внутренними событиями, которая поддерживает список прослушивающих и ожидающих приложений и работает как "полицейский- регулировщик" для направления соответствующих событий прослушивающим приложениям.
Элементы приложения
На стороне приложения этому механизму нужно:
* приложение, которое способно зарегистрировать свой интерес в событиях;
* другие приложения, которые выполняют те операции DML, которые прослушивает заинтересованное приложение.
Естественно, прослушивающему приложению также необходим механизм реагирования на события.
Элементы интерфейса
При пересылке событий от сервера клиенту используется пара портов, отличная от порта, используемого в главном канале клиент-сервер (обычно порт 3050). Сервер и клиентская библиотека находят произвольную пару портов для использования в качестве трафика событий.
Элементом программного обеспечения является клиентская подпрограмма, называемая функцией обратного вызова события. Это код на клиенте, который вызывается сервером для информирования клиента о событиях, как только подтвердится транзакция, в рамках которой было отправлено ожидаемое событие. Для встроенных приложений предкомпилятор gpre генерирует код для таких функций обратного вызова. Для динамических приложений, которые хотят выполнять прослушивание синхронно (см. следующий раздел), как это делают приложения ESQL, функция обратного вызова содержится в клиентской библиотеке. Динамические приложения могут - и обычно так и делают - прослушивать асинхронно (см. разд. "Асинхронная сигнализация" и "Асинхронное прослушивание"). Для этого они должны предоставить пользовательскую функцию обратного вызова, называемую асинхронным перехватчиком (Asynchronous Trap, AST).

Как таковое отслеживание операций INSERT, UPDATE и DELETE – это и есть механизм триггеров. Аналоги механизма генерации событий для внешних приложений, который Вы описали, есть и в других БД. В оракле это можно осуществлять с помощью external procedures.