БД с возможностью синхронизации внутри локальной сети, если пропадает интернет?

Question

[Roman Kraev]

Есть 2+N устройств в локальной сети, каждый из них отправляет запрос через интернет в БД. Если интернет пропадает устройства ждут пока тот появиться чтобы через него синхронизировать свои данные с главной БД.
Есть БД для таких целей? Или инструменты передачи данных внутри локальной сети, если интернета нет, чтобы они могли контролировать дубликаты и сообщать об таких?
Устройства работают фактически параллельно с входящими данными, но время запроса и ответа через интернет в БД составляет меньше секунды. Но эта схема к сожалению не масштабируется.

Comments

[Roman Kraev]

Хм... попробую couchbase и что-то на sqllite, если получится, то отпишу.
Может из IoT есть решение?

Answer 1

[Владимир Коротенко]

master master, kiosk mode mssql, oracle .
Ну и вариант сохранять в приложении только словари из бд и строить записи для дальнейшей синхронизации

Answer 2

[Drno]

В БД же есть репликация...
поставьте в локальной сети БД и реплицируйте с основной через инет

Comments

[Roman Kraev]

Проблема с тем что с интернетом, он пропадает, и 2 устройства могут провести одну и туже запись 2 раза, а это значит что один реальный объект каким-то образом прошел через 2 устройства что критически недопустимо и если такое произошло то БД должка вывести ошибку.

[Drno]

Roman Kraev, мож я чего то не понял
если Вы ставите БД в локальной сети - причем тут интернет? с центральной базой уже отсинхронится потом, сами БД между собой

Если надо полностью автономный вариант - тогда выше был коммент, "строить" БД непосредственно на устройстве

[Roman Kraev]

Drno, Да не страшно уточнять. Может я плохо объясняю.
Есть главная БД, она в интернете, есть несколько локальных сетей и в каждой, есть несколько устройств, пока есть интернет, все хорошо, все устройства в главную БД отправляют запрос и редактируют состояние объекта. Если же 2е устройство в локальной сети решит тот же объект обработать, то на главной БД статус уже измениться и даже если будет одновременное обращение в порядке очереди обработается 1й запрос, 2й получит отказ.

Да же если исключить вариант с главной БД. То какие существуют БД или методы работы, чтобы между собой они могли синхронизировать работу. Если 1й обработал, то 2му сообщил об этом, и тот записал что объект уже обработан. при условии 2+N устройств.

[Drno]

Roman Kraev, я бы смотрел в сторону локальной БД на клиенте и настройки её в режим репликации с главной БД
Тогда клиенты всё обрабатывают локально, а в удаленную БД просто постепенно отправятся данные

Конкретнее я врят ли смогу подсказать

Answer 3

[rPman]

У тебя главная проблема возникает в момент одновременной работы с базой данных несколькими пользователями
Именно эту проблему нужно решать, и в общем случае это непростая задача, если нет сервера.

Держать копию базы данных на самом клиенте проблем не составит, инструменты есть как штатные у баз данных (репликация) так и средствами самого приложения

В качестве решения могу предложить следующее - установи в локальной сети полнофункциональную копию сервера (не только базу данных но и бакэнд), все клиенты из локальной сети работают либо с главным сервером либо с локальным, в этой схеме в момент появления связи, конфликтов в пределах пользователей локальной сети не будет (но возможны конфликты между удаленными пользователями и локальными)

p.s. один из вариантов решения проблемы - допустить конфликты в самой программе, т.е. вот у тебя форма редактирования объекта, если после предыдущего сеанса синхронизации базы появились конфликты, то интерфейс должен показывать это, давать возможность работать со всеми конфликтами и возможность их разруливать (объединение данных если было редактирование с выбором какие поля оставить а какие нет, сложнее со ссылкой на удаляемый объект, в таких случаях нужна возможность либо отменить удаление либо удалить связь с ним)

Вообще понятие 'конфликтное или неточное состояние' - нормальное, в разных системах это представляется по разному, например понятие 'черновик', или статус - принято/на рассмотрении, когда есть специальные люди, приводящие базу в консистентное состояние, и этот процесс непрерывный. Полноценная поддержка всех возможных конфликтов - мечта, так или иначе это реализуют поверх и удерживают способы в голове самих пользователей, ну к примеру в базе нет возможности указать что запись дубликат, на время пока этот дуп разруливается а его связи корректируются и переносятся на один объект, будущий удаляемый помечается как удаляемый через пометку в наименовании... т.е. база статуса на это не имеет но операторы друг с другом договариваются что такие объекты не использовать

Comments

[Roman Kraev]

Хороша идея, даже была попытка реализовать, но как в бизнесе, слишком дорого, да и еще одно место которое может отказать, да и админ нужен еще один на каждый такой сервер и т.д. А таких локальных сетей не 1шт. Да и для каждой новой сети делать сервер, то же не очень.

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

[rPman]

Roman Kraev, сервер на каждую локальную сеть (точнее на группы связности) - это для уменьшения конфликтов, у тебя выбора нет если железом проблему не решить