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

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

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

Подписаться

Автор Тема:   создаем свою SCADA.бесплатный регистратор истории и событий
xandrved
Junior Member

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

написано 30 Сентября 2008 08:12ИнфоПравкаОтветитьIP

Начали тестирование Незабудки 2.0 с дискретностью до 100 мс.
Работает.
Жаль, что в 2000 г.,когда началась эксплуатация нашего регистратора на базе Interbase,
я не знал что "На SQL-сервере нормальный регистратор не построить".
А вот построили,работает,технологи довольны.

Теперь можно и умных людей послушать,узнать чего у них не получилось,какие бывают SQL-сервера,
какой крутой WINCC и как надо делать правильные фичи "без лишнего гемора".
Господа!Может укажите ссылку,где брали инфу.
А может расскажите о том что получилось? АУ!

Dmitry M. Gaidash
Moderator

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

написано 30 Сентября 2008 08:40ИнфоПравкаОтветитьIP

Arsen
Если ближе к практике, то я еще не видел ни одного OPC-клиента (а я их перепробовал кучу), в котором можно было бы задать время обновления тэгов менее 1 с

ColdFire
Member

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

написано 30 Сентября 2008 09:38ИнфоПравкаОтветитьIP

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

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

Добавление от 30 Сентября 2008 10:22:

Arsen
Gериод обновления группы задается в миллисекундах, так что теоретически можно указать 1 миллисекунду, и даже ноль, что означает "As fast as possible". Другое дело, что реальные промышленные сети имеют все ж таки более низкую скорость передачи данных и достижимый RR где-то в зоне 5+ мсек. Надо будет поэкспериментировать на досуге. Как-то мы обычно ставим 100 мсек и этого хватает.

xandrved
Junior Member

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

написано 30 Сентября 2008 10:28ИнфоПравкаОтветитьIP

[q]ColdFire
Ирония- не хамство.Если перегнул-прошу прощения.
Дискуссия полезная но мало конкретной информации.
Мы же даем ссылку на свой сайт, что мешает назвать ваш продукт и дать ссылку.
Есть интерес.

nemcheg
Junior Member

Сообщений: 18
Регистрация: Август 2008

написано 30 Сентября 2008 10:34ИнфоПравкаОтветитьIP

xandrved
И до какого объема доживала Ваша база на практике?
2-3 гига данных потянет? Как со скоростью будет при таких размерах?
Все таки, насколько я понимаю, в основе лежит бинарное поле, а SQL для чего нужен?
Почему Вы решили именно ФБ использовать, а не Беркли допустим? Или просто в своем формате хранить в виде файла?

ColdFire
Member

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

написано 30 Сентября 2008 10:48ИнфоПравкаОтветитьIP

xandrved
Мы делаем продукт "АльфаКомплекс" - www.enertek.ru, но там сейчас большие переделки грядут по софтовой части. Врядли кто с ним сильно сталкивался, т.к. долгое время он шел только под проекты.

Какая полезная информация вам нужна ? Я же привел примеры реальных тестов. Вам нужны цифры ? Oracle дает несколько сотен tps в зависимости от настроения, MS в районе тысячи, типовые базы данных дают ~2-3 тысячи, sqlite выдает ~6000.

nemcheg
Забудьте о Беркли - его купил Oracle полтора года назад, после чего поддержка BDB была выкинута в частности из MySQL, что крайне и крайне печально. С Oracle договориться о лицензировании у нас не получилось.

nemcheg
Junior Member

Сообщений: 19
Регистрация: Август 2008

написано 30 Сентября 2008 11:31ИнфоПравкаОтветитьIP

ColdFire
А у Вас какая база используется? Своя полностью?

ColdFire
Member

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

написано 30 Сентября 2008 11:47ИнфоПравкаОтветитьIP

У нас подключается любая SQL сетевая база, в которой есть встроенный в систему драйвер, либо ODBC, либо ADO (ADO только для микро-версии сервера; в смысле три варианта - наш драйвер native, ODBC или ADO). Но ODBC жуткая погань в плане скорости, мы не рекомендуем ее пользовать для систем отличных от микро-версии (50 узлов).

Штатно мы комплектуем систему с MySQL, либо как вариант для систем мид-класса можно брать DB2 персонального исполнения.
Своя база данных была раньше, но мы от нее отказались некоторое время назад - все же заказчики хотят стандартные решения, плюс не так уж и быстро получается.

nemcheg
Junior Member

Сообщений: 20
Регистрация: Август 2008

написано 30 Сентября 2008 12:21ИнфоПравкаОтветитьIP

ColdFire
Да, ODBC это отстой, полностью с Вами согласен.
Но мне интересно, почему именно SQL? По моим наблюдениям, практически все SQL сервера (MySQL не исключение, скорее даже в первых рядах) уходили в мир иной, когда размеры базы превышали пару гигов. MySQL отличался особенно тем, что загружал проц на 100% на несколько секунд при любых запросах на большой базе...

ColdFire
Member

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

написано 30 Сентября 2008 12:42ИнфоПравкаОтветитьIP

SQL - потому что это промышленный стандарт. Можно конечно встать в позу и воткнуть нечто свое (или не свое, но не-SQL), и потерять заказчика. Системе самой по себе без разницы, но все внешние средства (MES, ERP, аналитика) хотят именно SQL. Никто ради вашей чудо-системы не будет выкидывать SAP или приклячивать к ней непонятно что.

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

nemcheg
Junior Member

Сообщений: 21
Регистрация: Август 2008

написано 30 Сентября 2008 16:47ИнфоПравкаОтветитьIP

ColdFire
По поводу SQL: Вы говорили, что нормальный регистратор можно сделать, только используя бинарный формат. Но тогда возникает вопрос: чтобы внешнее приложение могло работать с такими данными, оно обязано знать конкретно этот формат. А это значит, что никакой стандартизации тут быть не может, каждая софтина по любому, помимо SQL запросов, обязана уметь работать еще и с полученными бинарными данными. То есть все равно, нужны дополнительные библиотеки. Или я не прав?

ColdFire
Member

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

написано 30 Сентября 2008 17:12ИнфоПравкаОтветитьIP

nemcheg
Нет, я писал, что чтобы писать в SQL в том виде, в котором этот самый SQL имеет какой-то смысл (то есть в raw-виде - одна запись = одна строка в таблице), необходимо попотеть с выбором и оптимизацией базы данных. Иначе будет как я описывал.

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

Мы не смотрели как в FB сделалы binary. Если их реализация версионна как обычные типы данных, это будет очень плохо (врядли разработчики делали два механизма доступа). Если нет - шансы есть.

Внешнее приложение вполне может лезть к данным в обычном SQL виде - как это делают разные генераторы отчетности вроде Crystal, FR, RB и т.д. Более того, к данным могут лезть вышестоящие или смежные системы.

Павел Мощицкий
Member

Сообщений: 2283
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 30 Сентября 2008 21:18ИнфоПравкаОтветитьIP

Dmitry M. Gaidash
было бы задать время обновления тэгов менее 1 с
Возьми, созданный при мне, OPC-ОВЕН. Реально шаг 50 мс выдержит. Меньше, появлялись вопросы, не знаю как сейчас.

Arsen
Junior Member

Сообщений: 13
Откуда: Донецк, Украина
Регистрация: Август 2008

написано 30 Сентября 2008 21:43ИнфоПравкаОтветитьIP

ColdFire
SQL - потому что это промышленный стандарт.
Наверное, вы имели в виду ОРС? Потому что SQL - это не промышленный стандарт
Что касается SQL, наши заказчики практически поголовно отказывались от его поддержки - одна из причин, по которой нам пришлось делать свою БДРВ. Ну не тянет мускуль базы за пару месяцев без напильника.
SQL имеет врожденную проблему - это индексы. Когда данных становится очень много, поиск по неоптимизированному индексу становится долог (характеристика логарифмическая). Плюс, при малых размерах записей поддержание индекса соизмеримо по времени с поддержанием самой базы данных.
Абсолютно с вами согласен. Намучались с ними.
Другой вариант - это вариант интачевского Historian, где все данные лежат во внутреннем формате на диске, а от SQL сервера остались рожки да ножки - типа парсера SQL.
Да, и не только интач - тот же WinCC поступает точно так же, вернее там просто MS SQL сервер "подучен" на понимание винцц-шного бинарного формата.

nemcheg
То есть все равно, нужны дополнительные библиотеки.
Да, нужны. Либо библиотеки, либо как минимум протокол запросов надо знать.

xandrved
какие бывают SQL-сервера, какой крутой WINCC
Крутой то крутой, да только монстровит чересчур Поэтому мы, товарищи, идем другим путем

nemcheg
Junior Member

Сообщений: 22
Регистрация: Август 2008

написано 01 Октября 2008 12:14ИнфоПравкаОтветитьIP

ColdFire
Если их реализация версионна как обычные типы данных, это будет очень плохо (врядли разработчики делали два механизма доступа). Если нет - шансы есть.
А что обозначает "версионна"? И чем это плохо?

ColdFire
Member

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

написано 01 Октября 2008 21:36ИнфоПравкаОтветитьIP

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

Вообще, современные СУБД в большинстве своем транзакционные. А для обсуждаемых тут целей эти транзакции нафиг не сдались - идет доступ single write / multiple read, да еще с существенным сужением формата, который разруливается от конфликтов существенно проще (с меньшими накладными расходами), чем абстрактные транзакции. Более того, руление как правило делается на уровне драйвера ввода-вывода, так что от базы данных нужен сущий примитив.

Arsen
SQL как ANSI SQL'92 (если не изменяет память, есть версия поновее) - стандарт де-факто для доступа к данным, может и с другим пониманием термина "промышленный" - как противопоставление термину "бытовой". Своя БДРВ - штука, конечно, неплохая, пока вы работаете в замкнутом цикле. Как только появляется необходимости предоставления доступа наружу, все будет плохо.
Мускуль - смотря с какой версией работать, с каким движком внутри, какова структура данных и т.д. Нас и наших заказчиков устраивает.
Вы в курсе, что мускуль есть sql-движок плюс движок хранения данных, которых несколько на выбор (как я уже писал, BDB оттуда убрали - с ним некоторые конкретные задачи решались лучше). От того, какой вариант выберите - все собственно и зависит.

nemcheg
Junior Member

Сообщений: 23
Регистрация: Август 2008

написано 02 Октября 2008 15:17ИнфоПравкаОтветитьIP

xandrved
Каждую минуту часовые блоки (отдельным потоком)записываются в базу данных типа FIREBIRD.

А что произойдет при сбое в этот момент? Получается, будут утеряны данные за 1 минуту?

Кстати, ссылка - это оно? Если да, то возможно ли сохранять данные с переменным периодом опроса, или он всегда жестко равен 1 секунде?

xandrved
Junior Member

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

написано 03 Октября 2008 04:51ИнфоПравкаОтветитьIP

[q]nemcheg
Размер базы 24 ГБ,содержит данные за 9 месяцев, с того времени как мы перешли на FIREBIRD.
Тормозов не наблюдалось.Обслуживания не проводилось.

Начинали с Interbase, потому что на нем уже были задачи.
После изучения попробовали регистрацию.Долго не получалось (медленно пишет и читает).
Проблема была решена после использования часовых блоков(BLOB-полей)+ сжатие.
Затем перешли на FIREBIRD ибо бесплатный.
SQL-сервер используется только как механизм сохранения (индексированных) данных и собственно как сервер.

В случае сбоя (а такое у нас бывает крайне редко) теряется часовой блок полностью, а точнее вся транзакция.
Ссылка на www.interface.ru наша, размещена по просьбе админитрации.
Период опроса может быть разный , но на практике такое разнообразие никогда не применяли.
Если можно расскажите о своих разработках.
Судя по замечаниям Вы основательно знакомы с проблематикой.

Arsen
Junior Member

Сообщений: 14
Откуда: Донецк, Украина
Регистрация: Август 2008

написано 04 Октября 2008 13:02ИнфоПравкаОтветитьIP

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

Павел Мощицкий
Member

Сообщений: 2295
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 04 Октября 2008 14:26ИнфоПравкаОтветитьIP

Arsen
все равно формирует запросы в каком-либо своем формате
Так это тормозит даже больше, чем чистое использование SQL.

Arsen
Junior Member

Сообщений: 15
Откуда: Донецк, Украина
Регистрация: Август 2008

написано 04 Октября 2008 14:33ИнфоПравкаОтветитьIP

Павел Мощицкий
Да, и кроме того SQL сервера вместе с данными передают дополнительную служебную информацию.
А это суммарно около 30% полезного трафика.

ColdFire
Member

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

написано 04 Октября 2008 20:55ИнфоПравкаОтветитьIP

Arsen
Вы совершенно правы - SQL это стандарт языка запросов, а также некоторой части DDL. А интерфейсы к разным базам данных действительно разные как с точки зрения кода, так и с точки зрения механизмов. Так что варианта тут два - или искать готовую прослойку, или писать свою (в том смысле, что унифицируется механизм доступа к данным внутри вашего кода - прямая запись в коде "если хотим oracle, то open('oci32.dll') и так далее"). ODBC как прослойка никуда не годится - он зараза весь текстовый внутри и жутко неоптимальный. ADO недалеко от него ушел. Это одна из причин, почему SQL который MS SQL в наших целях также не котируется (нету бинарных драйверов).

А дальше все зависит от того, насколько качественно сделана связка "прослойка-нативный драйвер". Если там будет десять раз из текста туда-сюда гоняться, проку никакого. 30% полезного трафика не особо напрягает, но для выжимания соков сюда тоже имеет смысл лезть. В любом случае никто данные поштучно в сервер не пишет.
Большинство драйверов (и ответная поддержка у сервера) умеют делать prepare-execute над запросом, то есть текстовый запрос компилируется один раз и запоминается и потом гоняются только параметры.

Ваш ответ:

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


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

Все время MSK

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

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

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

Copyright © skunksworks.net, 2000-2018

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


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