Регистрация | Последние сообщения | Персональный список | Поиск | Настройка конференции | Личные данные | Правила конференции | Список участников | Top 64 | Статистика раздела | faq | Что нового v.2.3 | Чат
Skunk Forum - Техника, Наука, Общество » АСУТП »
Создать свою SCADA-систему (страница 4)

Версия для печати (настроить)
Страницы: 1 2 3 4

Новая тема | Написать ответ

Подписаться

Автор Тема:   Создать свою SCADA-систему
ColdFire
Member

Сообщений: 456
Откуда: Россия
Регистрация: Ноябрь 2004

написано 28 Августа 2009 15:42ИнфоПравкаОтветитьIP

Мочалов Роман
Основывается на тестах. Гоняли мы тесты года два назад. Попробовали многие базы данных в стандартной конфигурации, но с производителями не связывались. В бумажном виде результатов не осталось, но расклад на память примерно такой:
- быстрее всего - sqlite (~10-20 тыс. в секунду)
- db2 - порядка 8000
- mysql - порядка 4000
Все последующие < 2000, причем оракл оказался на первый взгляд более-менее, но быстродействие катастрофически падает лимонах на 10 записей (есть подозрение, что можно как-то поднять оптимизацией). mssql с pgsql замкнули цепочку - там на уровне единиц сотен.

FB не тестировали изначально - у него версионная структура, которая разрастается неимоверно при стандартном цикле insert-delete, а гарбадж сам не чистится. Нечто подобное было в древних версиях pgsql. Хотя может за последнее время что-то поменяли.

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

Rudia
Junior Member

Сообщений: 5
Регистрация: Май 2009

написано 28 Августа 2009 16:10ИнфоПравкаОтветитьIP

ColdFire
Хм, 400 млрд. записей, это по скромным подсчетам от 10 до 30 терабайт данных для таблицы из 3 столбцов размерностью по 8 байт с одним индексом, что там за дисковое хранилище?

Сравнивать локальную субд с полноценной сетевой некорректно.

У меня быстро читается и пишется. Что я делаю не так?

ColdFire
Member

Сообщений: 457
Откуда: Россия
Регистрация: Ноябрь 2004

написано 28 Августа 2009 16:38ИнфоПравкаОтветитьIP

Большой локальный массив. Конечно - некорректно. Вопрос только в том, как организовывать доступ.
"Быстро" - понятие весьма условное, привязанное к начинке сервера. Можете посмотреть на top100 современных СУБД (в смысле - инсталляций), там оченно некислые конфигурации.

Мочалов Роман
Junior Member

Сообщений: 5
Откуда: г.Саров, Россия
Регистрация: Ноябрь 2008

написано 28 Августа 2009 17:09ИнфоПравкаОтветитьIP

ColdFire
С тестами понятно, надо делать скидку на то, что это ваши тесты.

цитата:
FB не тестировали изначально - у него версионная структура, которая разрастается неимоверно при стандартном цикле insert-delete, а гарбадж сам не чистится.

Если ли бы Вас сейчас слышали специалисты по FB, они бы посоветовали добавлять "IMHO". В этой фразе из трех утверждений верно только первое. И поправка "может за последнее время что-то поменяли" не спасет

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

[Это сообщение изменил Мочалов Роман (изменение 28 Августа 2009 18:36).]

ColdFire
Member

Сообщений: 458
Откуда: Россия
Регистрация: Ноябрь 2004

написано 28 Августа 2009 17:53ИнфоПравкаОтветитьIP

Мочалов Роман
Да ну ? ИМХО - это к области теории, а я имею в виду конкретные реализации для конкретных механизмов поступления и обновления данных. Поиск в интернете показывает, что проблема с разрастанием размера базы существует как минимум еще в 2008 году. По крайней мере я не представляю, как ее в принципе можно реализовать для версионных СУБД.

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

Rudia
Junior Member

Сообщений: 6
Регистрация: Май 2009

написано 28 Августа 2009 18:13ИнфоПравкаОтветитьIP

ColdFire
Ну насчет скорости postgres могу сказать, что на настольной системе с процессором класса core 10000 записей в секунду - легко. Тем более, что как раз в последние 2 года вышло несколько версий со значительными доработками, сами разработчики назвали это прорывом.
В общем для моих объемов данных хватает core2duo 2 ггц и 4 гига памяти с головой (хотя я хотел под задачу 2xXeon'а ). Загрузка процессора при работе ~5%. Объем данных - порядка 30 значений в секунду. Выборка значений тега за сутки (порядка 1000 значений) ~200 ms при первом обращении к таблице и ~50 ms при последующих. За месяц - 4-6 секунд за любой промежуток времени. Скорость записи и чтения остаются детерминированными, т.к. физически работа идет с небольшими таблицами ~5млн записей. Чтение из субд происходит постоянно, т.к подключено до 50 клиентов и имеется много трендов, а при вызове карты с трендом идет запрос в бд, для отображения данных за несколько последних часов.
Ещё субд с легкостью распараллеливает запросы и может читать в несколько потоков и писать одновременно, благодаря мультиверсионности транзакций. И мусор за собой она убирает)

В общем каждый хвалит свое болото, спорить не буду)

Мочалов Роман
Junior Member

Сообщений: 6
Откуда: г.Саров, Россия
Регистрация: Ноябрь 2008

написано 28 Августа 2009 18:47ИнфоПравкаОтветитьIP

ColdFire
Поиск в интернете показывает, что проблема с разрастанием размера базы существует как минимум еще в 2008 году.

Мы используем InterBase (а затем и Firebird) для архивирования в своих системах начиная с 1999 года. Для других пользователей, основываясь на своем личном опыте, могу сказать, что и тогда и сейчас указанных проблем у нас нет.

ColdFire
Member

Сообщений: 459
Откуда: Россия
Регистрация: Ноябрь 2004

написано 28 Августа 2009 21:37ИнфоПравкаОтветитьIP

Rudia
Ну - я рад за pgsql. Кстати собирать мусор на ходу он умел не всегда - мы в свое время намаялись с вакуумом. Однако, реализация с разбивкой данных по таблицам встречается часто - большинство баз данных, при больших объемах данных с индексом работают неоптимально и скорость доступа сильно падает. Но разбивать данные по таблицам - это теряется всякий смысл реляционости. Примерно так же, как паковать данные в blob - выигрыш в скорости, потеря в универсальности. У вас есть лыжные ботинки 56 размера ? А зачем вам лыжи ?

Мочалов Роман
Все может быть, все может статься. Я не могу поверить, что идут данные в том формате, который вы описали. Т.к. в свое время сам это колупал. У FB, в отличие от других легких баз, основной плюс в хорошей работе именно реляционных механизмов, поддержании актуальности связей и т.д. - этакий макси среди минибаз, по крайней мере mysql до этого еще ползти и ползти, но у него свои плюсы.

Rudia
Junior Member

Сообщений: 7
Регистрация: Май 2009

написано 28 Августа 2009 22:27ИнфоПравкаОтветитьIP

ColdFire
Ну смысл реляционности не теряется, т.к. технология partitioning подразумевает физическое разделение таблицы для увеличения быстродействия при больших объемах данных, а логически - это одна таблица. В postgres это называется наследованием. Все операции, выполняемые над наследуемой таблицей - выполняются на её наследниках. Для оптимизации быстродействия при построении плана запроса используются ограничения в таблицах. Я, например, задаю полю "дата", т.е. если в условии запроса есть конкретный промежуток времени, то мне субд найдет одну или несколько таблиц из нескольких сотен и выполнит операцию над ней. А, к примеру, банальный select count(*) from table выполняется порядка часа ибо он шустрит по всем таблицам.

xandrved
Junior Member

Сообщений: 9
Откуда: г.Кемерово
Регистрация: Сентябрь 2008

написано 04 Сентября 2009 09:00ИнфоПравкаОтветитьIP

Я разработал собственный регистратор НЕЗАБУДКА (на С++ Builder 2006),тестировал его больше года на реальных данных. Особенности:
1. не используется СУБД.
2. нет операций вставки и удаления, только запись в файл.
3. чтение через индекс,который хранится в памяти
4. данные хранятся в влоках, предварительно сжатых оригинальным алгоритмом
5. скорость записи и чтения высокие
6. полностью по всем функциям перекрывает действующий на заводе регистратор
7. может цепляться к любому приложению.
Кому интересно см. xandrved.narod.ru и пишите на почту.
Ожидаю разрешения от высого нач-ва на публикацию итогов тестирования.

Разумеется система предназначена для быстрой работы с технологическими трендами,
а для формирования отчетов данные должны все-таки сливаться в СУБД и обрабатываться через SQL.
Хотя мы успешно обходимся без этого.

bessonov2
Member

Сообщений: 189
Регистрация: Май 2006

написано 13 Сентября 2009 11:42ИнфоПравкаОтветитьIP

Зачем нужна SCADA система, если есть VBA, Delphi и прочее?

Dmitry M. Gaidash
Moderator

Сообщений: 742
Регистрация: Сентябрь 2005

написано 13 Сентября 2009 11:58ИнфоПравкаОтветитьIP

bessonov2
Напиши мне на Delphi полноценную визуализацию для проекта на 18 тысяч тэгов за две недели Чтобы с архивами, алармами, синхронизацией времени и всем-всем-всем прочим. И чтобы все это еще и работало.

Serge78rus
Junior Member

Сообщений: 1
Откуда: Санкт-Петербург Россия
Регистрация: Март 2014

написано 29 Марта 2014 16:33ИнфоПравкаОтветитьIP

Я бы не ориентировался на Silverlight, это привяжет Вас к Microsoft

Добавление от 29 Марта 2014 16:36:

Зачем FBD, почему не дать разработчику нормальный язык, например из тех-же Net

Добавление от 30 Марта 2014 12:20:

цитата:
Vitone писал:
...
- Планируется осуществить Web-доступ к мнемосхеме с использованием технологии Silverlight (достаточно будет поставить спец. плагин для браузера)
...
Насколько все это актуально?
Какие есть вопросы и пожелания?
Буду благодарен за хороший совет.

Вот как мы выводим мнемосхемы на WEB-страницы: ссылка ,
а вот так графики: ссылка

Насчет пожеланий: мне, как программисту, очень не комфортно работать со СКАДАми, я чувствую себя как со связанными руками. Для программиста, на мой взгляд, была бы актуальна не законченная система, а некий фреймворк в виде каркаса приложения с набором высокоуровневых библиотек и все это на нормальном, полноценном языке программирования.

Kipnis
Junior Member

Сообщений: 1
Откуда: Москва
Регистрация: Февраль 2015

написано 03 Февраля 2015 06:42ИнфоПравкаОтветитьIP

А мне как специалисту КИП вообще не комфортно работать со Скадой

Ваш ответ:

Коды форума
Смайлики


Ник:    Пароль       
Отключить смайлики
Страницы: 1 2 3 4

Все время MSK

Склеить | Разбить | Закрыть | Переместить | Удалить

Новая тема | Написать ответ
Последние сообщения         
Перейти к:

Свяжитесь с нами | skunksworks.net

Copyright © skunksworks.net, 2000-2018

Разработка и техническая поддержка: skunksworks.net


Рейтинг@Mail.ru Яндекс.Метрика