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

[iDesperado]

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

да, обозвать oracle rac "технологией с неочевидными сайд-эффектами и минимумом открытых фидбеков от клиентов", учитывая что технология добрую четверть все рынка рдбмс занимает (всего оракл это 50% рынка), это сильно.
реально топикастеру надо смотреть мсскл где мультимастер репликация из коробки и во всех редакциях + много у кого нормально работает.
оракл конечно круто, но смысла тратить много больше на явно не космические задачи явно нет. EE редакция со всякими RAC, golden gate чудовищно дороги, в стандарт редакции репликация кастрированная хрень. я когда исследовал вопрос, нашел http://www.dbvisit.com/ которые предлагают репликацию под оракл стандарт едишен. вроде они и под другие субд предлагают.

[Mark]

Решений для повышения отказоустойчивости базы данных много. Как пример на Оракле это Real Application Cluster (RAC) c Transparent Application Failover(TAF), or Oracle Physical Standby c Dataguard. Что использовать, зависит от требований к отказоустойчивости: несколько минут или несколько секунд.

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

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

А если серьезно : можно сразу не брать, можно просто почитать. Качнуть пробную версию. ИМХО если нет опыта с Оракл, то Oracle RAC поставить может не получится. Сразу надо сказать : Oracle RAC - Это очень дoрого. Если не надо отказоусточивости в секунды, то можно обойтись Oracle Standard Edition with Physical Standby and Dataguard. Получится гораздо бюджетнее.

Тут несколько наоборот в Standard Edition (SE)- RAC is free. А Dataguard в SE нету.

[Boriskin]

реально топикастеру надо смотреть мсскл где мультимастер репликация из коробки и во всех редакциях + много у кого нормально работает.

А МССКЛ вообще живет на линуксах?

[Flash-04]

2017 - да!

[Boriskin]

А чего так воодушевленно?

[Flash-04]

Ну раз тебе нужно...

[valchkou]

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

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

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

[major Major Major Major]

Встала след. задача - сделать DB solution с примерно следующими характеристиками

На Монго это все делается с пол пинка. Я в свое время настроил с нуля replica set за пару часов не имея никакого понятия как оно работает заранее. При этом у меня пара нодов крутилась в офисе а третья машина была у девелопера в России (для быстроты отладки), уходя в оффлайн постоянно. Был поражен лекгостью с какой все это заработало

[valchkou]

Встала след. задача - сделать DB solution с примерно следующими характеристиками

На Монго это все делается с пол пинка. Я в свое время настроил с нуля replica set за пару часов не имея никакого понятия как оно работает заранее. При этом у меня пара нодов крутилась в офисе а третья машина была у девелопера в России (для быстроты отладки), уходя в оффлайн постоянно. Был поражен лекгостью с какой все это заработало

монго это хорошая опция, проста не только в установке но и для програмистов
вопрос в объемах данных и high availability
если когда вдруг потребуется шардинг то вот где и начинается засада

[major Major Major Major]

Встала след. задача - сделать DB solution с примерно следующими характеристиками

На Монго это все делается с пол пинка. Я в свое время настроил с нуля replica set за пару часов не имея никакого понятия как оно работает заранее. При этом у меня пара нодов крутилась в офисе а третья машина была у девелопера в России (для быстроты отладки), уходя в оффлайн постоянно. Был поражен лекгостью с какой все это заработало

монго это хорошая опция, проста не только в установке но и для програмистов
вопрос в объемах данных и high availability
если когда вдруг потребуется шардинг то вот где и начинается засада

Да, у них отличный драйвер для .net с поддержкой линка. Работал и из r studio без проблем. Шардинг это уже сложнее, там надо думать и лучше на этапе дизайна базы. Я когда налаживал наверное раза три все убивал нафиг и начинал с нуля, думаю пару тройку дней потратил. Но топикстартеру шардинг вряд ли понадобится. Я рекомендую поставить и поиграться. Монговские процессы можно поднять на одной машине, то есть для первоначального устройства реплики сета запустить три штуки локально, никаких дополнительных серверов не потребуется, а потом присоединять внешние по мере надобности.

[valchkou]

ну тогда https://mariadb.com/

[iDesperado]

На Монго это все делается с пол пинка. Я в свое время настроил с нуля replica set за пару часов не имея никакого понятия как оно работает заранее. При этом у меня пара нодов крутилась в офисе а третья машина была у девелопера в России (для быстроты отладки), уходя в оффлайн постоянно. Был поражен лекгостью с какой все это заработало

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

[tessob]

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

Более двадцати лет работаю с Ораклом. Если вы не знакомы с этими продуктами/технологиями, то это ваши проблемы
Обозвать Оракл "проприетарные технологии с неочевидными сайд-эффектами и минимумом открытых фидбеков от клиентов" , спасибо, посмешили. В Гугл батенька

Простите, но именно такие специалисты как вы и отпугивают меня от таких брендов, как Oracle. Посмотрите сами, ваш RAC - до 100 километров. Вы действительно считаете, что если я размещу кластер на разных материках в публичных сетях, то никаких сайд эффектов у меня точно не будет?

[iDesperado]

Простите, но именно такие специалисты как вы и отпугивают меня от таких брендов, как Oracle. Посмотрите сами, ваш RAC - до 100 километров. Вы действительно считаете, что если я размещу кластер на разных материках в публичных сетях, то никаких сайд эффектов у меня точно не будет?

я тоже считаю, что нужно быть ну очень крупным спецом, что бы после 20 лет с ораклом оставались "неочевидные сайд-эффекты" при синхронизации буферного кэша оракла. там требование sync в микросекунды, какие сотни км ? возьмите что-то попроще, вы явно 20 лет потеряли впустую. возьмите NoSQL, там все заметно проще.

[major Major Major Major]

На Монго это все делается с пол пинка. Я в свое время настроил с нуля replica set за пару часов не имея никакого понятия как оно работает заранее. При этом у меня пара нодов крутилась в офисе а третья машина была у девелопера в России (для быстроты отладки), уходя в оффлайн постоянно. Был поражен лекгостью с какой все это заработало

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

Ну так от задачи и от подхода зависит. При правильно построенной модели документов в их идеологии много из мира SQL становится уже не особо нужным. Я не утверждаю что Монго это замена скажем ms sql для любой задачи, у них своя ниша где уже sql server неуютно себя ощущает (вот такая региональная репликация к примеру, или те же aggregation pipeline). У меня системы есть как на той так и на другой платформе, главное не забывать про поговорку про молоток и гвозди.

[Mark]

..По моему мнению для абсолютного большинства задач достаточно Oracle Standard Edition + Physical Standby DB. Все. А 100 км или 1000 км влияет только на задержки по сети.

ну ты палку то не перегибай - есть у меня кастомеры на SE - больше всего не хватает параллелизма - на скорость реально влияет. Ну и Standby надо руками допиливать - не rocket science конечно - но скриптовать надо.

Простите, но именно такие специалисты как вы и отпугивают меня от таких брендов, как Oracle. Посмотрите сами, ваш RAC - до 100 километров. Вы действительно считаете, что если я размещу кластер на разных материках в публичных сетях, то никаких сайд эффектов у меня точно не будет?

Давайте не путать круглое с мягким, для таких вещей надо делать active-active репликацию (Golden Gate вполне себе работает) - RAC это другая технология... если вас устраивает read/only replica то расстояние в Oracle роли не играет - ставится куча far-sync серверов и вперед.
Но как уже писал Lazy444 если нет денег то в сторону Oracle смотреть не стоит.
По поводу Кассандры - если теоретики и пишут про распределенные кластера - то на практике это не работает как должно про support от DataStax я вообще лучше промолчу.

[mskmel]

про support от DataStax я вообще лучше промолчу.

Если добавить суппорт к Кассандре и стоимость их professional services , то Оракл уже не таким дорогим кажется.
Тоже самое относится и к Монго vs Oracle SE.

[tessob]

Топик начался с:

1. требуется репликация всех данных целиком на разные регионы - Сев. Америка, Зап. Европа и Азия

Я поделился своим опытом с единственным мастером и кучей слейвов. Решение у нас было на Оракле, если чо. Однако Оракл не потому, что он лучше мускуля или постгреса, а потому, что ИТ манагеры от заказчика решили, что их за факап с ораклом не уволят, а за факап с мускулем уволят точно. Когда решение проектировали заказчик призывал Оракловых консультантов, которые 2 недели показывали презы, махали руками, но от предложения запилить демо-решение с несколькими мастерами или организовать референс к клиенту, где это есть, отказались.

Что касается решения на нескольких мастерах, то все, что я знаю - это бесконечная еб.. работа с кластером и прОклятый архитектор.

З.Ы. У нас после запуска ни один ДБА ни разу не просыпался среди ночи.

[iDesperado]

Я поделился своим опытом с единственным мастером и кучей слейвов. Решение у нас было на Оракле, если чо. Однако Оракл не потому, что он лучше мускуля или постгреса, а потому, что ИТ манагеры от заказчика решили, что их за факап с ораклом не уволят, а за факап с мускулем уволят точно. Когда решение проектировали заказчик призывал Оракловых консультантов, которые 2 недели показывали презы, махали руками, но от предложения запилить демо-решение с несколькими мастерами или организовать референс к клиенту, где это есть, отказались.

Что касается решения на нескольких мастерах, то все, что я знаю - это бесконечная еб.. работа с кластером и прОклятый архитектор.

З.Ы. У нас после запуска ни один ДБА ни разу не просыпался среди ночи.

у в индии и с 40 лет опыта и не такое рекомендуют, не важно что ораклу 40 еще нет. у меня в канторе десяток референсов с RAC кластером с датагвардом в соседний датацентр. и работают эти системы в странах между котором 4-6 тысяч км. просто нельзя людей с "20 лет опыта" подпускать к системам, если те не врубаюются как тот же RAC работает. мусье, почитайте что такое оракл и его буферный кеш. там суть в том что нода лезет на соседнюю вместо того что бы с SSD диска поднять блок, именно потому, что расчет что соседняя нода в микросекунды 8к блок отдаст. в этом вся суть.
если ноды за сотни км, это репликация. причем если сравнивать с понятиями NoSQL, то асинхронная, где ни транзакций ни консистенции ни ничего нет. даже уникальные ключи и те руками зачастую в NoSQL приходиться изобретать самостоятельно.

[iDesperado]

Ну так от задачи и от подхода зависит. При правильно построенной модели документов в их идеологии много из мира SQL становится уже не особо нужным. Я не утверждаю что Монго это замена скажем ms sql для любой задачи, у них своя ниша где уже sql server неуютно себя ощущает (вот такая региональная репликация к примеру, или те же aggregation pipeline). У меня системы есть как на той так и на другой платформе, главное не забывать про поговорку про молоток и гвозди.

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

[valchkou]

По поводу Кассандры - если теоретики и пишут про распределенные кластера - то на практике это не работает как должно .

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

[Леонид Ильич Брежнев]

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

А что DynamoDB реплицирует через континенты, а не в пределах одного ринга - группы DC в нескольких милях друг от друга?
Cross ring traffic у Амазона всегда был и медленный и дорогой, по крайней мере мне так пару лет назад в ВПШ рассказывали.

[Леонид Ильич Брежнев]

Вот условие задачи (одно из) :
2. адекватная синхронизация данных между регионами за приемлемое время (суперскорость в силу определенных причин не критична), но хотелось бы чтобы write/update в одном месте доходили до других не через часы.

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

Ну бывает еще eventually consistence vs. consistent read. Если нужно первое, то результат не предсказуем, если второе, то результат гарантирован. Кассандру скажем можно развернуть так, что бы было в нескоько DC реплицировать. Но это будет не быстро, и чем таких replicatable DCs тем медленне будет. Но работать будет.

[Леонид Ильич Брежнев]

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

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

Cassandra single host installation, 60K writes per second

[alex_127]

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

А что DynamoDB реплицирует через континенты, а не в пределах одного ринга - группы DC в нескольких милях друг от друга?
Cross ring traffic у Амазона всегда был и медленный и дорогой, по крайней мере мне так пару лет назад в ВПШ рассказывали.

https://aws.amazon.com/dynamodb/global-tables/

Что такое cross ring - не знаю, разве там кольцо?