Одна большая центральная БД и много мелких с частичной репликацией, какие варианты?
Здравствуйте.
Такую задачу можно решить программным путем. Но интересно, есть ли готовые варианты на уровне СУБД или модулей для каких либо СУБД (не важно SQL или NoSQL). Вопрос из области "поиск альтернатив, вдруг есть лучше".
Суть такая, центральная БД хранит много-много данных. Данные однотипные, но данные одного приложения в нескольких отдельных таблицах/коллекциях, относящихся только к этому приложению. Запущено много контейнеров или удаленных клиентов, где есть маленькая БД, хранящая в себе только данные этого клиента. Необходимо синхронизировать изменения в данных, причем как сделанных на стороне клиента, так и на стороне центральной БД.
Если кто сталкивался с подобной задачей, будет интересно хотя бы намек, как решено. Или видел описание в какой-то СУБД.
Так никто не делает. Надо садиться, разбирать по коробочкам продукт и строить нормальное решение. В такой формулировке запрос является полнейшей дикостью
Роман Мирр, о, точно... Читал про Filtered replication, причем там есть еще PouchDB в качестве встраиваемой БД, и с CouchDB репликация чуть ли не на уровне движка.. Спасибо.
но данные одного приложения в нескольких отдельных таблицах/коллекциях, относящихся только к этому приложению.
Если я верно понял, то, скажем, для заказов компании 2Колеса вы построили таблицу Orders2Wheels. Если это так, то это дико неправильно и я солидарен в этом с Иван Шумов .
Вообще, все описание проблемы наводит на мысль, что у вас что-то переусложнено.
Роман Мирр, нет, не совсем так. Можно это обозначить как много-много ботов. Соответственно у каждого бота свои настройки и какая-то статистика. При своей работе бот ведет внутри себя маленькую БД с настройками и статистикой (простейший пример - счетчики сообщений, но не только). Время от времени в центральной БД могут быть изменены настройки, их нужно перетягивать в базы ботов, тоже самое и в обратную сторону. Но данные всей БД отдельному боту нафиг не нужны, поэтому берется только маленькая часть. Решить это можно и программным путем, но стало любопытно, можно ли на уровне СУБД все это настроить. CouchDB/PouchDB неплохо укладываются в идею. Но вдруг что-то такое есть и еще или даже в SQL-мире...
Роман Мирр, Или не ботов... В свое время участвовал в проекте, где как часть проекта планировался центральный склад и много маленьких, разбросанных по общирной территории. Соответственно вставал вопрос синхронизации данных складов между собой, усложненное тем, что многие места не имеют постоянного и стабильного интернета. И естественно маленьком складу вовсе не нужны все данные, а только та часть, что его касается. Типа того. К сожалению, до "боевых" условия тогда проект не дорос, но для собственного развития иногда изучаю мир СУБД в этом направлении
Алексей, ну вот и нашли. Пусть просто регулярно бот обращается за новыми надстройками к центральному сервису по api. Не забываем что интернет это не надежный канал связи и восстановить упавшую репликацию иногда невозможно и надо все делать ручками
В одном из проектов у нас сделали так:
бэкенд представлял из себя REST API, который выдавал каждому клиенту только те данные, которые касались его идентификатора. Для контроля версий данных использовали таблицу с client_id, version, action и каждый клиент скачивал накопившуюся разницу.
Клиенты периодически, раз в 5-10 минут, выполняли polling с сервера с накопившимися изменениями у клиента, при том что сервер централизованно хранил и управлял всеми изменениями.
При сбое коннекта происходила повторная попытка соединения согласно периоду. Так что в офлайне клиенты работали хоть с устаревшими данными, но таки работали.
Средний
Простой
Простой
