Архітектура баз даних Master-master vs master-slave?

Я чув про два види архітектури баз даних.

• майстер-майстер

• хазяїн-раб

Хіба не головний майстер більше підходить для сьогоднішнього веб-сайту, тому що це як Git, у кожного блоку є весь набір даних, і якщо один знизиться, це не зовсім має значення.

Ведучий-раб нагадує мені SVN (який мені не подобається), де у вас є один центральний блок, який обробляє річ.

Запитання:

1. Які плюси і мінуси кожного?

2. Якщо ви хочете мати у вашому мобільному телефоні локальну базу даних, як iPhone, яка з них є більш підходящою?

3. Чи є вибір одного з цих найважливіших факторів ретельним?

Ми торгуємо доступністю, послідовністю та складністю. Перше вирішити останнє питання: чи це має значення? Да дуже багато! Вибір щодо управління вашими даними є абсолютно принциповим, і немає "Кращої практики", що ухиляється від прийняття рішень. Вам потрібно зрозуміти ваші конкретні вимоги.

Існує принципова напруга:

Один примірник: консистенція проста, але якщо це трапляється вниз, всі виходять з води, а якщо люди віддалені, то можуть платити жахливі витрати на спілкування. Візьміть на малюнок портативні пристрої, для яких може знадобитися відключена робота, і одна копія не виріже.

Master Slave: послідовність не надто складна, оскільки кожен фрагмент даних має точно одного власника. Але тоді, що робити, якщо ти не бачиш цього майстра, потрібна якась відкладена робота.

Майстер-майстер: добре, якщо ти можеш змусити його працювати, то, здається, пропонують все, жодної точки відмови, кожен може працювати весь час. Проблема в тому, що дуже важко зберегти абсолютну консистенцію. Докладніше див. У статті Вікіпедії .

У Вікіпедії, здається, є хороший підсумок переваг та недоліків

Переваги

• Якщо один майстер не працює, інші майстри продовжать оновлювати базу даних.

• Майстри можуть розташовуватися на декількох фізичних сайтах, тобто розподілятися по всій мережі.

Недоліки

• Більшість систем множинної реплікації лише послідовно послідовні, тобто ледачі та асинхронні, що порушують властивості ACID.

• Системи гострої реплікації є складними і вводять деяку затримку зв'язку.

• Такі питання, як вирішення конфлікту, можуть стати нерозв'язними, оскільки кількість залучених вузлів зростає і необхідна затримка зменшується.

Під час дослідження різних архітектур баз даних. Я зібрав багато інформації, яка може бути актуальною для когось іншого дослідження в майбутньому. Я натрапив

1. Реплікація головного раба
2. Реплікація Master-Master
3. Кластер MySQL

Я вирішив погодитися на використання кластера MySQL для мого випадку використання. Однак дивіться нижче про різні плюси і мінуси, які я склав

1. Реплікація головного раба

Плюси

• Аналітичні програми можуть читати з підлеглого (-ів), не впливаючи на головного
• Резервне копіювання всієї бази даних відносно не впливає на майстер
• Раби можуть бути відведені в автономному режимі і синхронізуватися назад з ведучим без простоїв

Мінуси

• У разі невдачі, раба повинно бути підвищено до господаря, щоб зайняти його місце. Немає автоматичного відмови
• Простой час і можливо втрата даних, коли майстер не працює
• Усі записи також повинні бути зроблені майстру в дизайні майстра-раба
• Кожен додатковий ведений додає певного навантаження майстру, оскільки двійковий журнал повинен бути прочитаний і дані скопійовані до кожного веденого
• Програму, можливо, доведеться перезапустити

2. Реплікація Master-Master

Плюси

• Заявки можуть читати обидва майстри
• Розподіляє навантаження запису по обох головних вузлах
• Простий, автоматичний та швидкий відхід

Мінуси

• Слабо послідовно
• Не так просто, як майстер-підлеглий для налаштування та розгортання

3. Кластер MySQL

Новий хлопець у місті на основі дизайну кластерів MySQL. Кластер MySQL був розроблений з урахуванням високої доступності та масштабованості, і це ідеальне рішення для використання в середовищах, які не потребують простоїв, високої доступності та горизонтальної масштабованості.

Див MySQL Cluster 101 для отримання додаткової інформації

Плюси

• (Висока придатність) Немає жодної точки відмови
• Дуже висока пропускна здатність
• 99,99% тривалості роботи
• Авто-заточування
• Реактивність в режимі реального часу
• Он-лайн операції (зміни схеми тощо)
• Поширені записи

Мінуси

• Дивіться відомі обмеження

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