Архитектура базы данных Master-master vs master-slave?
Я слышал о двух типах архитектуры баз данных.
мастер-мастер
master-slave
разве мастер-мастер не более подходит для сегодняшней сети, потому что это похоже на Git, каждый блок имеет весь набор данных, и если он идет вниз, это не совсем важно.
Master-slave напоминает мне SVN (который мне не нравится), где у вас есть один центральный блок, который обрабатывает вещь.
вопросы:
каковы плюсы и минусы каждого?
Если вы хотите иметь локальную базу данных в вашем мобильном телефоне, как iPhone, какой из них более подходит?
является ли выбор одного из них критическим фактором для тщательного рассмотрения?
2 ответов:
мы торгуем доступностью, последовательностью и сложностью. Чтобы сначала ответить на последний вопрос: имеет ли это значение? Да уж очень! Выбор того, как управлять вашими данными, является абсолютно фундаментальным, и нет "лучшей практики" уклонения от решений. Вы должны понимать ваши конкретные требования.
есть фундаментальное противоречие:
один экземпляр: последовательность легка, но если она случается вниз, то все из воды, и если люди удаленные тогда могут заплатить ужасные затраты на связь. Принесите портативные устройства, которые, возможно, потребуется работать отключен, в картину и одна копия не будет вырезать его.
Master Slave: согласованность не слишком сложна, потому что каждая часть данных имеет ровно один владелец master. Но что тогда делать, если вы не видите этого мастера, нужна какая-то отложенная работа.
Мастер-Мастер: ну, если вы можете заставить его работать, то он, кажется, предлагает все, ни одной точки отказа, каждый может работать все время. Беда в том очень трудно сохранить абсолютную последовательность. Смотрите статья в Википедии дополнительные.
Википедии, кажется, есть хорошее резюме преимуществ и недостатков
преимущества
Если один мастер терпит неудачу, то другие мастера будут продолжаться уточнить база данных.
мастера могут быть расположены на нескольких физических сайтах т. е. распространяется по сети.
недостатки
большинство систем репликации с несколькими мастерами только слабо согласованы, т. е. ленивый и асинхронный, нарушающий кислотные свойства.
нетерпеливые системы репликации сложны и вводят некоторые задержка связи.
такие вопросы, как разрешение конфликтов могут стать неразрешимыми, как количество узлов вовлеченный повышается, и требуемая задержка уменьшается.
при исследовании различных архитектур баз данных. Я собрал хороший бит информации, которая может быть актуальна для кого-то другого исследования в будущем. Я наткнулся
- Репликация Master-Slave
- Мастер-Мастер Репликации
- MySQL Cluster
Я решил согласиться на использование MySQL Cluster для моего варианта использования. Однако, пожалуйста, смотрите ниже для различных плюсов и минусов, которые я собрал
1. Репликация Master-Slave
плюсы
- аналитические приложения могут считывать данные с ведомого устройства(ов) без воздействия на ведущее устройство
- резервные копии всей базы данных относительно не влияют на мастер
- ведомые устройства могут быть переведены в автономный режим и синхронизированы с мастером без каких-либо простоев
минусы
- в случае неудачи подчиненный должен быть повышен до мастера займите его место. Нет автоматического перехода на другой ресурс
- время простоя и, возможно, потеря данных, когда мастер терпит неудачу
- все записи также должны быть сделаны мастеру в дизайне master-slave
- каждый дополнительный ведомый добавляет некоторую нагрузку к ведущему устройству, так как двоичный журнал должен быть прочитан и данные скопированы в каждый ведомый
- приложение, возможно, придется перезапустить
2. Мастер-Мастер Репликация
плюсы
- приложения могут читать от мастера
- распределяет нагрузку на запись между обоими главными узлами
- простой, автоматический и быстрый переход на другой ресурс
минусы
- слабо согласуется
- не так просто, как master-slave для настройки и развертывания
3. MySQL Cluster
новый ребенок в городе на основе MySQL кластерное проектирование. MySQL cluster был разработан с учетом высокой доступности и масштабируемости и является идеальным решением для использования в средах, которые не требуют простоев, высокой доступности и горизонтальной масштабируемости.
посмотреть MySQL Cluster 101 для получения дополнительной информации
плюсы
- (высокая доступность) нет единой точки отказа
- очень высокая пропускная способность
- 99,99% время безотказной работы
- Авто-Шардинг
- В Режиме Реального Времени
- -лайн операций (изменения схемы и т. д.)
- распределенные пишет
минусы
- посмотреть ограничения
вы можете посетить мой блог полная разбивка, включая диаграммы архитектуры, которая подробно описывает 3 упомянутые архитектуры.
Comments