|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
На заводе есть порядка 200 различных датчиков. Примерно каждую секунду нужно сохранять показания этих датчиков (некоторые отдают данные только по событию - например, взвешивание сырья при поступлении на линию). Хранить эти данные нужно несколько лет (вечно ??). В режиме on-line нужно выводить некую агрегированную информацию в приложение (например, средние показатели за текущие сутки). По требованию, нужно выполнять сложный анализ, как то: количество случаев повышения температуры больше 300 градусов на агрегате N за последние три года; общая масса сырья за последний год и прочий полет фантазии. Однако, результаты нужно получать практически мгновенно (насколько это возможно). Как думаете, какая платформа лучше всего подойдет для этой задачи? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2017, 13:29 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
Практически любая. Те, у которых есть встроенный OLAP - попроще будут, к остальным придётся делать хранимые агрегаты ручками. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2017, 13:33 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
vsivsiКак думаете, какая платформа лучше всего подойдет для этой задачи?та на которую у вас есть ресурсы и бюджет. если это один админ-эникей и десятилетний компутер в углу бухгалтерии, то это одно если есть бюджет для софта/железа и нанять 1-2 прогов для создания подобной системы конкретно под вас это другое ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2017, 13:53 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
vsivsiНа заводе есть порядка 200 различных датчиков. Примерно каждую секунду нужно сохранять показания этих датчиков (некоторые отдают данные только по событию - например, взвешивание сырья при поступлении на линию). Хранить эти данные нужно несколько лет (вечно ??). В режиме on-line нужно выводить некую агрегированную информацию в приложение (например, средние показатели за текущие сутки). По требованию, нужно выполнять сложный анализ, как то: количество случаев повышения температуры больше 300 градусов на агрегате N за последние три года; общая масса сырья за последний год и прочий полет фантазии. Однако, результаты нужно получать практически мгновенно (насколько это возможно). Как думаете, какая платформа лучше всего подойдет для этой задачи? Готовая SCADA система с SQL хранением данных ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2017, 15:18 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
Спасибо всем за ответы. Сейчас выбираем систему для хранения данных. SiemarglГотовая SCADA система с SQL хранением данных Потянет ли MySQL такую нагрузку, если данных накопится много? PostgreSQL? Рассматриваем возможность использовать ClickHouse. Что скажете? Также, звучали ElasticSearch, Prometheus.io, MongoDB. Стоит ли искать что-либо еще, или выбирать из выше перечисленных? Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2017, 22:22 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
vsivsiСпасибо всем за ответы. Сейчас выбираем систему для хранения данных. SiemarglГотовая SCADA система с SQL хранением данных Потянет ли MySQL такую нагрузку, если данных накопится много? PostgreSQL? Рассматриваем возможность использовать ClickHouse. Что скажете? Также, звучали ElasticSearch, Prometheus.io, MongoDB. Стоит ли искать что-либо еще, или выбирать из выше перечисленных? Спасибо.Прямо такие уникальные, а ведь есть системы и со 100тыс датчиков. И работают без всяких извращений. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2017, 23:42 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
Для начала поищите информацию как организовать шардинг в MySQL, сами перехочите. Плюс у него огромный оверхед при хранении данных по сравнению с той же MongoDB с WT. В этом плане mongodb будет удобнее и надежнее. Да и при работе с большими данными Aggregation Framework + Map Reduce будут более практичны, чем SQL, ИМХО. ClickHouse как я понял только яндекс продвигает и не факт, что послезавтра не закроют проект. ElasticSearch я вообще не слышал, чтобы использовали как СУБД, хотя наверное всякое бывает. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2017, 08:37 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
vsivsiКак думаете, какая платформа лучше всего подойдет для этой задачи?Вот что выбрали ещё в 2011: Часть 1 Часть 2 Здесь была бурная дисскусия вернее как обычно бесплодный срач на эту тему: 11183929 Если заинтересуетесь, то пишите сразу сюда: http://www.sql.ru/forum/cache ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2017, 09:00 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
Uber использует Cassandra + ElasticSearch... А кто-то использует Postgres, только разносит OLTP и OLAP по разным нодам. Мне понравился доклад одних перцев про это. Они не знали ни Postgres, ни потянет-ли он, но изначально организовали все грамотно с точки зрения DevOps. В результате при росте приложения без отрыва от производства добавляли новые сервера и ноды под разные типы нагрузки. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2017, 09:03 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
skyANA, это для 200 пользователей? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2017, 10:25 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
skyANA, ага, помнится Uber колхозили СВОЙ шардинг на уровне приложения и на каждом углу кричали, что PosgreSQL фигня, а MySQL - наше всё. Я бы посомневался в адекватности их разработчиков. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2017, 11:13 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
vsivsiПотянет ли MySQL такую нагрузку, если данных накопится много? PostgreSQL? Рассматриваем возможность использовать ClickHouse. Что скажете? Также, звучали ElasticSearch, Prometheus.io, MongoDB. Стоит ли искать что-либо еще, или выбирать из выше перечисленных? Поддержу servit-а, СУБД Cache хорошо зарекомендовала себя на данных АСУТП. А еще на сочетании OLTP и OLAP в одном флаконе. Если бы ты в профиле указал почту, выслал бы тебе описание своих экспериментов на эту тему. Лицензий много не потребуется, сбор данных будут делать фоновые процессы, которые почти не лицензируются. Если выбираете из совсем бесплатных, погугли "Time Series Database". Слышал про успешное применение MySQL в таких задачах. С тезисом, что " Map Reduce будут более практичны, чем SQL " для данной задачи категорически несогласен :) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2017, 11:20 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
DirksDR, Извиняюсь, что вмешиваюсь. Вы бы не могли выложить результаты кратко в виде - столько-то данных опрошено, заняло столько времени. Построены такие-то агрегаты, заняло столько времени. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2017, 16:45 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
vsivsiРассматриваем возможность использовать ClickHouse. Что скажете? Основное ограничение КликХауса -- невозможность делать UPDATE и DELETE отдельных строк по ключу. Легко и просто работает только INSERT. Надо сказать, что разработчики КХ работают над возможностью обновления и удаления строк, но в любом случае это никогда не станет ключевой эффективной фичей. КликХаус отлично подойдет чисто для аналитических агрегирующих запросов на чтение, когда результат представляет из себя небольшое кол-во строк, вычисленных из множество строк данных учета (соотношение порядка 1 строки результата, получаемый из 1 000 -> 1000 000 -> 1 000 000 000 строк данных). В своем основном сценарии использования КХ рвет абсолютно все опенсорcных конкурентов и большинство коммерческих. Активная тусовка пользователей и разработчиков КликХауса в чате Телеграма (группа https://t.me/clickhouse_ru , уже 600 участников), попробуйте там задать свой вопрос. HettClickHouse как я понял только яндекс продвигает и не факт, что послезавтра не закроют проект. КликХаус, как и любой другой продукт, продвигают его разработчики. Это нормально. На КХ построена система Яндекс.Метрика, которая анализирует клики посетителей на сотнях тысяч сайтов практически в режиме реального времени. Ни куда она завтра вдруг не денется и с КХ тоже ничего не случится. Так что не надо зря пугать. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2017, 22:32 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
Acce_EkbDirksDR, Извиняюсь, что вмешиваюсь. Вы бы не могли выложить результаты кратко в виде - столько-то данных опрошено, заняло столько времени. Построены такие-то агрегаты, заняло столько времени. На этом форуме много раз говорилось, что корректного сравнения систем не бывает. Если настаиваете, то на моем офисном ПК получал скорость загрузки до 30 тыс. записей в сек. Объем данных составил около 60% от исходного (Телескоп-4, MSSQL). Аналитикой в смысле измерений и агрегатов не занимался. Запрос сводной таблицы (Pivot) у меня сработал в 12 раз быстрее, чем на тех же данных в Oracle на приличном сервере. Но структура моей базы была более подходящей для запроса, и, чтобы получить лучшее время, я написал небольшую программу на Cache Object Script. Использовал "key-value" доступ к данным, вместо SQL. Структура данных типично АСУТП-ная: "объект-показатель-дата"="значение". ... |
|||
:
Нравится:
Не нравится:
|
|||
17.04.2017, 17:05 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
SiemarglskyANA, это для 200 пользователей?У ТСа порядка 200 различных датчиков. При чем тут пользователи? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2017, 09:34 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
HettskyANA, ага, помнится Uber колхозили СВОЙ шардинг на уровне приложения и на каждом углу кричали, что PosgreSQL фигня, а MySQL - наше всё. Я бы посомневался в адекватности их разработчиков. Начнём с того что в Uber несколько команд и сбором и обработкой метрик занимаются одни, а колхозами свой шардинг другие. А теперь главный вопрос: чего Вы все про шардинг пишите? На каждый датчик по шарде предлагаете, или что? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2017, 09:38 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
авторА теперь главный вопрос: чего Вы все про шардинг пишите? На каждый датчик по шарде предлагаете, или что? :) А что, шардить можно только "по датчикам"? Что ТСу делать, когда место на диске закончится, а у него в MySQL все лежит? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2017, 09:40 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
skyANASiemarglskyANA, это для 200 пользователей?У ТСа порядка 200 различных датчиков. При чем тут пользователи? Да нет у него нагрузки. 200TPS Не хрен совать всякую муру вроде суперрешений. ЛЮБОЙ сервер справится ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2017, 09:59 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
SiemarglskyANAпропущено... У ТСа порядка 200 различных датчиков. При чем тут пользователи? Да нет у него нагрузки. 200TPS Не хрен совать всякую муру вроде суперрешений. ЛЮБОЙ сервер справитсяУ него датчики!!! Обязательно нужно планировать базу данных на 10.000 серверов как у Google. А вдруг. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2017, 10:14 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
HettавторА теперь главный вопрос: чего Вы все про шардинг пишите? На каждый датчик по шарде предлагаете, или что? :) А что, шардить можно только "по датчикам"? Что ТСу делать, когда место на диске закончится, а у него в MySQL все лежит? Подключить второй диск. Неужели база MySQL не может состоять из нескольких файлов, а файлы лежать на разных дисках? Немного арифметики: 200 датч * 86400 = 17 280 000 записей/сутки, или 6.3 млрд/год. Немало, но я все равно не стал бы кластеры и шардинги городить. Time Series Database хорошо сжимают такие данные, иногда на порядок. Через год можно пересчитать средние за минуту значения, а посекундные данные удалить. (или скинуть в архив для вечного хранения). ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2017, 11:11 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
SiemarglskyANAпропущено... У ТСа порядка 200 различных датчиков. При чем тут пользователи? Да нет у него нагрузки. 200TPS Не хрен совать всякую муру вроде суперрешений. ЛЮБОЙ сервер справится Тут для начала надо уточнить "200 различных датчиков" - это ровно 200 датчиков, или 200 типов датчиков :) Ну и как много операторов сидит в режиме online, и как часто необходимо выполнять сложный анализ и получать результаты практически мгновенно. Если, как Вы утверждаете, нет у ТС такой нагрузки, то возникает вопрос: а на фига вообще что-то делать? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2017, 12:59 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
HettавторА теперь главный вопрос: чего Вы все про шардинг пишите? На каждый датчик по шарде предлагаете, или что? :) А что, шардить можно только "по датчикам"? Что ТСу делать, когда место на диске закончится, а у него в MySQL все лежит? Нет конечно. Но зачем вообще тут что-то шардить? По какому ключу? А вот фантазировать про то что место закончится, не зная о том, какого типа данные пишут датчики, не стоит :) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2017, 13:02 |
|
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
|
|||
---|---|---|---|
#18+
Microsoft StreamInsight ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2017, 20:14 |
|
|
start [/forum/topic.php?fid=48&fpage=5&tid=1856695]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
46ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 332ms |
total: | 476ms |
0 / 0 |