Не совсем ясно, о чем все таки статья. То ли о том, как кодить бота телеграмма, то ли о том, как пользоваться сервисами яндекса. Опять же, если это "защищеная инфраструктура", то отправлять уведомления о работе серверов через яндекс - странно. Если не настолько защищенная - то можно админов попросить прокидывать конкретный url для бота "наружу". Или в зоне сети с доступом в интернет поднять свой smtp-сервер, в котором будет сразу реализована логика отправки сообщений для бота. Соответственно, исключая любых посредников, например в лице сервисов Яндекса с различными ограничениями и оплатой...
А вот поиск у нас в эластике.)
Для неё флаговое перечисление сериализуется в коллекцию значений. Причём значения хранятся не в интах, а в строковых значениях типа keyword. Это обеспечивает и читабельность, и отсутствие кореляций с другими значениями перечесления, если б хранились в интах.
Соответственно, поисковый фильтр формируется для указания наличия (или отсутствия) конкретных значений в коллекции.
Мы пошли другим путем. Булевые флаги перевели в флаговое перечисление. В БД — инты.
Всё отлично индексируется и работает.
Безусловно, в бд данные не читабельные, но в коде — все супер.
Не совсем в тему, но.
Мы в проекте переносим всякие выборки из слона в эластику. То есть, слон используется как хранилище, которое много что умеет. Типа работы с json и т.д. И в нем выборка, в основном, идёт по ключам. Все остальное — только в эластике.
Конечно, благо, пока никаких агрегаций нет. Но, думаю, эластика справится.)
А какова частота дискретизации измеряемых сигналов и квантования сигнала?
Вопрос к тому, что, непосредственно снятие значений — один малый модуль. С очень простой железной начинкой. Если взять, положим, дискретизация 2 кГц и квантование в 2 байта на 6 параметров (3 фазы => напряжение + ток) + 2 байта на ID устройства, то получается около 200 кБит/с. Вполне средняя пропускная способность шины CAN (если задуматься о помехозащищенности каналов связи возле электромашины). Либо сразу по IEEE 802 отправлять.
А математика (спектр, очистка от шумов, построение тенденций) — на серверах.
Кодить математику проще и приятнее на «большой» машине, нежели в микроконтроллере.
Мне видится, что комплектность оборудования (один комплект на одну электромашину) зажата для повышения доходности системы диагностики.
Не вижу проблемы для сбора данных на один сервер и обсчета данных у на нем.
Результат диагностики, как таковой, не требуется непосредственно в текущем времени. Его можно безболезненно получить и через час.
Хороший вопрос.
А ещё, случаем, не ли такой кучи ограничений, как в Sql Server.
Типа нельзя сделать для таблицы с identity действие insert… select…
И т.д.
Не совсем ясно, о чем все таки статья. То ли о том, как кодить бота телеграмма, то ли о том, как пользоваться сервисами яндекса.
Опять же, если это "защищеная инфраструктура", то отправлять уведомления о работе серверов через яндекс - странно.
Если не настолько защищенная - то можно админов попросить прокидывать конкретный url для бота "наружу".
Или в зоне сети с доступом в интернет поднять свой smtp-сервер, в котором будет сразу реализована логика отправки сообщений для бота. Соответственно, исключая любых посредников, например в лице сервисов Яндекса с различными ограничениями и оплатой...
А вот поиск у нас в эластике.)
Для неё флаговое перечисление сериализуется в коллекцию значений. Причём значения хранятся не в интах, а в строковых значениях типа keyword. Это обеспечивает и читабельность, и отсутствие кореляций с другими значениями перечесления, если б хранились в интах.
Соответственно, поисковый фильтр формируется для указания наличия (или отсутствия) конкретных значений в коллекции.
В базе только по ключам что-то берётся.
Мы пошли другим путем. Булевые флаги перевели в флаговое перечисление. В БД — инты.
Всё отлично индексируется и работает.
Безусловно, в бд данные не читабельные, но в коде — все супер.
Не совсем в тему, но.
Мы в проекте переносим всякие выборки из слона в эластику. То есть, слон используется как хранилище, которое много что умеет. Типа работы с json и т.д. И в нем выборка, в основном, идёт по ключам. Все остальное — только в эластике.
Конечно, благо, пока никаких агрегаций нет. Но, думаю, эластика справится.)
Вопрос к тому, что, непосредственно снятие значений — один малый модуль. С очень простой железной начинкой. Если взять, положим, дискретизация 2 кГц и квантование в 2 байта на 6 параметров (3 фазы => напряжение + ток) + 2 байта на ID устройства, то получается около 200 кБит/с. Вполне средняя пропускная способность шины CAN (если задуматься о помехозащищенности каналов связи возле электромашины). Либо сразу по IEEE 802 отправлять.
А математика (спектр, очистка от шумов, построение тенденций) — на серверах.
Кодить математику проще и приятнее на «большой» машине, нежели в микроконтроллере.
Мне видится, что комплектность оборудования (один комплект на одну электромашину) зажата для повышения доходности системы диагностики.
Не вижу проблемы для сбора данных на один сервер и обсчета данных у на нем.
Результат диагностики, как таковой, не требуется непосредственно в текущем времени. Его можно безболезненно получить и через час.
Хороший вопрос.
А ещё, случаем, не ли такой кучи ограничений, как в Sql Server.
Типа нельзя сделать для таблицы с identity действие insert… select…
И т.д.