Pull to refresh

Comments 16

Она должна синхронизировать данные между IoT-устройствами

а какое расстояние должно быть между девайсами? По идее 2км было бы идеально.
Зависит от сети, т.е. все ограничения имеют физический характер.
«за основу взята платформа Intel Edison, так как она поддерживает многие архитектуры, в том числе MIPS и ARM» звучит неправильно, т.к. Intel Edison == x86 модификация, никаким RISC там не пахнет.
Я бы рекомендовал изменить формулировку, чтобы не вводить в заблуждение.
Я также портировал все функции из API libmosquitto. Посмотреть на результат можно здесь. По ссылке дан пример использования. Все что нужно сделать для сбора данных со всех устройств внутри mesh network — это вызвать функцию subscribe() из определенного места и опубликовать метод get()!

Судя по коду вы не портировали libmosquitto, а написали wrapper для lua.

Именно портировал под tarantool. Попробую рассказать в чем отличие, отличие в том, что у tarantool есть свой собственный i/o loop, если библиотека имеет i/o и работает вне i/o loop tarantool, то такая библиотека будет блокировать работу во время I/O операций.

Другими словами, это не просто wrapper. Посмотрите внимательно на код, он в open-source.
А вот и код интеграции в I/O loop tarantool: https://github.com/tarantool/mqtt/blob/master/mqtt/driver.c#L61 Этот код не совместим с обычной lua.

Вопрос про репликацию: какбы понятны доводы в пользу использования её, но а минусов совсем что ли нет? Частая проблема когда репликация «рвётся» приходиться же потом её восстанавливать руками, например в MySQL, да и в других субд, думаю, также или в тарантуле с этим не так?

Восстанавливать ее не надо. Допустим. У нас прервался коннект — связь потеряна, то механизм репликации _должен_ восстановить работу при возобновлении связи. Если механизм этого не делает, то это очень странно :)

В Tarantool за этим следить не надо, я не знаю MySQL, но думаю, там тоже как-то обрабатывается (по аналогии с PG и т.п.).

он то есть "механизм", но он может не сработать, если не понятно что стало "мастером", если скажем с момента разрыва мастер-мастер репликации между двумя бд, данные поменялись в обеих бд

Ааа… понял!

Да такое может случиться — назовем это конфликтом. Конфликт можно обойти добавляя некий UUID, как уникальный PK к каждой записи. Вообще существует много вариантов как это обойти, все не перечислить, да и каждый из вариантов будет заточен под данные.
Чтобы было понятно (про уникальный UUID или отказ от уникальных индексов): при M-M репликации (да и не только) на всех узлах хранится LSN (по сути время последнего изменения), merge LSN — не проблема, проблема — слить данные, которые конфликтуют.

Это да, но я не много другом, самом крайнем варианте так сказать: как быть, если изменения были в обеих в БД, в одинаковых записях с одинаковым ID?


Например, допустим, Вы выставляете в "главной" БД (допустим это один из "мастеров" с админкой) отключить устройство, которое сошло с ума и спамит, и связь в этот момент оборвалась. Данные(скажем флаг вкл/выкл) о том, что устройство должно перестать посылать данные не прилетят на это устройство, в добавок оно же само у себя обновит какие-то данные и будет считать, что его данные более актуальны,
будет как минимум "странная" ситуация и как максимум репликация оборвётся, если это было те же записи"/"строки".


Однако, наверное, если грамотно разграничить в архитектуре БД данные, то такого не произойдёт…

> Однако, наверное, если грамотно разграничить в архитектуре БД данные, то такого не произойдёт…
Верно.

Либо реализовать логику разучивание конфликтов — что == создать репликацию с 0.
Подскажите, пожалуйста, ссылку на подробную инструкцию по установке из исходников Tarantool на ARM
Готовой сборки пакетов пока нет (собрать можно ручками — это просто).
PS написал в личку свои контакты.
Sign up to leave a comment.