Распознавание тут ни при чем — в данном случае просто проверка на похожесть по шаблону. Сейчас уже есть отдельные модули, совместимые с тем же Arduino.
Сугубо персонально. Давеча оставляли у меня кошку: просто поставил открытый пакет с кормом с безлимитным интернетом доступом, и она когда хотела подходила и ела. За две недели не особо много и убавилось.
А вот в детстве была кошка, которая скорее бы лопнула, чем оставила еду.
Для мониторинга, как мне кажется, одно- и двух-байтных значений в большинстве случаев достаточно, значащих цифр в метриках не так много.
Почему то все сразу мыслят глобально: если база данных, так надо поддерживать тысячи, а лучше миллионы строк в секунду. Для маркетинга циферки конечно нужные — продать «серьезный» продукт видимо проще.
P.S. Проверил SQLite на массовую вставку: добавление 100К записей занимаем ~60сек, т.е. скорость ~1.5К строк/сек (с pragma synchronous = 0). В статьях встречаются цифры 70К строк/сек, но там и железо и ОС другие. При увеличении количества столбцов скорость упала совсем незначительно, что для велосипеда отрадно.
Согласен, что time-series базы для мониторинга предпочтительнее, просто пока выбор так-себе. Тот же Influx еще в процессе. В целом мне не очень понятно почему у них такой объем на точку выходит: казалось бы фиксируем тип float (4 байта) и пишем последовательно. При фиксированном промежутке между измерениями даже дату рядом со значением хранить не надо.
На небольших объемах (скажем до 100-300 устройств) SQLite с описанной выше оптимизацией, должен вполне справляться, по моим прикидкам. На практике, надо будет проверять.
SQLite может хранить 1-4байта (в зависимости от типа и величины) на числовое значение. Это дело можно еще пожать: отказаться от rowid (минус 64-байта со строки) и результат опроса хранить как строку, с одной датой, т.е. не как обычно: "время + значение1", "время + значение2" и так далее, а "время + значение1, значение2 и далее", сэкономив по 4байта на каждой паре, кроме первой.
Эпоксилин приклеивается так себе, да и результат весьма хрупок на маленьких объемах.
Можно использовать Poxipol, который продается в авто-магазинах. Это что-то среднее между супер-клеем и эпоксилином. Для мелких деталей тоже не очень.
Альтернатив несколько больше чем описано в обзоре (в частности нет PRTG и The Dude), что впрочем не остановило меня от написания еще одной с максимально упрощенным интерфейсом, возможностью опроса устройств несколькими методами (от SNMP до опроса портов) и просмотра истории сгруппированной по типам устройств/узлов.
function test () { setTimeout(function () { throw new Error('MyError'); }, 100); } try { test(); } catch (err) { console.error('Request boom! ', err); }интернетомдоступом, и она когда хотела подходила и ела. За две недели не особо много и убавилось.А вот в детстве была кошка, которая скорее бы лопнула, чем оставила еду.
Для мониторинга, как мне кажется, одно- и двух-байтных значений в большинстве случаев достаточно, значащих цифр в метриках не так много.
Почему то все сразу мыслят глобально: если база данных, так надо поддерживать тысячи, а лучше миллионы строк в секунду. Для маркетинга циферки конечно нужные — продать «серьезный» продукт видимо проще.
P.S. Проверил SQLite на массовую вставку: добавление 100К записей занимаем ~60сек, т.е. скорость ~1.5К строк/сек (с pragma synchronous = 0). В статьях встречаются цифры 70К строк/сек, но там и железо и ОС другие. При увеличении количества столбцов скорость упала совсем незначительно, что для велосипеда отрадно.
На небольших объемах (скажем до 100-300 устройств) SQLite с описанной выше оптимизацией, должен вполне справляться, по моим прикидкам. На практике, надо будет проверять.
Можно использовать Poxipol, который продается в авто-магазинах. Это что-то среднее между супер-клеем и эпоксилином. Для мелких деталей тоже не очень.
Демка, следящая за стендовым оборудованием.