Windows 2003 Server - RTOS?

Цитата: Superwad от 27.01.2017 11:29:50Разгребая информацию одного интересного сообщения, с удивлением узнал, что Win2003 serever -есть система реального времени? Когда она такой стала, и как быстро она обрабатывает сообщения в режиме реального времени, или есть специальная сборка для этих целей?

Цитата: Superwad от 27.01.2017 11:29:50

 

)) может это по улучшенным микрософтовским стандартам он как раз туда и попадает )
За что ни возьмись, всё перекурочат, и пытаются пропихивать как стандарт. Может и здесь новые правила разработали.

• +0.00 / 0

Цитата: Superwad от 27.01.2017 11:29:50Разгребая информацию одного интересного сообщения, с удивлением узнал, что Win2003 serever -есть система реального времени?

Цитата: Superwad от 27.01.2017 11:29:50

 

Датировано каким числом было? Первого апреля?
У микрософт есть WinCE. Некоторые ее позиционируют, как ОС мягкого реального времени. Но это не так -- сама микрософт говорит, что это ОС с "поддержкой реального времени". Что касается их серверов, то ни один из ש-серверов никогда не был ОСРВ и не будет. Не та архитектура, чтобы.

• +0.00 / 0

Цитата: adolfus от 29.01.2017 01:13:44Датировано каким числом было? Первого апреля?
У микрософт есть WinCE. Некоторые ее позиционируют, как ОС мягкого реального времени. Но это не так -- сама микрософт говорит, что это ОС с "поддержкой реального времени". Что касается их серверов, то ни один из ש-серверов никогда не был ОСРВ и не будет. Не та архитектура, чтобы.

Цитата: adolfus от 29.01.2017 01:13:44

 

Насчет WinCE я в курсе - у нас на заводе автоматическая линия на ней пашет, на DOS пашут токарные станки, есть фрезер на Линукс от Сименс. А тут разгребал интересную новость от атомщиков - на чем работает система управления реактором. Зашел на сайт разработчика основы этой системы и выпал в осадок - там система управления - эта надстройка над ОС реального времени - и значатся Win2003 Server, Unix, и др.
Начал копать, оказалось, что системы жесткого реального времени - это - двухядерные системы. Разработано как для Win NT, так и для Линукса. Но, интересно, что из всех систем из разряда Виндовс, только 2003 в ней числиться и более ничего свежее нет.
К чему бы это? Совсем стало барахло, или разрабы ушли на более без проблемную с открытыми исходниками ОС?

• +0.01 / 1

Цитата: Superwad от 30.01.2017 06:58:54Насчет WinCE я в курсе - у нас на заводе автоматическая линия на ней пашет, на DOS пашут токарные станки, есть фрезер на Линукс от Сименс. А тут разгребал интересную новость от атомщиков - на чем работает система управления реактором. Зашел на сайт разработчика основы этой системы и выпал в осадок - там система управления - эта надстройка над ОС реального времени - и значатся Win2003 Server, Unix, и др.
Начал копать, оказалось, что системы жесткого реального времени - это - двухядерные системы. Разработано как для Win NT, так и для Линукса. Но, интересно, что из всех систем из разряда Виндовс, только 2003 в ней числиться и более ничего свежее нет.
К чему бы это? Совсем стало барахло, или разрабы ушли на более без проблемную с открытыми исходниками ОС?

Цитата: Superwad от 30.01.2017 06:58:54

 

Ни NT, ни linux в принципе не могут обеспечить режим жесткого реального времени -- не та архитектура. WinCE -- это как раз NT и есть. Все лишнее из нее выбросили и все равно получили только муляж ОС мягкого РВ. Нельзя получить ОСРВ из ОС универсального назначения, банально облегчая ее и освобождая от излишеств. С линуксом по этой причине тоже не очень сложилось. Построение любой ОСРВ, даже мягкого РВ, необходимо выполнять с нуля и для конкретной прикладной задачи. После того, как дюжина разных задач будет беспроблемно окучена, можно браться за обобщение решений и сливать их в модульную ОСРВ.

• +0.01 / 1

Цитата: adolfus от 31.01.2017 02:51:31Ни NT, ни linux в принципе не могут обеспечить режим жесткого реального времени -- не та архитектура. WinCE -- это как раз NT и есть. Все лишнее из нее выбросили и все равно получили только муляж ОС мягкого РВ. Нельзя получить ОСРВ из ОС универсального назначения, банально облегчая ее и освобождая от излишеств. С линуксом по этой причине тоже не очень сложилось. Построение любой ОСРВ, даже мягкого РВ, необходимо выполнять с нуля и для конкретной прикладной задачи. После того, как дюжина разных задач будет беспроблемно окучена, можно браться за обобщение решений и сливать их в модульную ОСРВ.

Цитата: adolfus от 31.01.2017 02:51:31

 

Ну тогда уж и на интеловском процессоре нельзя сделать "жесткую" ОС РВ - сколько он там времени контекст переключает. Должен же где то быть разумный минимум на время обработки события.

• +0.00 / 0

Цитата: folk от 31.01.2017 03:41:09Ну тогда уж и на интеловском процессоре нельзя сделать "жесткую" ОС РВ - сколько он там времени контекст переключает. Должен же где то быть разумный минимум на время обработки события.

Цитата: folk от 31.01.2017 03:41:09

 

Ну РВ это же не обязательно наносекунды. Где-то 100 мкс достаточно, где-то вообще 10 мс. Главное, чтобы гарантированно.

• +0.04 / 4

Цитата: folk от 31.01.2017 03:41:09Ну тогда уж и на интеловском процессоре нельзя сделать "жесткую" ОС РВ - сколько он там времени контекст переключает. Должен же где то быть разумный минимум на время обработки события.

Цитата: folk от 31.01.2017 03:41:09

 

Можно. Дело не в том, сколько времени он переключает контекст, а как это организована обработка запросов от ВУ чуть выше -- в ядре. А времени переключения контекста для ОС жесткого РВ достаточно было даже у i486, на котором было построено этих RTOS вагон и маленькая тележка.

• +0.00 / 0

Цитата: adolfus от 31.01.2017 02:51:31Ни NT, ни linux в принципе не могут обеспечить режим жесткого реального времени -- не та архитектура. WinCE -- это как раз NT и есть. Все лишнее из нее выбросили и все равно получили только муляж ОС мягкого РВ. Нельзя получить ОСРВ из ОС универсального назначения, банально облегчая ее и освобождая от излишеств. С линуксом по этой причине тоже не очень сложилось. Построение любой ОСРВ, даже мягкого РВ, необходимо выполнять с нуля и для конкретной прикладной задачи. После того, как дюжина разных задач будет беспроблемно окучена, можно браться за обобщение решений и сливать их в модульную ОСРВ.

Цитата: adolfus от 31.01.2017 02:51:31

 

1. На Линуксе как раз можно сделать систему мягкого РТОС, из-за того, что тяжелая графика отделена от ядра, в отличии от Винды.
2. Я считал, что WinCE - это не совсем NT, а параллельная мобильная система, которая совместима только на уровне некоторых библиотек. Есть еще вариант Embeded - та, вариант настольной как бы
3. Вот для жесткой РТОС и сделан вариант двухядерности. Интересно то, что для отработки дальнейших сообщений выбрана только Win2003 Server - и больше ничего от M$. Причем все приблуды в виде второго ядра - от сторонних производителей.
Полагаю, все дело в том, что дождаться описания от М$ своих библиотек и системы очень долго и нудно, проще взять Линукс и заваять свое изделие - проще и меньше проблем с лицензиями...

• +0.02 / 2

Цитата: Superwad от 31.01.2017 07:07:191. На Линуксе как раз можно сделать систему мягкого РТОС, из-за того, что тяжелая графика отделена от ядра, в отличии от Винды.
2. Я считал, что WinCE - это не совсем NT, а параллельная мобильная система, которая совместима только на уровне некоторых библиотек. Есть еще вариант Embeded - та, вариант настольной как бы
3. Вот для жесткой РТОС и сделан вариант двухядерности. Интересно то, что для отработки дальнейших сообщений выбрана только Win2003 Server - и больше ничего от M$. Причем все приблуды в виде второго ядра - от сторонних производителей.
Полагаю, все дело в том, что дождаться описания от М$ своих библиотек и системы очень долго и нудно, проще взять Линукс и заваять свое изделие - проще и меньше проблем с лицензиями...

Цитата: Superwad от 31.01.2017 07:07:19

 

1. Можно, но пока не особо получилось. Ядро слишком тяжеловато даже в урезанном варианте -- много лишнего кода, который RTOS не нужен, но убрать его не получается.
3. Насколько я помню, первые эксперименты с NT в качестве RTOS закончились плохо -- полностью обездвиженный по причине отказа энергетики корабль из средиземки буксировали на завод через всю атлантику. В наше время точно такие же дела происходят с фанерным суперэсминцем пиндосов Зумвольт, где по некоторым сведениям ש-довсы крутятся в RT. Известны два случая.

• +0.00 / 0

Цитата: adolfus от 31.01.2017 08:43:331. Можно, но пока не особо получилось. Ядро слишком тяжеловато даже в урезанном варианте -- много лишнего кода, который RTOS не нужен, но убрать его не получается.
3. Насколько я помню, первые эксперименты с NT в качестве RTOS закончились плохо -- полностью обездвиженный по причине отказа энергетики корабль из средиземки буксировали на завод через всю атлантику. В наше время точно такие же дела происходят с фанерным суперэсминцем пиндосов Зумвольт, где по некоторым сведениям ש-довсы крутятся в RT. Известны два случая.

Цитата: adolfus от 31.01.2017 08:43:33

 

Вот потому, зная как работают эти Помойки от M$ мне не нравится их применение в качестве РТОС. А Линукс на фрезере - работает, но так - интерфейс не спешит сильно шевелится, но и не сказать что совсем уж тормоз.
На других станках стоит XP только как терминал, а вот что исполняет в стойках за система РТОС- ХЗ (железо Сименс).
ЗЫ. прикол в чем у надстройки, что используют атомщики - данные с датчиков запихиваются в БД РЕАЛЬНОГО времени, после чего перекидываются на хранения в обычную SQL сервер - по умолчанию - Oracal.

• +0.01 / 1

Цитата: Superwad от 31.01.2017 10:17:15...в обычную SQL сервер - по умолчанию - Oracal.

Цитата: Superwad от 31.01.2017 10:17:15

 

Не думаю, что это обычная БД.

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

• +0.00 / 0

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

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

Цитата: Lapsha от 01.02.2017 06:38:43

 

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

• -0.01 / 1

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

Цитата: slavae от 01.02.2017 07:40:56

 

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

• +0.00 / 0

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

Цитата: slavae от 01.02.2017 07:40:56

 

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

• +0.00 / 0

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

Цитата: adolfus от 01.02.2017 09:08:14

 

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

• -0.01 / 1

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

Цитата: slavae от 01.02.2017 10:00:29

 

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

• +0.00 / 0

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

Цитата: adolfus от 01.02.2017 09:08:14

 

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

• +0.00 / 0

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

Цитата: slavae от 01.02.2017 07:40:56

 

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

• +0.01 / 1

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

Цитата: Superwad от 01.02.2017 15:18:26

 

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

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

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

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

• +0.03 / 5

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

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

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

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

Цитата: slavae от 01.02.2017 21:30:33

 

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

• +0.00 / 0

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

Цитата: Superwad от 01.02.2017 15:18:26

 

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

• +0.00 / 0

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

Цитата: adolfus от 02.02.2017 08:32:50

 

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

• +0.01 / 1

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

Цитата: Superwad от 01.02.2017 15:18:26

 

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

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

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

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

• +0.01 / 1

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

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

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

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

Цитата: Oleg K. от 02.02.2017 09:11:07

 

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

• +0.00 / 0

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

Цитата: Superwad от 02.02.2017 09:57:52

 

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

• +0.00 / 0

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

Цитата: Oleg K. от 02.02.2017 10:11:19

 

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


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

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

• +0.00 / 0

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

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

 

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

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

• +0.00 / 0

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

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

Цитата: Oleg K. от 02.02.2017 10:44:09

 

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

• +0.00 / 0

Цитата: 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).

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

 

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

• +0.00 / 0

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

Цитата: Alexxey от 02.02.2017 15:16:26

 

Я не спорю, может быть и есть, но только в этих двух SQL серверах это сделано удобоваримо и доведено до логического конца как в серверной, так и клиентской частях.

• +0.02 / 1

Цитата: Superwad от 02.02.2017 15:24:48Я не спорю, может быть и есть, но только в этих двух SQL серверах это сделано удобоваримо и доведено до логического конца как в серверной, так и клиентской частях.

Цитата: Superwad от 02.02.2017 15:24:48

 

Что может быть удобоваримее, логичнее триггеров?

• +0.01 / 1

Цитата: Superwad от 02.02.2017 15:24:48Я не спорю, может быть и есть, но только в этих двух SQL серверах это сделано удобоваримо и доведено до логического конца как в серверной, так и клиентской частях.

Цитата: Superwad от 02.02.2017 15:24:48

 

Как Вы можете это утверждать, если не знаете как это сделано в других БД.
Смотрите, для Оракла Вы пишете обычную стандартную библиотеку на удобном Вам языке C, C++, Delphi, Pascal, Java... хоть Visual Basic. Подключаете её как external library
create or replace library my_utils is '${EP_LIB_HOME}/utils.so'
или
create or replace library my_utils is 'C:\my_utils.dll'
например.
И пользуетесь функциями из неё, как обычными хранимыми процедурами/функциями
CREATE OR REPLACE FUNCTION some_func (
x BINARY_INTEGER,
y BINARY_INTEGER)
RETURN BINARY_INTEGER
AS LANGUAGE C
LIBRARY my_utils
NAME "some_func";
Вызывайте хоть из триггеров, хоть из других хранимых процедур, хоть просто из SQL.
Что может быть гибче и удобнее?

• +0.02 / 2

Цитата: Alexxey от 02.02.2017 15:47:46Как Вы можете это утверждать, если не знаете как это сделано в других БД.
Смотрите, для Оракла Вы пишете обычную стандартную библиотеку на удобном Вам языке C, C++, Delphi, Pascal, Java... хоть Visual Basic. Подключаете её как external library
create or replace library my_utils is '${EP_LIB_HOME}/utils.so'
или
create or replace library my_utils is 'C:\my_utils.dll'
например.
И пользуетесь функциями из неё, как обычными хранимыми процедурами/функциями
CREATE OR REPLACE FUNCTION some_func (
x BINARY_INTEGER,
y BINARY_INTEGER)
RETURN BINARY_INTEGER
AS LANGUAGE C
LIBRARY my_utils
NAME "some_func";
Вызывайте хоть из триггеров, хоть из других хранимых процедур, хоть просто из SQL.
Что может быть гибче и удобнее?

Цитата: Alexxey от 02.02.2017 15:47:46

 

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

• +0.01 / 2

Вот компоненты в Лазаре (на примере ZeosDB)


Вот свойства



Вот события


Что еще может быть быстрее и проще?
Ставишь в событии OnEventAlert на обновление графика в окне, прописываешь подписку на какое событий, активизируешь подписку - и все!
Да, это реально работает.

• +0.00 / 0

Цитата: Superwad от 02.02.2017 16:32:26Вот компоненты в Лазаре (на примере ZeosDB)
...
Что еще может быть быстрее и проще?
Ставишь в событии OnEventAlert на обновление графика в окне, прописываешь подписку на какое событий, активизируешь подписку - и все!
Да, это реально работает.

Цитата: Superwad от 02.02.2017 16:32:26

 

Не стоит быть столь категоричным и утверждать превосходство единственных решений.

Вы понятия не имеете какой код, для общения с СУБД генерирует коннектор, насколько он эффективен и оптимален - вопрос тёмный и кроме как на глаз обычно не определяемый.  Я был свидетелем того какие селекты к базе генерировал ORM в крупной Информационной Системе, подобной дикости я бы не смог выдумать даже в запое.

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

2 страницы продолжается дискуссия о неких волшебных "БД реального времени"...   тысячах датчиков....   супербыстрых нано, 3д, инновационных методах...   

Господа, о чём Вы? 
Любая Система Управления Базами Данных - это средство структурирования, хранения и анализа некоторых абстрактных данных.
Миллионы датчиков, сложнохитрых, их все вливают...   коллеги, забудьте про датчики, рассматривайте поток данных. В компьютере есть только 0 и 1, остальное несущественно.  Если поток "сырых" данных превышает возможности передачи коммуникационных каналов (неважно как, по ширине и латентности),  то выхода только два - либо сжимать данные либо расширять каналы.   Ни одна субд не может сохранить поток сырых данных  на дисковый массив быстрее, чем сам этот массив в состоянии воспринять. Есть субд оптимизированные на "запись" (они производят минимальную обработку входных данных перед записью), но они медленно читают и ещё медленней "считают".   Есть СУБД которые позволяют делать очень мощную обработку выборки, с кучей пред и пост математики, но это возможно только при глубокой структуризации данных, которая делается зачастую не в один этап (при записи) а в несколько - они не в состоянии очень быстро записать.

• +0.01 / 1

Цитата: Superwad от 02.02.2017 16:32:26Что еще может быть быстрее и проще?
Ставишь в событии OnEventAlert на обновление графика в окне, прописываешь подписку на какое событий, активизируешь подписку - и все!
Да, это реально работает.

Цитата: Superwad от 02.02.2017 16:32:26

 

В общем, да, мне на Оракле сейчас такой классной штуки не хватает.
На всякий случай скажу, что в ФБ, (думаю, и в других) эти события пересылаются клиенту по менее уровневому каналу, типа между сокетами tcp. Во времена IB они были глючными, приходилось для приёма событий делать отдельный коннект к БД чисто для приёма событий )

• -0.01 / 1

Цитата: Superwad от 02.02.2017 16:06:14Лучше и проще - подписка на события! Потому что:
1) То что вы привели - работает в синхронном режиме, генерируя либо дополнительную постоянную нагрузку на сервер, либо постоянный сетевой трафик запросами!
2) Подписка на события - это асинхронный механизм! Выше я уже привел отрывок из книги, как это работает. А работает просто. Подписываетесь через специальный механизм на сервере один раз на интересующие Вас события и получаете их, когда они только произошли в режиме реального времени (только ответ!). А закрываете сессию асинхронно, командой отмены подписки! Все. Никаких дополнительных расходов!!!

Цитата: Superwad от 02.02.2017 16:06:14

 

Во-первых, как там реализован этот специальный механизм, и какие он вызывает накладные расходы по содержанию всей этой тряхомундии по отслеживанию подписчиков и проч., – мы можем только догадываться.
Во-вторых, то что я привёл – полностью в Ваших руках. Никто не заставляет выполнять тяжёлую синхронную обработку прямо в функции Вашей dll. Вы вольны сделать её максимально лёгкой, например, просто отправляющей сообщение окну другого приложения, или взводящей семафор/мьютекс, и т.д. и т.п. И обрабатывайте потом это событие сколь угодно асинхронно.

• +0.02 / 1

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

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

Цитата: Lapsha от 01.02.2017 06:38:43

 

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

• +0.00 / 0

Цитата: Superwad от 30.01.2017 06:58:54Но, интересно, что из всех систем из разряда Виндовс, только 2003 в ней числиться и более ничего свежее нет.

Цитата: Superwad от 30.01.2017 06:58:54

 

Если посмотреть объективно, то 2003 была и, на мой вкус, остаётся единственной ихней хорошей серверной ОС. Там уже было всё, что надо для полноценной работы и ещё не было того, что не надо.В 2008 уже пошло надувание свистелками и перделками, лиж бы продать, про те поделки что вышли позже - даже упоминать не буду. Со времён 2003 ничего нового, реально нужного в работе они не придумали.

• +0.00 / 0

Цитата: Superwad от 27.01.2017 11:29:50Разгребая информацию одного интересного сообщения, с удивлением узнал, что Win2003 serever -есть система реального времени? Когда она такой стала, и как быстро она обрабатывает сообщения в режиме реального времени, или есть специальная сборка для этих целей?

Цитата: Superwad от 27.01.2017 11:29:50

 

Это наверное специальная версия для дронов чтобы не сильно разгонялись а летали медленно и нызенько ... Иранцы когда дрон посадили то обнаружили там WinNT 

• +0.02 / 1