1

Идея на миллиард, по датчикам и отчетам и т.д.

Тема: Идея на миллиард, по датчикам и отчетам и т.д.

Господа! Глядя на постоянные муки с подбором наборов данных в таблицах и графиках, появилась идея предложить глобально переформатировать данное явление на Хостинге, притом таким образом, чтобы выборку данных можно было менять не через самописные модули, которые могут работать "поверх" веб-площадки, а собственно самим движком. И вот как я вижу эту реализацию.

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

Уверен, что у разработчиков уже накоплена информация по количеству машинного времени на каждый типа запроса, исходя допустим из максимального количества данных "разв секунду" в базах данных сброшенных с терминала, эти "веса" запросов по датчикам выглядеть могут  так:

Датчик топлива - 3 секунды на выборку за месяц;
Зажигание -1 секунда за месяц;
Время начальное произвольного датчика - 5 секунд выборка за месяц.

И есть критический предел вычислительного времени суммарно на обработку отчета, который формируется из суммы количества времен выборок по датчикам.

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

Для пользователя это может быть так в сервисе:

"Собери свою таблицу данных не превышая критический порог запросов 100%",  и идет набор запросов (всех) которые вообще могут быть в отчете:

$X - Датчик зажигания - 1%
$Y - Датчик другой 2 - 5%
$Z  - Время работы - 3 %
$W -Время начала работы датчика - 1%

и так далее все возможные обрабатываемые на текущий момент запросы, пользователь просто берет и набивает в колонки таблицы нужные ему переменные запросов данных не превышая критический порог (отображать набитую величину в %)

То-же самое может касаться и графиков, на текущий момент ограничение в графиках это унылая утопическая картина конца 19 века, уже трудно найти мониторинг где есть ограничения по количеству типов датчика в графике, но на Виалон они почему-то остались.

2

Идея на миллиард, по датчикам и отчетам и т.д.

Re: Идея на миллиард, по датчикам и отчетам и т.д.

Идея-то как идея, нормальная.

Но оно не так работает, как вы себе представляете. Это вычислительные кластеры и распределенные БД, там нет "типового времени на операцию", оно зависит от кучи различных параметров в широких пределах и прикинуть, как вы предлагаете, в принципе невозможно, картина мира иная.

3

Идея на миллиард, по датчикам и отчетам и т.д.

Re: Идея на миллиард, по датчикам и отчетам и т.д.

Нууу в целом я предложил шагать от "Максимума", могут ли в бд поступать от одного терминала данные чаще чем раз в 1 с ?

Или такой разрез вопроса, чем отличается внешний модуль, который также лезет в базу ковырять данные, и насколько я понял его можно сделать большим, то того же механизма внутри виалон? Только тем что если он подвиснет, то не положит сервер?

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

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

4

Идея на миллиард, по датчикам и отчетам и т.д.

Re: Идея на миллиард, по датчикам и отчетам и т.д.

24Glonass пишет:

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

Так они вроде периодически появлялись от интеграторов. Только что-то похоже ни один не выжил.

ООО "Ин-Тек"
https://in-tec.org
г. Екатеринбург (г. Березовский)
5

Идея на миллиард, по датчикам и отчетам и т.д.

Re: Идея на миллиард, по датчикам и отчетам и т.д.

Хотелось бы такой штуки от производителей..

6

Идея на миллиард, по датчикам и отчетам и т.д.

Re: Идея на миллиард, по датчикам и отчетам и т.д.

24Glonass и всем добрый добрый день.
Мысли интересные, полезные.

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

Но небольшой спойлер и, возможно, луч надежды : сейчас в проработке механизм, который позволил бы нам в отчетах обрабатывать не сообщения от объектов (тысячи и тысячи сообщений), а использовать уже заготовленные и "сложенные" так называемые события, которые хранят в себе определенные данные: превышения скорости, заправки, сливы и многое другое (т.е. для определения превышения скорости в отчетах не нужно будет перебирать множество сообщения, в базе данных будет храниться одно событие для одного превышения, которое и будет "вытягиваться" для отчета). Если все получится, то потенциально мы сможем строить отчеты на основе описанных событий, тем самым увеличивая скорость обработки данных и, как следствие, обрабатывать больше данных. И в ОЧЕНЬ отдаленной перспективе строить отчеты на событиях, формируя их каким угодно образом.

У нас нет ни сроков каких-то, ни точных планов, пока мы просто пробуем заглянуть в альтернативный мир и посмотреть, что из этого получится.

Maria Starikova,
Wialon Hosting Product manager, Gurtam
7

Идея на миллиард, по датчикам и отчетам и т.д.

Re: Идея на миллиард, по датчикам и отчетам и т.д.

А можно рассмотреть еще вариант с самостоятельным набором таблиц, но, допустим, не более 15 столбцов, чтобы был некий компромисс между возможностями сервера и нашими потребностями.  Или допустим всего 2-3 столбца можно было брать из другой таблицы. Вообще бы стало хорошо.

Тут надо нас хорош понять, мы не хотим впихнуть в таблицу 50 новых обработанных данных. обычно это буквально 1-2 столбца, допустим какой-то доп. датчик и его время или что-то еще.

8

Идея на миллиард, по датчикам и отчетам и т.д.

Re: Идея на миллиард, по датчикам и отчетам и т.д.

MyFly
эти два столбца могут быть в разных таблицах сейчас?

Maria Starikova,
Wialon Hosting Product manager, Gurtam
9

Идея на миллиард, по датчикам и отчетам и т.д.

Re: Идея на миллиард, по датчикам и отчетам и т.д.

Да, они в разных. Мы не можем использовать столбец времени  "Общее время" из раздела цифровых датчиков, в таблицу моточасов, чтобы абоненту было удобно видеть время от первого включения датчика до последнего,  туда можно вставить только только датчик полезной работы, а он калькулирует именно время работы датчика, но не интервал от первого до последнего включения.

Уже есть несколько абонентов которым бы это потребовалось