powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / NoSQL, Big Data [игнор отключен] [закрыт для гостей] / Выбор платформы - хранить и обрабатывать показания датчиков на заводе
25 сообщений из 27, страница 1 из 2
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39435420
vsivsi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
На заводе есть порядка 200 различных датчиков.
Примерно каждую секунду нужно сохранять показания этих датчиков (некоторые отдают данные только по событию - например, взвешивание сырья при поступлении на линию).
Хранить эти данные нужно несколько лет (вечно ??).

В режиме on-line нужно выводить некую агрегированную информацию в приложение (например, средние показатели за текущие сутки).
По требованию, нужно выполнять сложный анализ, как то: количество случаев повышения температуры больше 300 градусов на агрегате N за последние три года; общая масса сырья за последний год и прочий полет фантазии. Однако, результаты нужно получать практически мгновенно (насколько это возможно).

Как думаете, какая платформа лучше всего подойдет для этой задачи?
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39435423
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Практически любая. Те, у которых есть встроенный OLAP - попроще будут, к остальным придётся делать хранимые агрегаты ручками.
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39435437
Фотография Дедушка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vsivsiКак думаете, какая платформа лучше всего подойдет для этой задачи?та на которую у вас есть ресурсы и бюджет.
если это один админ-эникей и десятилетний компутер в углу бухгалтерии, то это одно
если есть бюджет для софта/железа и нанять 1-2 прогов для создания подобной системы конкретно под вас это другое
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39435451
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vsivsiНа заводе есть порядка 200 различных датчиков.
Примерно каждую секунду нужно сохранять показания этих датчиков (некоторые отдают данные только по событию - например, взвешивание сырья при поступлении на линию).
Хранить эти данные нужно несколько лет (вечно ??).

В режиме on-line нужно выводить некую агрегированную информацию в приложение (например, средние показатели за текущие сутки).
По требованию, нужно выполнять сложный анализ, как то: количество случаев повышения температуры больше 300 градусов на агрегате N за последние три года; общая масса сырья за последний год и прочий полет фантазии. Однако, результаты нужно получать практически мгновенно (насколько это возможно).

Как думаете, какая платформа лучше всего подойдет для этой задачи?
Готовая SCADA система с SQL хранением данных
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39438299
vsivsi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Спасибо всем за ответы.
Сейчас выбираем систему для хранения данных.

SiemarglГотовая SCADA система с SQL хранением данных

Потянет ли MySQL такую нагрузку, если данных накопится много? PostgreSQL?

Рассматриваем возможность использовать ClickHouse. Что скажете?

Также, звучали ElasticSearch, Prometheus.io, MongoDB.

Стоит ли искать что-либо еще, или выбирать из выше перечисленных?

Спасибо.
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39438324
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vsivsiСпасибо всем за ответы.
Сейчас выбираем систему для хранения данных.

SiemarglГотовая SCADA система с SQL хранением данных

Потянет ли MySQL такую нагрузку, если данных накопится много? PostgreSQL?

Рассматриваем возможность использовать ClickHouse. Что скажете?

Также, звучали ElasticSearch, Prometheus.io, MongoDB.

Стоит ли искать что-либо еще, или выбирать из выше перечисленных?

Спасибо.Прямо такие уникальные, а ведь есть системы и со 100тыс датчиков. И работают без всяких извращений.
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39438423
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Для начала поищите информацию как организовать шардинг в MySQL, сами перехочите. Плюс у него огромный оверхед при хранении данных по сравнению с той же MongoDB с WT.

В этом плане mongodb будет удобнее и надежнее. Да и при работе с большими данными Aggregation Framework + Map Reduce будут более практичны, чем SQL, ИМХО.

ClickHouse как я понял только яндекс продвигает и не факт, что послезавтра не закроют проект.
ElasticSearch я вообще не слышал, чтобы использовали как СУБД, хотя наверное всякое бывает.
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39438438
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vsivsiКак думаете, какая платформа лучше всего подойдет для этой задачи?Вот что выбрали ещё в 2011:
Часть 1
Часть 2

Здесь была бурная дисскусия вернее как обычно бесплодный срач на эту тему: 11183929

Если заинтересуетесь, то пишите сразу сюда: http://www.sql.ru/forum/cache
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39438441
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Uber использует Cassandra + ElasticSearch...

А кто-то использует Postgres, только разносит OLTP и OLAP по разным нодам.

Мне понравился доклад одних перцев про это.
Они не знали ни Postgres, ни потянет-ли он, но изначально организовали все грамотно с точки зрения DevOps.
В результате при росте приложения без отрыва от производства добавляли новые сервера и ноды под разные типы нагрузки.
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39438511
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANA,

это для 200 пользователей?
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39438557
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANA,

ага, помнится Uber колхозили СВОЙ шардинг на уровне приложения и на каждом углу кричали, что PosgreSQL фигня, а MySQL - наше всё. Я бы посомневался в адекватности их разработчиков.
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39438565
Фотография DirksDR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vsivsiПотянет ли MySQL такую нагрузку, если данных накопится много? PostgreSQL?

Рассматриваем возможность использовать ClickHouse. Что скажете?

Также, звучали ElasticSearch, Prometheus.io, MongoDB.

Стоит ли искать что-либо еще, или выбирать из выше перечисленных?
Поддержу servit-а, СУБД Cache хорошо зарекомендовала себя на данных АСУТП.
А еще на сочетании OLTP и OLAP в одном флаконе.
Если бы ты в профиле указал почту, выслал бы тебе описание своих экспериментов на эту тему.
Лицензий много не потребуется, сбор данных будут делать фоновые процессы, которые почти не лицензируются.
Если выбираете из совсем бесплатных, погугли "Time Series Database".
Слышал про успешное применение MySQL в таких задачах.
С тезисом, что " Map Reduce будут более практичны, чем SQL " для данной задачи категорически несогласен :)
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39438866
Acce_Ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DirksDR,

Извиняюсь, что вмешиваюсь. Вы бы не могли выложить результаты кратко в виде - столько-то данных опрошено, заняло столько времени. Построены такие-то агрегаты, заняло столько времени.
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39439004
Roman Kolchin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
vsivsiРассматриваем возможность использовать ClickHouse. Что скажете?
Основное ограничение КликХауса -- невозможность делать UPDATE и DELETE отдельных строк по ключу. Легко и просто работает только INSERT. Надо сказать, что разработчики КХ работают над возможностью обновления и удаления строк, но в любом случае это никогда не станет ключевой эффективной фичей.

КликХаус отлично подойдет чисто для аналитических агрегирующих запросов на чтение, когда результат представляет из себя небольшое кол-во строк, вычисленных из множество строк данных учета (соотношение порядка 1 строки результата, получаемый из 1 000 -> 1000 000 -> 1 000 000 000 строк данных). В своем основном сценарии использования КХ рвет абсолютно все опенсорcных конкурентов и большинство коммерческих.

Активная тусовка пользователей и разработчиков КликХауса в чате Телеграма (группа https://t.me/clickhouse_ru , уже 600 участников), попробуйте там задать свой вопрос.

HettClickHouse как я понял только яндекс продвигает и не факт, что послезавтра не закроют проект.
КликХаус, как и любой другой продукт, продвигают его разработчики. Это нормально. На КХ построена система Яндекс.Метрика, которая анализирует клики посетителей на сотнях тысяч сайтов практически в режиме реального времени. Ни куда она завтра вдруг не денется и с КХ тоже ничего не случится. Так что не надо зря пугать.
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39439765
Фотография DirksDR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Acce_EkbDirksDR,

Извиняюсь, что вмешиваюсь. Вы бы не могли выложить результаты кратко в виде - столько-то данных опрошено, заняло столько времени. Построены такие-то агрегаты, заняло столько времени.
На этом форуме много раз говорилось, что корректного сравнения систем не бывает.
Если настаиваете, то на моем офисном ПК получал скорость загрузки до 30 тыс. записей в сек.
Объем данных составил около 60% от исходного (Телескоп-4, MSSQL).
Аналитикой в смысле измерений и агрегатов не занимался.
Запрос сводной таблицы (Pivot) у меня сработал в 12 раз быстрее, чем на тех же данных в Oracle на приличном сервере.
Но структура моей базы была более подходящей для запроса, и, чтобы получить лучшее время, я написал небольшую программу на Cache Object Script.
Использовал "key-value" доступ к данным, вместо SQL. Структура данных типично АСУТП-ная: "объект-показатель-дата"="значение".
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39439989
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglskyANA,

это для 200 пользователей?У ТСа порядка 200 различных датчиков. При чем тут пользователи?
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39439990
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
HettskyANA,

ага, помнится Uber колхозили СВОЙ шардинг на уровне приложения и на каждом углу кричали, что PosgreSQL фигня, а MySQL - наше всё. Я бы посомневался в адекватности их разработчиков.
Начнём с того что в Uber несколько команд и сбором и обработкой метрик занимаются одни, а колхозами свой шардинг другие.
А теперь главный вопрос: чего Вы все про шардинг пишите? На каждый датчик по шарде предлагаете, или что? :)
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39439993
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторА теперь главный вопрос: чего Вы все про шардинг пишите? На каждый датчик по шарде предлагаете, или что? :)
А что, шардить можно только "по датчикам"?
Что ТСу делать, когда место на диске закончится, а у него в MySQL все лежит?
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39440015
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skyANASiemarglskyANA,

это для 200 пользователей?У ТСа порядка 200 различных датчиков. При чем тут пользователи?
Да нет у него нагрузки. 200TPS
Не хрен совать всякую муру вроде суперрешений. ЛЮБОЙ сервер справится
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39440029
Alexander Ryndin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglskyANAпропущено...
У ТСа порядка 200 различных датчиков. При чем тут пользователи?
Да нет у него нагрузки. 200TPS
Не хрен совать всякую муру вроде суперрешений. ЛЮБОЙ сервер справитсяУ него датчики!!! Обязательно нужно планировать базу данных на 10.000 серверов как у Google. А вдруг.
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39440073
Фотография DirksDR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
HettавторА теперь главный вопрос: чего Вы все про шардинг пишите? На каждый датчик по шарде предлагаете, или что? :)
А что, шардить можно только "по датчикам"?
Что ТСу делать, когда место на диске закончится, а у него в MySQL все лежит?
Подключить второй диск.
Неужели база MySQL не может состоять из нескольких файлов, а файлы лежать на разных дисках?
Немного арифметики: 200 датч * 86400 = 17 280 000 записей/сутки, или 6.3 млрд/год.
Немало, но я все равно не стал бы кластеры и шардинги городить.
Time Series Database хорошо сжимают такие данные, иногда на порядок.
Через год можно пересчитать средние за минуту значения, а посекундные данные удалить. (или скинуть в архив для вечного хранения).
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39440171
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglskyANAпропущено...
У ТСа порядка 200 различных датчиков. При чем тут пользователи?
Да нет у него нагрузки. 200TPS
Не хрен совать всякую муру вроде суперрешений. ЛЮБОЙ сервер справится
Тут для начала надо уточнить "200 различных датчиков" - это ровно 200 датчиков, или 200 типов датчиков :)
Ну и как много операторов сидит в режиме online, и как часто необходимо выполнять сложный анализ и получать результаты практически мгновенно.

Если, как Вы утверждаете, нет у ТС такой нагрузки, то возникает вопрос: а на фига вообще что-то делать? :)
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39440173
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
HettавторА теперь главный вопрос: чего Вы все про шардинг пишите? На каждый датчик по шарде предлагаете, или что? :)
А что, шардить можно только "по датчикам"?
Что ТСу делать, когда место на диске закончится, а у него в MySQL все лежит?
Нет конечно. Но зачем вообще тут что-то шардить? По какому ключу?

А вот фантазировать про то что место закончится, не зная о том, какого типа данные пишут датчики, не стоит :)
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39440473
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Microsoft StreamInsight
...
Рейтинг: 0 / 0
Выбор платформы - хранить и обрабатывать показания датчиков на заводе
    #39441128
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
КритикMicrosoft StreamInsightСудя по рассматриваемому ТС'ом выше списку, предпочтение отдаётся (только) бесплатным решениям.
...
Рейтинг: 0 / 0
25 сообщений из 27, страница 1 из 2
Форумы / NoSQL, Big Data [игнор отключен] [закрыт для гостей] / Выбор платформы - хранить и обрабатывать показания датчиков на заводе
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]