Применение tarantool в АСУТП

410 views
Skip to first unread message

Евгений Авдеев

unread,
Feb 27, 2014, 7:22:24 AM2/27/14
to tarant...@googlegroups.com
Не смотря на явную ориентацию разработчиков Tarantool для web приложений, по своим характеристикам база потенциальна не плохо подходит для разработки АСУТП приложения для промышленных предприятий. Тут подкупает прежде всего внутренний планировщик событий, позволяющий анализировать поток данных на лету. Отсюда вопрос. Планируется ли адаптация приложения под платформу WIndows. Хочу подчеркнуть. Windows это не пустая хотелка, а стратегия многих крупных промышленных предприятий.

Konstantin Osipov

unread,
Feb 27, 2014, 8:02:09 AM2/27/14
to tarant...@googlegroups.com
* Евгений Авдеев <avv....@gmail.com> [14/02/27 16:48]:
АСУ ТП - это прекрасно и очень хочется там быть.

Порт на Windows в принципе возможен, но очень и очень затратен
(несколько месяцев работы, по оценкам).
Практически уверен, что Mail.Ru этим заниматься не будет, т.е.
нужно либо делать самостоятельно с нашей помощью, либо искать
третью сторону, которая это будет делать.

--
http://tarantool.org - an efficient, extensible in-memory data store

Евгений Авдеев

unread,
Feb 27, 2014, 1:42:31 PM2/27/14
to tarant...@googlegroups.com
Жаль, но я думаю вы все равно рано или поздно придете к необходимости делать порт для
Windows по примеру Redis или MongoDB. Хочу подчеркнуть что NoSQL база данных именно для АСУТП
это не паханное поле, на котором никого нет.
Существует необходимость передачи агрегированных данных, уже сформированных по событию из NoSQL
базы в реляционную общего назначения MSSQL или Oracle.Можно конечно написать службу которая будет 
все это передавать. Но гораздо было бы удобнее, если бы был провайдер для линка например MSSQL -> Tarantool, 
чтобы MSSQL мог самостоятельно забирать нужные ему данные (предварительно сформированные с помощью процедур на Tarantool)

Konstantin Osipov

unread,
Feb 27, 2014, 2:20:24 PM2/27/14
to tarant...@googlegroups.com
* Евгений Авдеев <avv....@gmail.com> [14/02/27 23:09]:

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

Если нет возможности выделить физически машину под тарантул (что
сомнительно, в конце концов Adruino или подобная ему система
вполне достаточна для нас) то можно запустить в
эмуляторе/виртуалке.

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

Евгений Авдеев

unread,
Feb 27, 2014, 2:50:00 PM2/27/14
to tarant...@googlegroups.com
Tarantool уже сейчас работает на виртуальной машине, и работает хорошо. На тестовой машине.
 Вопрос в инертной политике больших предприятий. Существует стандарт предприятия и если в работе сотня серверов
с Windows Server. Сложно убедить руководство поставить Linux.
Но ваша позиция мне вполне понятна.

Причем тут Adruino? Это игрушечная электроника. 
Я говорил о АСУТП металлургического предприятия..

Roman Tsisyk

unread,
Feb 28, 2014, 2:35:58 AM2/28/14
to tarant...@googlegroups.com, Евгений Авдеев
2014-02-27 23:50 GMT+04:00 Евгений Авдеев <avv....@gmail.com>:
>> Tarantool уже сейчас работает на виртуальной машине, и работает хорошо. На
>> тестовой машине.
>
> Вопрос в инертной политике больших предприятий. Существует стандарт
> предприятия и если в работе сотня серверов
> с Windows Server. Сложно убедить руководство поставить Linux.

На этот случай может сгодиться Hyper-V.
Возможно, получится применить Linux и Tarantool для новых проектов.

> Но ваша позиция мне вполне понятна.
>
>> Причем тут Adruino? Это игрушечная электроника.

Конечно, под 8 битный процессор Tarantool никоим боком даже не скомпилируется.
Здесь просто слегка попуталось название, не более того.
Имеелось ввиду, что практически любая игрушечная коробка с **x86** на
борту вполне может потянуть Tarantool.

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

Спасибо!

---
WBR,
Roman Tsisyk <ro...@tarantool.org>
http://tarantool.org/ - an efficient in-memory data store and a Lua
application server

Konstantin Osipov

unread,
Feb 28, 2014, 4:02:37 AM2/28/14
to tarant...@googlegroups.com
* Евгений Авдеев <avv....@gmail.com> [14/02/28 00:09]:
> Я говорил о АСУТП металлургического предприятия..

Речь идёт о необходимой мощности для Тарантула для выполнения
своей работы. Мы будем выдавать очень приемлимую
производительность на железе уровня сотового телефона.

Евгений Авдеев

unread,
Feb 28, 2014, 9:25:25 AM2/28/14
to tarant...@googlegroups.com, Евгений Авдеев, ro...@tarantool.org
В нашу базу данных поступают сигналы от базовой автоматики (PLC контроллеров, OPC серверов) со скоростью примерно 2000-9000 insert/sec
Большую часть из этих сигналов необходимо анализировать в режиме реального времени на предмет выполнения рецептуры, технологии производства,
реализации системы прослеживаемости продукции. Постфактум делаются запросы в базу данных. Например получить min или max температуры, давления или токов за любой промежуток времени от минут до часов.
Запросы довольно тяжелые. и.т.д. После предварительной обработки результаты пишутся в MSSQL для формирования отчетной документации.
Просто написать для этого программу не получается потому что задачи меняются ... системы дорабатываются. Производство непрерывное и останавливать его для отладки программ возможности нет.
Вся логика пишется в виде MySQL процедур с применением встроенного планировщика задач.
MSSQL, Oracle с данной задачей не справляется. Мы используем MySQL который медленно но выполняет свою работу. 
Проблема в том что таблицы типа heap (memory) блокируются полностью и не позволяют оперировать большими объемами данных.
Применение Oracle TimesTen большого выигрыша производительности не дает, проблему не решают и не стоят своих денег (для нас).
Я сейчас подыскиваю подходящую NoSQL базу со встроенным планировщиком и возможностью разработки хранимых процедур.

пятница, 28 февраля 2014 г., 11:35:58 UTC+4 пользователь Roman Tsisyk написал:

Konstantin Osipov

unread,
Feb 28, 2014, 10:59:04 AM2/28/14
to tarant...@googlegroups.com, Евгений Авдеев, ro...@tarantool.org
* Евгений Авдеев <avv....@gmail.com> [14/02/28 18:26]:

Мы хорошо вам подходим :). Недавно проводил моделирование, на
моём лаптопе, intel core i5, до 15 000 CALL/second на одном ядре, при этом
каждая хранимка делала ок. 30 select'ов и insert'ов, т.е.
речь шла о 450 000 rps на одно ядро.

Попробуйте поднять на ваших Windows машинах виртуалку, и
потестировать производительность в ней.

> В нашу базу данных поступают сигналы от базовой автоматики (PLC
> контроллеров, OPC серверов) со скоростью примерно 2000-9000 insert/sec
> Большую часть из этих сигналов необходимо анализировать в режиме реального
> времени на предмет выполнения рецептуры, технологии производства,
> реализации системы прослеживаемости продукции. Постфактум делаются запросы
> в базу данных. Например получить min или max температуры, давления или
> токов за любой промежуток времени от минут до часов.
> Запросы довольно тяжелые. и.т.д. После предварительной обработки результаты
> пишутся в MSSQL для формирования отчетной документации.
> Просто написать для этого программу не получается потому что задачи
> меняются ... системы дорабатываются. Производство непрерывное и
> останавливать его для отладки программ возможности нет.
> Вся логика пишется в виде MySQL процедур с применением встроенного
> планировщика задач.
> MSSQL, Oracle с данной задачей не справляется. Мы используем MySQL который
> медленно но выполняет свою работу.
> Проблема в том что таблицы типа heap (memory) блокируются полностью и не
> позволяют оперировать большими объемами данных.
> Применение Oracle TimesTen большого выигрыша производительности не дает,
> проблему не решают и не стоят своих денег (для нас).
> Я сейчас подыскиваю подходящую NoSQL базу со встроенным планировщиком и
> возможностью разработки хранимых процедур.
>

Евгений Авдеев

unread,
Apr 4, 2015, 3:07:53 AM4/4/15
to tarant...@googlegroups.com
Спустя год после разговора о применении Tarantool для разработчиков Windows, в частности в АСУТП ничего не изменилось. А жаль. 
1. Клиентской windows программы для разработки процедур, написания запросов - как не было, так и нет.
2. net библиотеки для доступа к tarantool из c# - как не было, так и нет.
3. Порта для windows сервера нет.

Это не критика, это мнение со стороны. Пока вы не обратите внимание на разработчиков Windows а нас большинство. Tarantool так и останется малоизвестным
решением, о котором никто не слышал (в отличие от Redis).
Было бы не плохо хотя бы выполнить пункты 1 и 2. Ну и выложите наконец образ виртуальной машины с Tarantool на борту. Чтобы не тратить время на изучение Linux.
Потенциал Tarantool великолепный, но все развиваются. Не хочется чтобы очередной Российский проект ушел в свисток.

пока переходим на Redis!


четверг, 27 февраля 2014 г., 22:20:24 UTC+3 пользователь Konstantin Osipov написал:

Mister T

unread,
Apr 4, 2015, 5:15:39 AM4/4/15
to tarant...@googlegroups.com
Евгений, это опен-сорс. Если вам что-то нужно, то напишите это сами, или попробуйте написать (все схемы и протоколы известны и задокументированы). Например, клиентскую windows-программу для разработки процедур или net-библиотеку для доступа к tarantool. Ну или ждите, пока это напишут. А то получается, что вы укоряете сообщество энтузиастов в том, что они не исполняют ваши желания. Ну либо денег им дайте, я не знаю.
На всякий случай: это мое личное мнение, не сочтите его за "наезд", и я не знаю, что по этому поводу думают разработчики tarantool'а. Может mail.ru платит им деньги за то, чтобы коварно не поддерживать "большинство Windows разработчиков", дабы они уходили к божественному Redis'у.
Peace!

суббота, 4 апреля 2015 г., 10:07:53 UTC+3 пользователь Евгений Авдеев написал:

Dmitry E. Oboukhov

unread,
Apr 4, 2015, 5:33:57 AM4/4/15
to tarant...@googlegroups.com
> Спустя год после разговора о применении Tarantool для разработчиков Windows, в
> частности в АСУТП ничего не изменилось. А жаль.
> 1. Клиентской windows программы для разработки процедур, написания запросов -
> как не было, так и нет.
> 2. net библиотеки для доступа к tarantool из c# - как не было, так и нет.
> 3. Порта для windows сервера нет.

> Это не критика, это мнение со стороны. Пока вы не обратите внимание на
> разработчиков Windows а нас большинство. Tarantool так и останется
> малоизвестным
> решением, о котором никто не слышал (в отличие от Redis).
> Было бы не плохо хотя бы выполнить пункты 1 и 2. Ну и выложите наконец образ
> виртуальной машины с Tarantool на борту. Чтобы не тратить время на изучение
> Linux.
> Потенциал Tarantool великолепный, но все развиваются. Не хочется чтобы
> очередной Российский проект ушел в свисток.


Санкции на дворе.
в Крыму запретили использовать Apple store, скоро вашей Windows смогут
воспользоваться только представители пятой колонны, предоставившие
справку из АНБ США

--
_______________
< tarantool.org > Mail.RU
---------------
\ ^__^
\ (oo)\_______
(__)\ )\/\ Dmitry E. Oboukhov <un...@debian.org>
U ||----w | GPGKey: 1024D / F8E26537 2006-11-21
|| || 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537

signature.asc

Евгений Авдеев

unread,
Apr 4, 2015, 10:58:35 AM4/4/15
to tarant...@googlegroups.com
Я не укорял никого. Только высказал свое мнение. Что касается "...сами напишете..." - возможно что то сами бы и написали. Например удобный клиент для процедур и запросов. Не это проблема.Но для этого было бы не плохо иметь провайдера.
Проблема в том нет вообще ничего для сообщества разработчиков Net. Но писать вообще все - многовато. 
Кроме того mail.ru я так понимаю не общество энтузиастов. 

суббота, 4 апреля 2015 г., 13:15:39 UTC+4 пользователь Mister T написал:

Евгений Авдеев

unread,
Apr 4, 2015, 11:02:23 AM4/4/15
to tarant...@googlegroups.com, un...@tarantool.org
Все мы пользуемся достижениями загнивающего капитализма. То что Linux пользуется 5% пользователей не делает
его Российским ПО.

Dmitry E. Oboukhov

unread,
Apr 4, 2015, 1:27:54 PM4/4/15
to tarant...@googlegroups.com
> Все мы пользуемся достижениями загнивающего капитализма. То что Linux
> пользуется 5% пользователей не делает
> его Российским ПО.

дело не в Российскости, а свободности.
если эплстор могут запретить, а так же запретить поддержку Российским
банкам ихних баз данных типа оракла, то запретить использовать
свободные продукты не смогут.
поэтому банки переводят свое ПО ща на постгрис, а вы потихоньку
перелазьте с Windows на Linux ;)
signature.asc

Евгений Авдеев

unread,
Apr 4, 2015, 2:12:20 PM4/4/15
to tarant...@googlegroups.com, un...@tarantool.org
Мы это 5000 компов и специальное ПО которого нет и никогда не будет на Linux. Кроме того Windows это политика международной компании.
Потому даже чтобы поставить Linux сервер, надо долго обосновывать. 
Я уже не говорю что Linux обходится дороже в итоге чем платная винда. Плавали знаем. 
"Линуха" хороша ша WEB серверах. В промышленном производстве ей делать нечего.
Что касается свободы ПО - это максимализм свойственный молодости.1
Запретить могу что угодно и когда угодно. 


суббота, 4 апреля 2015 г., 21:27:54 UTC+4 пользователь Dmitry E. Oboukhov написал:

Konstantin Osipov

unread,
Apr 4, 2015, 3:31:36 PM4/4/15
to tarant...@googlegroups.com, un...@tarantool.org
* Евгений Авдеев <avv....@gmail.com> [15/04/04 21:40]:

Господа, давайте прекратим эту тему, она не относится к Тарантулу.

Евгений, год назад я Вам уже ответил, мне нечего добавить: Windows
port - работа на несколько месяцев, если Вашей компании нужен
порт, мы можем обсудить условия на sup...@tarantool.org.

Удачи с Redis на Windows.

> Мы это 5000 компов и специальное ПО которого нет и никогда не будет на
> Linux. Кроме того Windows это политика международной компании.
> Потому даже чтобы поставить Linux сервер, надо долго обосновывать.
> Я уже не говорю что Linux обходится дороже в итоге чем платная винда.
> Плавали знаем.
> "Линуха" хороша ша WEB серверах. В промышленном производстве ей делать
> нечего.
> Что касается свободы ПО - это максимализм свойственный молодости.1
> Запретить могу что угодно и когда угодно.

--
http://tarantool.org - a NoSQL database in a Lua script
Reply all
Reply to author
Forward
0 new messages