Синхронизация и репликация ДБ по многим частям света

[Boriskin]

Встала след. задача - сделать DB solution с примерно следующими характеристиками
1. требуется репликация всех данных целиком на разные регионы - Сев. Америка, Зап. Европа и Азия
2. адекватная синхронизация данных между регионами за приемлемое время (суперскорость в силу определенных причин не критична), но хотелось бы чтобы write/update в одном месте доходили до других не через часы.
3. максимальная пропускная способность при чтении (имеют место пиковые часы по нагрузке)
4. желательно бесплатно, можно как SQL based, так и NoSQL - данные легко утрамбуются и туда и туда.

В настоящее время имеется одна база в одном месте и скорость доступа к оной из удаленных мест при пиковой нагрузке становится очень конкретной pain in the ass, и первое, что приходит в голову - сдублировать данные поближе к местам потребления, при этом текущее решение можно полностью похерить. Собсно отсюда и сабж.

Мысли - советы - велкам!

[Palych]

Я много лет назад пытался добиться такого на OpenLDAP
Вроде почти получилось, но потом вышла новая версия, а приложение у меня отняли...

Сейчас мы тоже ищем что-то подобное.
Вроде на MySQL можно разные комбинации сделать, но как оно реально работает - непонятно...

[VovaK98]

AWS так и просится..

[Boriskin]

Текущее решение сбацано на Postgres и к оному можно прикрутить варианты репликации, hot standby и так далее, но конечная эффективность всего этого выглядит не гарантированной даже без учета сопутствующего головняка на тему физической реализации замысла.

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

Поглядываю на Кассандру, коя целиком и полностью поддерживается, по описанию выглядит как возможный кандидат, но есть сомнения на тему скорости чтения из базы - насколько быстро оно читает...

[mavr]

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

И чем это отличается от редактирования данных многими пользователями в локальной базе?

[mavr]

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

И чем это отличается от редактирования данных многими пользователями в локальной базе?

Как пример: в локальной базе одновременно можно предотвратить изменение одной и той же строчки в таблице с первичным ключом равным 1 разными пользователями. В распределенной базе изменить одну и ту же строчку в таблице с первичным ключом равным 1 как два пальца об асфальт. Внимание вопрос : запись в какой из баз будет "правильная" ?

А вот не надо менять условия задачи чтобы подогнать под ответ который у вас есть
"предотвратить изменение одной и той же строчки в таблице с первичным ключом равным 1 разными пользователями" никак не отменяет возможность изменения этой же записи другим пользователем минутой позже.
"кто первый успел, того и тапочки" в чистом виде

[alex_127]

Я надеюсь что ваш лоад какой нибудь очень специальный. Просто то что глобально работает и при этом не дохнёт под реальной нагрузкой можно пересчитать на пальцах одного архитекта. А самые работающие (спаннер, dynamodb global tables) только в клауде.

[ALV00]

У каждой приличной RDBMS есть штатный механизм репликации. Посмотрите доки как ее настраивать. Самое главное, нужно определиться со стратегией.
Насчет NoSQL, если нет биг даты, то нафиг она нужна? Там есть серьезные ограничения по функциональности, например, нет джойнов. Ну и вообще эта технология сырая и часто на коленке деланная, тогда как RDBMS все зрелые.

[Boriskin]

Если данные можно поделить так, что каждое location может менять только свою часть данных, а остальные у себя только читатели, то тоже можно делать.

Почти оно. Почти - бо есть кое какие тонкости, но в целом картина практически такая, поэтому собственно вопрос о репликации и встал. Если б был полный зоопарк - то репликация была бы как мертвому припарки.

[Boriskin]

У каждой приличной RDBMS есть штатный механизм репликации. Посмотрите доки как ее настраивать. Самое главное, нужно определиться со стратегией.

RTFM совет канэшн хороший , особенно если бы механизм был один - то и вопросов было бы значительно меньше, но у того же Postgres-a одних механизмов даже без стратегий - под десяток. Под мой конкретный случай - пяток.

Насчет NoSQL, если нет биг даты, то нафиг она нужна? Там есть серьезные ограничения по функциональности, например, нет джойнов. Ну и вообще эта технология сырая и часто на коленке деланная, тогда как RDBMS все зрелые.

Ну мало ли, может окажется, что телескопом определенной модели очень удобно гвозди забивать. Особенно если телескоп все время на облачке и под рукой.

[Boriskin]

Если два пользователя изменили одну и ту же запись с интервалом в одну минуту, и первое изменение не успело в другую базу до того, как там произошло второе изменение, то какое изменение, по вашему, оставляем ? Первое или второе ? и почему ?

Чтоб не наводить тень на плетень - этот вариант возможен и разрешается путем присуждения победы первому откоммитевшему.

[tessob]

Решали подобную задачу. Пришли к выводу, что конкретная база роли не играет, можно брать ту, к которой больше душа лежит. Мы все сделали через Single Master & Multiple Slaves. В мастер данные только пишутся. Мастер ничего не знает о репликах и конфликты решаются по принципу "кто последний, тот и папа", т.е. если из разных стран прилетят апдэйты по одному ключу, то будет принят последний. Разумеется, декриминализируется убийство разработчиков, кто апдейтит всю запись, а не отдельные поля. Ну и мастер воспринимается как Single source of true. Если какая либо реплика становится неконсистентной, то ее восстанавливают из мастера. Хотя такое бывало только в самом начале, до того как были подняты очереди между базами.

Если единственного мастера окажется мало, например по причини миллионов пользователей, то боюсь, что тут уже никто вам не даст готового рецепта.

З.Ы. Делали на Оракле. Просто он набрал больше голосов и не было особых причин "почему нет".

[Mark]

Если два пользователя изменили одну и ту же запись с интервалом в одну минуту, и первое изменение не успело в другую базу до того, как там произошло второе изменение, то какое изменение, по вашему, оставляем ? Первое или второе ? и почему ?

Чтоб не наводить тень на плетень - этот вариант возможен и разрешается путем присуждения победы первому откоммитевшему.

Ну вот вам и правило для разрешения конфликтов

Могу посоветовать делать репликацию на Оракле. Можно использовать стандартную репликацию от Оракла. Можно Oracle Streams как второй вариант. С репликацией на других базах дела не имел, сказать ничего умного не могу. Oracle Standard Edition по деньгам вполне бюджетно ИМХО.

Дык Streams все / deprecated and will be desupported.
А Golden gate (который конечно на порядок лучше) стоит не по детски.

[Palych]

Решали подобную задачу. Пришли к выводу, что конкретная база роли не играет, можно брать ту, к которой больше душа лежит. Мы все сделали через Single Master & Multiple Slaves. В мастер данные только пишутся.
...
З.Ы. Делали на Оракле. Просто он набрал больше голосов и не было особых причин "почему нет".

А пишут непосредственно клиенты? Им нужно знать о ближайшем рабе и хозяине?
Или как-то форвардятся запросы?

[Palych]

Могу посоветовать делать репликацию на Оракле. Можно использовать стандартную репликацию от Оракла. Можно Oracle Streams как второй вариант. С репликацией на других базах дела не имел, сказать ничего умного не могу. Oracle Standard Edition по деньгам вполне бюджетно ИМХО.

Дык Streams все / deprecated and will be desupported.
А Golden gate (который конечно на порядок лучше) стоит не по детски.

Вот так всегда с репликациями:
Глянешь - решений тыща под всё на свете.
Начинаешь копать - оказывается дай Бог одно из них вроде бы работающее, да и то никто не пробовал, поскольку все уже слабали на коленке что-то своё...