company_banner
1 марта в 12:25

Что такое платформа Tarantool IIoT?

image


Недавно в пресс-релизе мы рассказали о том, что запустили Tarantool IIoT — платформу для промышленного интернета вещей. Новость облетела многие электронные издания. Но что такое Tarantool IIoT и как он работает — тема оставалась не до конца раскрытой. Мы решили это исправить. Подробности под катом.


А что вообще такое IIoT?


Сначала я напомню, что IIoT — это industrial internet of things (промышленный интернет вещей). Это такая концепция, когда у объектов промышленности появляется доступ в интернет как в сеть и доступ к интернет-сервисам (которые работают в центрах обработки данных — ЦОДах). Давайте посмотрим на рисунок:


image


Что мы тут видим? Рисунок поделен на две части — «центр» и «на местах».


«Центр» — это ЦОД или облако, т. е. любой облачный IaaS-сервис, в котором можно разворачивать IT-инфраструктуру: Amazon, Azure и т. д.


«На местах» — я, если честно, не знаю, какой правильный термин тут использовать. Уверен, читатели меня поправят и предложат красивое определение. Я лучше расскажу, что имею в виду под «на местах»: в поле (в прямом смысле слова — на агрокультурном поле), на производственной площадке (на заводе, фабрике, металлообрабатывающих, горнодобывающих и нефтегазовых объектах), на ремонтной площадке, на транспорте (в автомобиле, грузовике, ж/д вагоне, локомотиве), на объектах городской инфраструктуры (в местах сбора информации о потреблении электричества и воды, в канализации, вдоль улиц, в объектах освещения), на объектах междугородной инфраструктуры (вдоль шоссе, железных дорог, возможно, линий электропередач). В общем, «на местах» — это везде, куда рука интернета только начинает добираться. Еще можно сказать «в поле», но тогда появляется риск сузить круг промышленного интернета вещей только до агрокультурного поля.


А что такое Tarantool IIoT? Какие проблемы он призван решать?


Tarantool IIoT — это распределенная софтверная платформа для сбора информации с датчиков и отправки ее в центр и на локальные системы управления. Tarantool IIoT работает и «в центре», и «на местах», соединяя их в единую информационную сеть. В этой сети максимум логики унесено в софт, поэтому с точки зрения железа она может быть собрана из commodity-компонентов, т. е. не нуждается в специальных поставщиках закрытых проприетарных программно-аппаратных платформ. Стало понятнее? Если нет, то читайте дальше :-)


Под commodity-компонентами имеются в виду легко заменяемые дешевые компоненты. Например, если мы вспомним дата-центры, то с точки зрения их железа commodity — это недорогие серверы, например supermicro или даже полностью самосборные серверы. С точки зрения железа «на местах» это могут быть самые дешевые датчики и IoT-хабы (т. е. маленькие компьютеры на основе ARM).


Внутри своих дата-центров в Mail.Ru Group мы уже достаточно давно почти полностью перешли на commodity-железо. Иногда без фирменной брендовой гарантии и саппорта, зато недорогое и взаимозаменяемое. При этом надежность и производительность обеспечиваются на уровне софта. Если что-то ломается, то это не критично для сервисов, потому что все задублировано и зареплицировано на уровне софта — мы просто спокойно отправляем железо в ремонт. Сроки и вообще возможность починки железа не влияют на непрерывность бизнеса. По такому же пути давно прошли крупные американские IT-корпорации: вся сложность переносится на софт, при этом железо максимально стандартизируется и удешевляется. И теперь мы предлагаем распространить этот подход и на мир IoT.


Спрашивается, зачем места и центр соединять в единую информационную сеть? Ответ такой:


  1. На местах есть источники информации (о температуре, вибрации, геопозиции, влажности, напряжении, давлении и т. д.). Эту информацию хорошо бы собирать, агрегировать и передавать в центр для аналитики, чтобы потом делать выводы о количестве и точках потерь при производстве продукции, потреблении сырья и топлива, эффективности работы на местах, периодах обслуживания, вероятности поломки станков и приборов и пр.
  2. На местах есть инфраструктура, которой иногда удобно управлять из центра, в том числе на основе ранее полученной аналитики. Управлять означает посылать из центра на места команды (вызывать API), которые будут активировать (выключать, включать, уменьшать, увеличивать, замедлять, ускорять) локальные объекты. На мой взгляд, пока рано говорить о полном и повсеместном управлении производством из центра (никто не хочет, чтобы из-за зависшего сетевого соединения упал 15-тонный пресс), но многие некритичные вещи можно делать. Например, если на основе анализа данных от датчиков вибрации оборудования стало ясно, что оборудование скоро выйдет из строя, то можно отправить из центра на завод команду, которая зажжет красную мигающую лампочку (да-да, именно так: если пушнуть это событие на планшет местному работнику, то он его попросту не заметит, ведь будет занят). Увидев мигание лампочки, сотрудники остановят сломанный станок и закажут досрочное проведение технического обслуживания.

На местах, как вы понимаете, есть своя специфика, отличная от ЦОДа. Оговорюсь сразу, что мы в Mail.Ru Group только в начале пути развития своей IIoT-стратегии и не так давно прощупываем рынок IIoT, поэтому, возможно, пока не до конца понимаем все тонкости. Вот что мы сейчас думаем о специфике. Это:


  • огромные площади (возьмите средней руки завод — по площади он может в сотни раз превосходить даже большой дата-центр);
  • суровые условия (жар, холод, влажность);
  • повышенный риск повреждения объектов IT-инфраструктуры;
  • высокая стоимость замены объектов IT-инфраструктуры (добраться в поле за тысячу верст по бездорожью и объехать там сотню квадратных километров — это вам не в ЦОД в Москве смотаться);
  • внешняя по отношению к IT-инфраструктуре информация, которую нужно собирать с помощью датчиков температуры, влажности, плотности, геопозиции, веса, напряжения и т. д.

Что вся эта специфика означает? Что мы не можем строить на заводах, полях, кораблях, городских улицах и прочих объектах то, что мы строим в ЦОДах: ряды одинаковых стоек с серверами внутри, скоммутированные через оптоволокно. Это будет безумно дорого.


А что мы еще не можем? В мире IoT роль серверов играют IoT Hubs — микрокомпьютеры (промышленные аналоги Raspberry PI), которые разбросаны на многих километрах площадок. Между ними оптоволокно тянуть — дорого. И в стойки собирать их тоже дорого, потому что из-за огромных расстояний IoT Hubs слишком много, и предприятия, ограниченные финансово, не могут формировать локальные кластеры из большого количества IoT Hubs. То есть нет локализованных стоек. Есть разбросанное по местности железо. Далее, у предприятий/объектов есть миллионы разбросанных повсюду датчиков (см. выше, о каких датчиках речь), с которых IoT Hubs собирают информацию. Опять же — как ее собирать? Если датчиков мало, то по проводам. А если их миллион, то через радиоканалы (миллион проводов, по проводу от датчика — представляете, какой клубок?).


В итоге, чтобы решение было более-менее cost-effective, вся эта конструкция может выглядеть вот так:


image


Датчики собирают информацию и отправляют ее на хабы (это не сетевые хабы, просто называются так же: это микрокомпьютеры с маленькой материнкой, процем, памятью и операционкой), хабы передают информацию в интернет (через мобильную связь, Wi-Fi, спутниковую связь, Ethernet и т.п.), и она долетает до ЦОДа. Ровно так же путешествует обратный поток — из ЦОДа на хабы, с хабов на датчики (или на локальные программируемые логические контроллеры).


Идем далее. Еще помните о специфике мира IIoT? Чтобы вся эта конструкция не стоила космических денег, хочется, чтобы:


  • IoT Hubs состояли из потенциально заменяемого железа, это снизит вероятность vendor lock-in и цену железа, которого нужно ой как много из-за огромных расстояний;
  • поверх была открытая операционка (например, разновидность Linux — OpenWrt);
  • вся логика взаимодействия с любыми видами датчиков и разбором их протоколов ушла на уровень софта поверх операционки (чтобы не зависеть от дорогих черных брендовых ящиков);
  • вся логика отправки сигналов в сторону датчиков и оборудования также ушла на уровень локального софта на IoT Hub, а не была захардкожена в вендорских железных коробках (имеется в виду логика обработки, а не физическая передача данных);
  • софт, работающий на IoT Hubs, был очень быстрый. IoT Hubs медленные, а медленные, потому что дешевые, а дешевые, потому что их надо очень много, а очень много надо из-за специфики (см. выше). А еще вспомните про специфику в виде жары-холода-влажности-вибрации, т. е. этим хабам нужны специальные корпуса. А цену-то наращивать нельзя. Значит, надо делать техническую начинку еще дешевле, стало быть, еще медленнее. Представляете, как быстро должен шуршать софт, чтобы дебет с кредитом сходился?

То есть хорошо бы, иными словами, иметь то, что мы привыкли видеть в ЦОДах: заменяемое недорогое железо, вся логика на уровне софта и весь fault-tolerance на уровне софта.


А теперь давайте обратим взгляд на софт в ЦОДе. Там, кроме операционки, почти всегда используется много других компонентов — СУБД, серверы приложений, системы мониторинга, DevOps-скрипты и системы. И уже поверх этой инфраструктуры пишется бизнес-логика. По-хорошему, вся описанная инфраструктура конфигурируется так, чтобы автоматически (ну или полуавтоматически) брать на себя основные проблемы сбоев на стороне железа (переключать нагрузку на реплику базы данных, если мастер-копия недоступна, распределять нагрузку между несколькими нодами серверов приложений, автоматом наливать чистую машину, которая подключена в кластер, и т. д.).


То есть появилось несколько специализаций. Разработчики бизнес-логики (продуктовые разработчики), по-хорошему, думают в основном о бизнес-логике и фокусируются на бизнес-проблемах. А еще имеются инженеры и разработчики остальной, огромной подводной части айсберга — DevOps, системные администраторы, разработчики СУБД, разработчики серверов приложений, систем мониторинга и других (назовем их инфраструктурными) компонентов.


Вот бы и на местах так было. Круто же? Вот бы разработка на IoT Hubs была такой же специализированной.


Tarantool IIoT — под капотом


И тут мы плавно подходим к Tarantool IIoT. Я не скажу, что он призван заменить всю вышеуказанную инфраструктуру на IoT Hubs, но он может сделать это частично. Посмотрите на рисунок:


image


Tarantool IIoT — это обычный Tarantool, но собранный и оттестированный под ARM и под x86 (версия для MIPS сейчас создается). Кроме того, внутрь него встроена автоматическая поддержка протоколов MQTT и MRAA — это основные протоколы для работы с датчиками. Tarantool IIoT инсталлируется непосредственно на IoT Hubs. Еще можно тут добавить, что для передачи данных между датчиками и хабом (на схеме «на местах») нужно специальное оборудование LORA или 6LoWPAN. Что, казалось бы, плохо (помните, мы не хотим уникальных вендорских коробок). Но вся соль в том, что это оборудование не обязано понимать протоколы множества датчиков. Его задача — только завернуть протокол в понятный для хаба протокол (обычно это наш любимый старый добрый TCP/IP). Весь остальной разбор можно делать на Tarantool IIoT с помощью скриптов, которые работают прямо на IoT Hub.


В этом преимущества программной платформы над железной — любое оборудование и любые протоколы можно поддержать самостоятельно, без вендора. Технические детали, как это все устроено и как программируется с помощью Tarantool, можно почитать в статье «Master-master репликация и масштабирование приложений между всеми IoT-устройствами и облаком».


Во всем остальном Tarantool IIoT — это полнофункциональный Tarantool, т. е. СУБД со встроенным сервером приложений, синхронным логом транзакций, репликацией между узлами, двумя движками (in-memory — memtx и on-disk — vinyl), хранимыми процедурами, асинхронными джобами, поддержкой очередей и прочими пирогами.


Что Tarantool IIoT дает разработчику?


Tarantool IIoT инсталлируется на IoT Hubs. Что это дает?


  1. На Tarantool IIoT можно писать скрипты, которые принимают информацию с датчиков, парсят ее и сохраняют в локальную базу данных прямо внутри Tarantool IIoT (она персистится на флеш-памяти IoT хаба).
  2. Информация, сохраненная на IoT Hub, локально реплицируется между несколькими IoT Hub для надежности (чтобы вся система продолжала работать даже после выхода одного или нескольких хабов из строя). Репликация у Tarantool есть сразу из коробки, т. е. не надо писать свою систему очередей. Вот тут, кстати, важный момент: Tarantool — это не только сервер приложений, но и СУБД. А значит, в нем можно персистить данные и реплицировать данные между узлами. Очень важные свойства в свете сказанного выше. И очень важно, что оно работает из коробки и протестировано годами (ибо ядро Tarantool ровно такое же, как и для обычных не IoT сервисов).
  3. Информация, сохраненная на IoT-хабах, реплицируется в ЦОД встроенными средствами Tarantool. Причем только та ее часть или агрегация, которую вы хотите реплицировать (настройка программируется и работает прямо на IoT Hub).
  4. Можно автоматом загружать код и хранимые процедуры в Тарантулы на местах, т. е. менять логику локальной агрегации из ЦОДа (т. е. отовсюду, откуда есть доступ в ЦОД: из офиса или из дома через VPN) без выезда на места.
  5. Можно по одной кнопке из ЦОДа (а значит, и из веб-интерфейса, доступ к которому есть у авторизованных людей с любого устройства из любой точки мира) менять степень детализации доставки информации в центр, при этом локально, на местах, получать столько информации, сколько надо, и обрабатывать ее без передачи в ЦОД.

Как итог — продуктовый разработчик получает шажок в сторону той степени комфорта, которая присутствует при создании софта, работающего в ЦОДе. Не приходится думать о том, что каналы между хабами локально и между хабом и ЦОДом ненадежны и рвутся: репликация все равно доставит данные в обе стороны без потерь и без задвоения. У разработчика меньше болит голова о клиент-серверной архитектуре, о файликах, о потере данных, о выходе из строя хабов — все это хендлит Tarantool IIoT ровно так же, как это происходит в ЦОДе при использовании обычного Tarantool. Разработчик может больше сконцентрироваться на бизнес-логике.


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


По сути, Tarantool IIoT — это полностью программируемая открытая платформа, которая позволяет не только разрабатывать приложения под IIoT на локальных устройствах (без выезда на места!), но и переносить best practices из ЦОДа на IoT-устройства на местах.


И еще эта платформа развязывает вам руки в том смысле, в котором производители оборудования вам их ранее связали. Например, у вас уже есть готовая и работающая железная IoT-инфраструктура, которая автоматом доставляет все из датчиков в ЦОД. Вы закупили новую партию более дешевых датчиков, которые не поддерживаются вашим текущим оборудованием. Вам придется валяться в ногах у вендора оборудования, чтобы он за большие деньги внес туда изменения. Ну или просто закупить новую версию оборудования. Или отказаться от дешевых датчиков. И все эти изменения — железные, не софтверные, т. е. с downtime, выездом на места, монтажом и прочими неприятностями.


С помощью Tarantool IIoT же можно без проблем получать данные с этих новых дешевых датчиков, парсить их и далее выдавать в ваше оборудование или в локальный софт в нужном формате. Без downtime и без больших затрат.


Понятно, что самого по себе Tarantool IIoT мало. Для полного комфорта нужны и остальные инфраструктурные системы — мониторинг, удаленный апгрейд софта (тот же Tarantool надо апгрейдить), автоматическая наливка Linux и прочие радости. Но, как нам кажется, это уже шаг в нужном направлении.


Почему вообще Tarantool IIoT, а не $любая_другая_технология IIoT?


В заключение я хочу рассказать, почему в качестве основы для нашего IIoT-продукта мы взяли именно Tarantool. Давайте на секунду вернемся к специфике IoT Hubs: у этих устройств медленные процессоры с малым количеством ядер (обычно одно-два ядра), мало оперативной памяти, мало флеш-памяти, которая к тому же медленная и ненадежная. Почему? Устройства должны быть очень дешевыми (ценовой диапазон приблизительно такой: 30—100 долларов), потому что их очень много, потому что инфраструктура разбросана на многие километры — и еще по ряду причин, см. выше. Помните, я говорил о специфике? От нее не уйти. Это с одной стороны. А с другой стороны, датчики генерируют огромное количество информации (с одного датчика могут поступать десятки и сотни параметров в секунду, а количество датчиков на хаб иногда исчисляется сотнями и тысячами). Всю информацию надо успевать обрабатывать, несмотря на жесткие условия и не очень быстрое оборудование.


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


И в условиях всех этих ограничений Tarantool на наших тестах показал лучшие результаты. Ближайшим конкурентом по скорости может быть Redis (с CouchBase и Aerospike, к сожалению, у нас ничего не получилось: они очень медленные на одноядерных машинах, но, возможно, мы просто не умеем их готовить). Главные минусы Redis с точки зрения применимости в IoT: в нем недостаточно развит сервер приложений, нет хранимых процедур (и нельзя в рантайме обновлять код внутри СУБД), нет джобов, нет мастер-мастер репликации, нет транзакций — больше вероятность потери данных. Плюс непонятно, планируют ли авторы продукта вообще развиваться в эту сторону. Вот тут пример сравнения двух продуктов: Tarantool vs Redis. Связка Python и Redis может в каком-то смысле заменить Tarantool, но по скорости, скорее всего, сильно проиграет. Сразу оговорюсь — сравнительных тестов пока нет, плюс мы рекомендуем скорость работы сравнивать в каждом случае, case by case.


Еще один важный нюанс: на IoT-девайсах, когда СУБД и сервер приложений объединены (а в Tarantool они объединены и работают в одном процессе), накладных расходов на их общение друг с другом, очевидно, будет сильно меньше (вот тут о накладных расходах, которые огромны даже при взаимодействии с быстрыми СУБД: Asynchronous processing with in-memory databases or how to handle one million transactions per second on a single CPU core). При этом любые накладные расходы на передачу информации между разными процессами получаются очень большими в свете невысокой производительности устройств и огромного количества информации, которую нужно обрабатывать.


Еще есть такая неплохая штука — SQLite, он хороший и быстрый, но, к сожалению, у него нет репликации и сервера приложений из коробки — т. е. поверх него надо еще поплясать с бубном. Остальные традиционные СУБД (не буду называть, тут большой список уважаемых продуктов, все их прекрасно знают) у нас просто не завелись нормально на маленьких железочках IoT или даже близко не справились с той нагрузкой, которая идет от датчиков. Однако если у вас есть положительный опыт применения других СУБД на IoT-девайсах, то мы будем рады, если вы поделитесь им!


Это все, что я хотел рассказать о Tarantool IIoT. У нас уже в процессе пилоты с различными производственными, транспортными и другими компаниями. Как только будет продакшн, мы обязательно про это детально напишем. Следите за новостями!

Автор: @danikin
Mail.Ru Group
рейтинг 573,05
Строим Интернет

Комментарии (44)

  • 0
    Это все замечательно, но все портит досутп в интернет. Если это не изолированная от веба сеть, то всегда есть не нулевой риск, что датчики начнут слать недостоверную инфу.
    • 0
      Ну так для этого хаб с Tarantool на нем и существует — он общается с интернетом по защищенному протоколу (SSL) и он является открытым решением. Т.е. вы всегда можете залезть на него (если железка под вашим контролем) и посмотреть на код, который на нем исполняется (в том смысле, чтобы убедиться, что кто-то физически не подменил железку или не залил туда свой код, обладая физическим доступом).
      • 0
        Соглашусь по поводу интернета. Если вспомнить сколько нашли дыр, за последнее время, в реализациях протоколов шифрования, то доступ в интернет — это потенциальная головная боль с обновлением сертификатов\прошивок\дыр. И не нулевая вероятность в компрометации устройств(вспоминаем ботнеты из домашних роутеров).
        • +1
          И на эту угрозу есть ответ. Tarantool IIoT может работать полностью без интернета. Все локально. Единственное, что придется софт тоже на нем обновлять с выездом на месте, но тут уж как говорится или шашечки или ехать. Если же не страшно организовать локальный интранет, то из локального интранетовского веб-интерфейса можно полностью управлять локальным кластером ARM-устройств с Тарантулом, в том числе заливать на них код, менять конфигурацию и тд.
          • 0
            А вот это уже убивает смысл самой затеи. Представьте себе огромный агрохолдинг, с полями, амбарами, парками техники, мельницами и прочее-прочеее-прочее по всей стране. Занести это в локальный интранет? тянуть све оптоволокно везде? просто нереально. А через общедоступные сети ненадежно. Идея хороша, при условии что вы осознаете риски.
            • 0
              Зачем? Радиоканалов навтыкать. Если вы считаете, что радиосигнал перехватывается и SSL расшифровывается, то в провод ровно также делается врезка.
              • 0
                Вы кажется начинаете понимать) Получается что собранная этой системой инфа не является 100% достоверной… чтото решать на базе этой информации можно, но нужно понимать последсвия
                • +2
                  Я даже больше вам скажу — весь IIoT в принципе не имеет права на жизнь. Никакую инфрастркутуру нельзя разворачивать в полях, на заводах, коряблях. Кто угодно может врезаться в провода и в радиосингал, и далее расшифровать все секьюрные протоколы. Добро пожаловать обратно теплые ламповые 60ые.
            • 0
              Обычно делают intranet поверх internet
  • +1
    Спасибо за статью. Позвольте вопрос: у вас наверняка есть прога которая работает в центре и агрегирует данные из хабов. Например вы хотите посмотреть какие датчики висят на хабе А, а какие на хабе Б. И вы наверное хотите также посмотреть из центра что показывают эти датчики. А еще вы должны как то регистрировать новый хаб в своей системе. Вообще количество задач, которые должен решать софт в центре безграничен. Можно узнать подробности про этот софт, который крутится у вас в центре?
    • 0
      Софт в центре в смысле как облачный сервис — пока в процессе разработки. Про это будет отдельный пост, когда запустим. Пока мы лишь предлагаем брать наш Tarantool и ставить его самому в центр и на устройства (ну или привлекая нас в качестве профессиональных консалтеров), и далее создавать конктертно на ваших железках и в вашем ДЦ конкретное решение вашей задачи. Сервис же, повторюсь, который будет шарить как сервера в центре так и железки (такой большое IIoT облако) пока в процессе.
      • 0
        я сейчас работаю над подобным проектом, поэтому мой интерес довольно конкретный. Без софта в центре ваше решение лишь одно из многих.По крайней мере это так выглядит на первый взгляд. Например, почему я должен взять именно тарантул а не google things? Или например не OpenHub?
        • 0
          Потому что Tarantool — это не просто сервер приложений, это еще и СУБД. Вы можете данные доставлять в центр автоматом через механизм репликации (не надо полагаться на очереди и другие специальные решения). И потому что вы можете на местах реплицировать данные между хабами и делать отказоучтойчивость там, где нет доступа в Интернет и не хочется выезжать на место и чинить/менять/переконфигурять хаб каждый раз, когда он сломается.
  • 0
    Всем хорош тарантул, с моей любовью к луа так вообще. Вот только на MIPS не работает :(
    • 0
      Мы планируем это досадное недоразумение устранить. Ждите обновлений! :-)
      • 0
        Ох, уже пол-года жду.
  • 0
    Правильно ли я понимаю, что в центре у вас тоже тарантул крутится и он получает данные с хабов через механизм репликаций?
    • 0
      Да. Хотя можно и по другому — можно с локального Тарантула в центр передавать данные по любому протоколу (в т.ч. MQTT) в любую систему — как запрограммируешь.
  • 0
    есть ли возможность управления устройств подключенных к хабу посредством правил, как это например сделано в OpneHub? Пример: к хабу подключен датчик температуры и помпа. Если датчик сказал, что температура воздуха ниже нуля, то помпу надо отключить. И это правило должно крутится именно на хабе, т.к. помпу надо отключать не зависимо от наличия коннекта с центром.
    • 0
      Можно даже круче. Можно запускать локально на хабе скрипты (любую программную логику). Т.е. прямо в скрипте говорите что-то типа if (temperature < 0) { pump.turn_off(); }
      (это псевдокод, понятно, что надо еще температуру получить с датчика и далее послать сигнал обратно на выключение помпы)
      • 0
        где можно посмотреть пример? Хотелось бы поставить на Rasberry и попробовать. Есть такая возможность?
        • 0
          С этим пока туго. Мы работаем в основном с интерпрайзами, для всех делаем все индивидуально. Документация и примеры для всех скоро будут. Пока можете почитать эту статью: https://habrahabr.ru/company/mailru/blog/320878/. Плюс, я сейчас попросил одного из наших парней написать вам в личку. Он поможет. Кроме того, добро пожаловать в общий телеграм-чат по Tarantool: https://telegram.me/tarantoolru. Можете прямо там задавать любые вопросы.
  • 0
    Как обстоят дела с Security? Как хаб узнает что ему прислали приказ из вашего центра а не из Африки?
    • 0
      SSL, аутентификация. К тому же, я написал уже выше, можно делать локально. Но раз такой вопрос возникает уже дважды, позвольте полюбопытствовать, может быть вы в курсе, какие есть серебряные пули у других систем на этот счет?
      • –1
        нет, к сожалению у меня нет ответа на этот вопрос. Поэтому и интересуюсь. Как известно в IoT S означает Security.
    • 0
      С этим все хорошо (есть прав пользователей, соль в протоколе https://tarantool.org/doc/dev_guide/internals_index.html).
      Так же можно все это пустить через ssl туннель.
  • 0
    Каким образом отражены устройства в вашем софте в центре? Например я хочу видеть все данные с датчиков температуры в радиусе 10 км от города М. Как я получу список всех датчиков определенного типа? Как я получу данные о датчиках вообще, например я хочу видеть все датчики от сименс.
    • 0
      Вы должны поставить достаточное количество хабов с лорой1 внутри или другой подобной системой, которая умеет собирать с датчиков радиосигнал и транслировать его в TCP/IP. Все данные слетаются на хабы. Хабы можно скомутировать в локальный интранет или подключить к интернету. С точки зрения софта (Tarantool IIoT) это не важно — софт будет видеть датчики в радиусе своей лоры и будет реплицировать всю информацию между всем локальными хабами. Таким образом вы получаете несколько локальных копий всей инфы с датчиков. Дальше уже вопрос техники — пишите скрипт или джоб внутри Тарантула, который как угодно эту инфу фильтрует, если надо сохраняет в других таблицах, которые реплицируются с центром или если не надо, то принимает решения локально и выдает сигналы на другие системы, на какие вы хотите в соответствии с вашей бизнес-логикой.
  • 0
    есть ли эта статья на английском?
    • 0
      В процессе перевода. Это тот случай, когда я сначала на русском решил написать :-) А кому бы вы хотели показать ее?
      • 0
        шефу. Не очень хочется ему самому обьяснять о чем речь.
        • 0
          Я вас понял. Статья в переводе. Дайте пару дней еще. Как будет опубликована — вы узнаете, я ссылки везде размножу :-)
  • +2
    А еще мне интересно, что такое LORA1? Ну, т.е. я знаю, что такое LoRa. А откуда там 1?
    • 0
      Да то же самое, в принципе, https://www.google.ru/search?q=lora+one&oq=lora+one&aqs=chrome..69i57.1171j0j7&sourceid=chrome&ie=UTF-8#newwindow=1&q=loraone&*
      • 0
        Т.е. это не LORA1, а lora one?
        • 0
          Да. Но, на самом деле, надо заменить просто на LORA, чтобы не было вопросов. Спасибо, что обратили внимание!
          • 0
            А что вы тогда имели ввиду под Lora one? Старую отладочную платку с кикстартера за 80 евро?
            • 0
              1/one надо было убрать. Оно прицепилось после хакатона, на котором мы это использовали. Еще раз повторюсь, спасибо за очень существенный комментарий.
              • 0
                Вы использовали на хакатоне Lora one? Странно, когда я там был, мне казалось, что использовались устройства от Unwired Devices и не Lora, а 6lowpan. Или вы про какой-то другой хакатон?
                • 0
                  Вам бы следователем работать :) Мы планировали использовать различные штуки. Остановились на 6lowpan от Unwired Devices.
  • 0

    Можете сравнить ваше решение с инфраструктурой influxdata?

    • 0
      Они как очередь для доставки данных. Но не для их локальной быстрой обработки на хабах. В отличие от Tarantool IIoT. И я не уверен, что они нормально работаю на хабах. На их сайте этот раздел 404: http://influxdata.wpengine.com/testimonials/#iot-sensor-data
  • 0

    Немного не по теме вопрос. Насколько хорошо Тарантул подходит для хранения "больших" записей (например, картинок в hex-кодировке)? Есть смысл рассматривать его на замену Кассандре?

    • 0
      Вполне. Только надо использовать дисковвый движок vinyl для этого.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка