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

[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 (который конечно на порядок лучше) стоит не по детски.

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

[Boriskin]

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

Понял, спасибо!

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

Миллионов не будет точно, десятки тысяч - теоретический предел.

[tessob]

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

Вся запись только в мастер, а чтение только из слейвов. Просто было принято волевое решение, что запись в базу будет дорогой, но зато дешевое чтение и никакого гимора с консистентностью. Ну и любое количество слейвов, в том числе для всякого репортинга и прочей фигни.

[Vladimir Kr.]

Мастер ничего не знает о репликах

... пишешь одно, читаешь дрyгое.
при чем здесь "Синхронизация и репликация" ?

[tessob]

Мастер ничего не знает о репликах

... пишешь одно, читаешь дрyгое.

Па Чи Му !?

при чем здесь "Синхронизация и репликация" ?

Без понятия. Почему Вы про них решили заговорить? Я рассказывал как мы решали аналогичную задачу на практике. Что там, в этот момент, происходило в теории я не в курсе.

[Vladimir Kr.]

Мастер ничего не знает о репликах

... пишешь одно, читаешь дрyгое.

Па Чи Му !?

при чем здесь "Синхронизация и репликация" ?

Без понятия. Почему Вы про них решили заговорить? Я рассказывал как мы решали аналогичную задачу на практике. Что там, в этот момент, происходило в теории я не в курсе.

Вы пишите только в мастер, "Мастер ничего не знает о репликах", читаете только с реплик.
почему в реплике будет идентичное мастеру сразу после записи в мастер?

У нас топик "Синхронизация и репликация" мастер-мастер базы.
Вы решали задачу мастер-мастер репликации, путем приведения ее к мастер-слейв?

[VovaK98]

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

Вспомнилось вот.
Когда я в середине девяностых коптил в одной из большой шестерки (щас уже big-4), такое решение совершенно безпроблемно работало на Лотусе Домино. Репликация и секюрити всегда были сильной стороной Лотуса. Мы, сидя в Москве, тянули реплики из UK, там хаб был. Питерский и региональные офисы тянули данные уже у нас. Лотус Домино - можно сказать, чистый NoSQL. Писали данные при этом во все реплики, и оно само уже расползалось.
Щас Лотус уже как бы всё, но вроде как несколько лет назад то что осталось перетянули на DB2 формат данных. Сам я уже не в струе, но поскольку вспомнилось- то вот - могу порекомендовать посмотреть в сторону IBM.
Успехов!

[tessob]

Вы пишите только в мастер, "Мастер ничего не знает о репликах", читаете только с реплик.
почему в реплике будет идентичное мастеру сразу после записи в мастер?

У нас топик "Синхронизация и репликация" мастер-мастер базы.
Вы решали задачу мастер-мастер репликации, путем приведения ее к мастер-слейв?

Перечитайте пункты 2 и 3 из первого поста. Если вы знаете как решить подобную задачу в реальном времени и в реальном мире, то напишите пожалуйста свою версию. Только имейте ввиду, что в реальном мире shit happens (сервера падают, провайдеры лажают, пакеты теряются). Мне и самому будет интересно узнать как "правильно" дизайнить распределенные системы.

[Vladimir Kr.]

Вы пишите только в мастер, "Мастер ничего не знает о репликах", читаете только с реплик.
почему в реплике будет идентичное мастеру сразу после записи в мастер?

У нас топик "Синхронизация и репликация" мастер-мастер базы.
Вы решали задачу мастер-мастер репликации, путем приведения ее к мастер-слейв?

Перечитайте пункты 2 и 3 из первого поста. Если вы знаете как решить подобную задачу в реальном времени и в реальном мире, то напишите пожалуйста свою версию. Только имейте ввиду, что в реальном мире shit happens (сервера падают, провайдеры лажают, пакеты теряются). Мне и самому будет интересно узнать как "правильно" дизайнить распределенные системы.

Как тут правильно сказали, для общего решения задачи синхронизации мастер-мастер серверов нужно определиться с алгоритмом разрешения конфликтов при сравнении двух commited записей с двух и более серверов. Это не та-же задача, что клиент-сервер, из-за отсутствия комита на клиенте.
Конкретную задачу ТС#2 можно решить выбрав один из алгоритмов плюс возможено шардинг, но останется вопрос об адекватности синхронизации.

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

Объединяем эти два подхода, добавляем мастер-слейв:
как обычно, читаем с любого сервера.
используем двухфазный коммит, но только с одним сервером, там где запись (table row) помечена как мастер копия. Это может быть тот-же сервер, или другой, но он будет один. После коммита изменения на мастер сервере, нужно в бакграунде оповестить _все_ остальные сервера об изменении. Если мастер не найден, это то в случае, если сервер резко умер (или потерял связь), то нужно подтвержение от всех серверов о смене мастер метки конкретной записи. Если при этом (отсутствие сервера с мастер меткой) запись изменилась сразу в 2х местах, то смотри выше вариант с двухфазным комитом. Но лучше сервера гасить с передачей всех мастер меток на ближайший. При потере связи да и вообще в бакграунде нужно сравнить логи транзакций с ближайшим сервером, на предмет более свежих записей. Если добавить распределение мастер меток по шардингу регионов, то не будет тормозить на cross-region ХА commit.

Получается чуть сложнее, чем обычный двухфазный коммит, но ничего супер сложного. Надежно, сравнительно быстро, тру мастер-мастер с AZ & HA & DR.

Я не знаю как с Ораклом, да и с Постгресом тоже не в курсе всех особенностей их вариантов. Может у Касандры похожая реализация?

[tessob]

Короче, правильно ли я понимаю, что:
1) В первом случае, если пользователи создадут на двух мастерах записи с одинаковыми ключами (инкремент) консистентность идет лесом?
2) Во втором случае мы просто ухудшаем производительность не выигрывая ни в чем?
3) В третьем случае клиент должен гулять по куче серверов разыскивая строчки с правильными метками, что как бы еще более медленное решение чем во втором случае?

Вы хоть один из этих подходов на практике реализовывали?

[uncle_Pasha]

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

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

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

Я не уловил требований, которые препятствуют использования репликации с Postgress.
Тот же Amazon его использует в AWS - и read-only реплики работают вполне сносно.
Можно, конечно, что-то еще прикрутить, но почему бы не начать с того, что работает уже сейчас?