danikin
0
Вы имеете в виду пройтись по логу, понять, какие таблицы затронуты, далее считать эти таблицы из снэпшота, применить к каждой из них лог? Ну или распишите ваш алгоритм подробнее. Пока мне кажется, что ваш вариант будет в худшем случае O(N) по памяти, что есть явное ухудшение текущей ситуации, поэтому ответ на ваше «почему нельзя» такой — потому что это потребляет больше памяти.

«либо как вариант процессу шарить конкретно по диску и писать в необходимые файлы пришедшие данные» — это не понял вообще, сорри.
danikin
0
Если речь идет о репликации на другой сервер, то через лог транзакций
danikin
0
«Интересная задача, у меня вопрос, почему нельзя использовать отдельный процесс, который бы работал с копией базы на диске и применял к ней лог транзакций?» — применять как? Загрузить всю базу еще раз в память, удвоив количество необходимой памяти, применив логи и сохранив в новый файл? Поделитесь алгоритмом применения, если не сложно, чтобы он был линейный по времени исполнения и меньше чем линейный по дополнительной памяти. Заранее спасибо.
danikin
+3
Запилите то же самое через Message Queues, выложите в продакшн, пустите нагрузку от реальных пользователей. И дальше мы с удовольствием почитаем на Хабре про ваш опыт.
danikin
+1
Ну тут дело вкуса уже. Кому то ОК, чтобы был SQL, но без нормального персистенса, а кому то наоборот.
danikin
+1
Ну вот видимо в этом и кроется ответ. Одно дело — СУБД с родным логом и пирогами. Другое тело — набор заготовок и напильник к ним.
danikin
+1
Ну это же не запись в свой родной лог транзакций, это запись в другую СУБД. Что тут же делает работу игнайта на запись не быстрее чем эта СУБД. Плюс, в случае разрыва сети возможны повторные записи (в СУБД запись прошла, сеть порвалась, игнайт про это не узнал — сделал ритрай, получили повторную запись
danikin
+2
А у Игнайта уже есть синхронная запись на диск всех изменений перед ответом пользователю на транзакцию?
danikin
0
Ну те, возвращаясь к вопросу, проблема не в компиляторе и -O3, а в бусте
danikin
0
Вполне. Только надо использовать дисковвый движок vinyl для этого.
danikin
0
Вам бы следователем работать :) Мы планировали использовать различные штуки. Остановились на 6lowpan от Unwired Devices.
danikin
0
1/one надо было убрать. Оно прицепилось после хакатона, на котором мы это использовали. Еще раз повторюсь, спасибо за очень существенный комментарий.
danikin
0
Да. Но, на самом деле, надо заменить просто на LORA, чтобы не было вопросов. Спасибо, что обратили внимание!
danikin
0
Они как очередь для доставки данных. Но не для их локальной быстрой обработки на хабах. В отличие от Tarantool IIoT. И я не уверен, что они нормально работаю на хабах. На их сайте этот раздел 404: http://influxdata.wpengine.com/testimonials/#iot-sensor-data
danikin
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&*
danikin
0
Я вас понял. Статья в переводе. Дайте пару дней еще. Как будет опубликована — вы узнаете, я ссылки везде размножу :-)
danikin
0
В процессе перевода. Это тот случай, когда я сначала на русском решил написать :-) А кому бы вы хотели показать ее?
danikin
0
Вы должны поставить достаточное количество хабов с лорой1 внутри или другой подобной системой, которая умеет собирать с датчиков радиосигнал и транслировать его в TCP/IP. Все данные слетаются на хабы. Хабы можно скомутировать в локальный интранет или подключить к интернету. С точки зрения софта (Tarantool IIoT) это не важно — софт будет видеть датчики в радиусе своей лоры и будет реплицировать всю информацию между всем локальными хабами. Таким образом вы получаете несколько локальных копий всей инфы с датчиков. Дальше уже вопрос техники — пишите скрипт или джоб внутри Тарантула, который как угодно эту инфу фильтрует, если надо сохраняет в других таблицах, которые реплицируются с центром или если не надо, то принимает решения локально и выдает сигналы на другие системы, на какие вы хотите в соответствии с вашей бизнес-логикой.
danikin
0
SSL, аутентификация. К тому же, я написал уже выше, можно делать локально. Но раз такой вопрос возникает уже дважды, позвольте полюбопытствовать, может быть вы в курсе, какие есть серебряные пули у других систем на этот счет?
danikin
0
С этим пока туго. Мы работаем в основном с интерпрайзами, для всех делаем все индивидуально. Документация и примеры для всех скоро будут. Пока можете почитать эту статью: https://habrahabr.ru/company/mailru/blog/320878/. Плюс, я сейчас попросил одного из наших парней написать вам в личку. Он поможет. Кроме того, добро пожаловать в общий телеграм-чат по Tarantool: https://telegram.me/tarantoolru. Можете прямо там задавать любые вопросы.
danikin
0
Можно даже круче. Можно запускать локально на хабе скрипты (любую программную логику). Т.е. прямо в скрипте говорите что-то типа if (temperature < 0) { pump.turn_off(); }
(это псевдокод, понятно, что надо еще температуру получить с датчика и далее послать сигнал обратно на выключение помпы)
danikin
0
Да. Хотя можно и по другому — можно с локального Тарантула в центр передавать данные по любому протоколу (в т.ч. MQTT) в любую систему — как запрограммируешь.
danikin
+2
Я даже больше вам скажу — весь IIoT в принципе не имеет права на жизнь. Никакую инфрастркутуру нельзя разворачивать в полях, на заводах, коряблях. Кто угодно может врезаться в провода и в радиосингал, и далее расшифровать все секьюрные протоколы. Добро пожаловать обратно теплые ламповые 60ые.
danikin
0
Мы планируем это досадное недоразумение устранить. Ждите обновлений! :-)
danikin
0
Потому что Tarantool — это не просто сервер приложений, это еще и СУБД. Вы можете данные доставлять в центр автоматом через механизм репликации (не надо полагаться на очереди и другие специальные решения). И потому что вы можете на местах реплицировать данные между хабами и делать отказоучтойчивость там, где нет доступа в Интернет и не хочется выезжать на место и чинить/менять/переконфигурять хаб каждый раз, когда он сломается.
danikin
0
Софт в центре в смысле как облачный сервис — пока в процессе разработки. Про это будет отдельный пост, когда запустим. Пока мы лишь предлагаем брать наш Tarantool и ставить его самому в центр и на устройства (ну или привлекая нас в качестве профессиональных консалтеров), и далее создавать конктертно на ваших железках и в вашем ДЦ конкретное решение вашей задачи. Сервис же, повторюсь, который будет шарить как сервера в центре так и железки (такой большое IIoT облако) пока в процессе.
danikin
0
Зачем? Радиоканалов навтыкать. Если вы считаете, что радиосигнал перехватывается и SSL расшифровывается, то в провод ровно также делается врезка.
danikin
+1
И на эту угрозу есть ответ. Tarantool IIoT может работать полностью без интернета. Все локально. Единственное, что придется софт тоже на нем обновлять с выездом на месте, но тут уж как говорится или шашечки или ехать. Если же не страшно организовать локальный интранет, то из локального интранетовского веб-интерфейса можно полностью управлять локальным кластером ARM-устройств с Тарантулом, в том числе заливать на них код, менять конфигурацию и тд.
danikin
0
Ну так для этого хаб с Tarantool на нем и существует — он общается с интернетом по защищенному протоколу (SSL) и он является открытым решением. Т.е. вы всегда можете залезть на него (если железка под вашим контролем) и посмотреть на код, который на нем исполняется (в том смысле, чтобы убедиться, что кто-то физически не подменил железку или не залил туда свой код, обладая физическим доступом).
danikin
0
1. А зачем использовать в виде индекса дерево (O(log(N)), если и хэш (O(1)) подходит? В Tarantool специально для этого есть разные виды индексов — TREE и HASH.

2. Это обман оптимизатора. Чтобы он по честному прошел весь цикл. Важно, что там внутри цикла есть как минимум одно обращение по индексу. Моделируем SIZE обращений по индексу.

3. https://habrahabr.ru/company/mailru/blog/317274/#comment_9959174
danikin
+1
Про Транзакции почитайте тут: http://kostja.github.io/misc/2017/01/24/tarantool-design-principles.html и тут: https://tarantool.org/doc/book/box/atomic.html

По поводу второго вашего вопроса — правильно понимаете. Но скорее всего у вас нет и не будет таких нагрузок, чтобы одна машина с Тарантулом не справилась. Даже у мейла редко бывают такие нагрузки — и мы ставим 4 машины, шардим на уровне приложения и это работает на долгие годы впероед.
danikin
+1
ACID обеспечивает. SQL в процессе. Если интересен недекларативный язык запросов, то это Lua, работает в виде хранимых процедур внутри Tarantool.
danikin
+1
В базе все пишется внутри на Lua. Вы лукапите в один индекс, находите поле, далее по этому полю лукапите в другой индекс. Все занимает как два обращения по индексу. По времени — плюс-минус как два раза в std::unordered_map сходить в терминах С++ + накладные расходы на сетевой вызов.
danikin
0
«Обычно в таких случаях я локализовывал проблему до минимальной программы, на которой она воспроизводится, т.е. откусывал от нее куски «методом половинного деления», пока не оставалась минимальная по размеру программа, в которой устойчиво воспроизводилась проблема.» — до какой программы вы в итоге дошли?
danikin
+1
Более менее простые. Или выборки/обновления по первичному/вторичному индексу или Lua-код из, условно, 5-10 строчек, внутри которого один-два подобных запроса.
danikin
+1
Мы пока размышляем на эту тему. Как вариант предлагаем вам попробовать написать на Lua прямо внутри Tarantool, используя его не только как СУБД, но и как сервер приложений.
danikin
0
Но нужна сначала регистрация на сайте. Я дам знать, когда она откроется