Теорема CAP - Доступність та толерантність розділів

Поки я намагаюся зрозуміти "Доступність" (A) та "Толерантність до розділів" (P) в CAP, мені було важко зрозуміти пояснення з різних статей.

У мене виникає відчуття, що А і Р можуть йти разом (я знаю, що це не так, і тому я не розумію!).

Пояснюючи простими словами, що таке A і P і різниця між ними?

Послідовність означає, що дані однакові у кластері, тому ви можете читати чи записувати з / на будь-який вузол та отримувати однакові дані.

Доступність означає можливість доступу до кластера, навіть якщо вузол у кластері опускається вниз.

Толерантність розділів означає, що кластер продовжує функціонувати, навіть якщо між двома вузлами є "розділ" (перерва в комунікації) (обидва вузли вгору, але не можуть спілкуватися).

Для того, щоб отримати доступність та толерантність до розділів, ви повинні відмовитися від послідовності. Поміркуйте, чи є у вас два вузли, X і Y, у програмі master-master. Тепер між мережевим зв’язком між X та Y існує перерва, тому вони не можуть синхронізувати оновлення. На даний момент ви можете:

A) Дозвольте вузлам вийти з синхронізації (відмовившись від консистенції), або

B) Вважайте кластер "зниженим" (відмова від доступності)

Усі доступні комбінації:

• CA - дані узгоджуються між усіма вузлами - доки всі вузли є в Інтернеті - і ви можете читати / писати з будь-якого вузла і бути впевненим, що дані однакові, але якщо ви коли-небудь розробляєте розділ між вузлами, дані будуть не синхронізовано (і не повторно синхронізується, коли розділ буде вирішено).
• CP - дані узгоджуються між усіма вузлами та підтримують роздільну толерантність (запобігаючи десинхронізації даних), стаючи недоступними, коли вузол опускається.
• AP - вузли залишаються в Інтернеті, навіть якщо вони не можуть спілкуватися один з одним і відновлять синхронізацію даних, коли розділ буде вирішений, але ви не гарантовані, що всі вузли матимуть однакові дані (під час або після розділу)

Слід зазначити, що системи CA практично не існують (навіть якщо деякі системи заявляють, що це так).

Якщо вважати, що Р в рівних співвідношеннях з C і A, це деяка помилка, швидше поняття "2 з 3" серед C, A, P вводить в оману. Короткий спосіб, який я поясню теоремою CAP, полягає в тому, що "У розподіленому сховищі даних під час мережевого розділу ви повинні вибрати або" Послідовність ", або" Доступність "і не можете отримати і те й інше". Більш новітні системи NoSQL намагаються зосередити увагу на доступності, тоді як традиційні бази даних ACID мали більше уваги на послідовності.

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

Ось як я обговорюю CAP, зокрема щодо P.

CA можливий лише в тому випадку, якщо ви добре з монолітною єдиною серверною базою даних (можливо, з реплікацією, але всі дані про один "блок відмов" - сервери не вважаються частково відмовними).

Якщо ваша проблема потребує масштабних, розподілених та багатосерверних --- мережевих розділів. Ви вже потребуєте P. Нечисленні проблеми, до яких я підходжу, піддаються парадигмам, які завжди є одним сервером (або, як сказав Стоунбрейкер, "розподілені ставки таблиці"). Якщо ви знайдете проблему з ЦА, такі рішення, як традиційні не масштабні RDBMS, надають багато переваг.

Для мене рідкість: тому ми переходимо до обговорення AP проти CP.

Ви можете вибрати між AP та CP операцією лише тоді, коли у вас є розділ. Якщо мережа та обладнання працюють правильно, ви отримуєте торт і їсте його.

Давайте обговоримо відмінність AP / CP.

AP - коли є мережевий розділ, нехай незалежні частини вільно працюють.

CP - коли є мережевий розділ, вимикають вузли або забороняють читати і записувати, тому виникають детерміновані збої.

Мені подобаються архітектури, які можуть робити і те, і інше, оскільки деякі проблеми є AP, а деякі - CP - а деякі бази даних можуть робити і те, і інше. Серед рішень CP та AP є також тонкощі.

Наприклад, у наборі даних AP ви маєте можливість як непослідовної читання, так і генерування конфліктів запису - це два різних можливих режиму AP. Чи може ваша система бути налаштована на AP з високою доступністю читання, але забороняє конфлікти при записі? Або ваша система AP може приймати конфлікти при записі із сильною та гнучкою системою дозволу? Чи будуть вам потрібні обидва з часом, чи ви можете вибрати систему, яка виконує лише одну?

Скільки недоступності ви маєте в системі CP, якщо ви маєте невеликі розділи (один сервер), якщо такі є? Більша реплікація може збільшити недоступність в системі CP, як система обробляє ці компроміси?

Це всі питання, які потрібно задати CP проти AP.

Зараз у цій галузі чудово прочитано пост "12 років потому" Брюера. Я вважаю, що це чітко просуває дебати щодо ССП, і настійно рекомендую.

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

Консистенція:

Читання гарантовано поверне останнє записування (наприклад, ACID) для даного клієнта. Якщо якийсь запит надходить протягом цього часу, він повинен зачекати, поки синхронізація даних завершиться через / у вузолі (ях).

Наявність:

кожен вузол (якщо не вийшов з ладу) завжди виконує запити і завжди повинен відповідати на запити. Не має значення, повертає вона останню копію чи ні.

Толерантність до перегородки:

Система продовжить функціонувати, коли з’являться мережеві розділи.

Щодо AP , доступність (завжди доступна) може існувати з ( дозволом ) або без ( RDBMS ) допуску розділення

pic джерело

Я вважаю, що толерантність до розділів не пояснюється добре в жодній з відповідей, тому просто пояснити речі ще детальніше теорема CAP означає:

C : (Лінійність або міцна консистенція) приблизно означає

Якщо операція B розпочалася після операції Успішно завершена, операція B повинна бачити систему в тому ж стані, що і після завершення операції A, або більш новий стан (але ніколи не старий стан).

A :

"Кожен запит, отриманий невдалим вузлом [база даних] в системі, повинен спричинити відповідь [без помилки]". Недостатньо, щоб якийсь вузол міг обробляти запит: будь-який невдалий вузол повинен мати можливість обробляти його. Багато так званих «високодоступних» (тобто малих простоїв) систем насправді не відповідають цьому визначенню доступності.

P :

Толерантність розділів (страшно неправильно названа) означає, що ви спілкуєтесь через асинхронну мережу, яка може затримувати або видаляти повідомлення. Інтернет та всі наші центри обробки даних мають цю властивість, тож ви насправді не маєте жодного вибору в цьому питанні.

Джерело: Чудова робота Мартіна Клеппмана

Тільки для прикладу: Кассандра може бути не більше, ніж система AP. Але якщо ви налаштуєте його для читання або запису на основі кворуму, він не залишається доступним CAP (доступний за визначенням теореми CAP) і є лише системою P.

У простій теоремі CAP зазначено, що розподіленій системі неможливо одночасно забезпечити всі три гарантії:

Послідовність

Кожен вузол містить однакові дані одночасно

Доступність

Для обслуговування даних кожного разу повинен бути принаймні один вузол

Толерантність до розділів

Поломка системи зустрічається дуже рідко

Переважно кожна система може гарантувати лише мінімум дві функції: CA, AP або CP .

Послідовність - Коли ми надсилаємо запит на читання, якщо він повертає результат, він повинен повернути останнє записування, задане клієнтським запитом. Наявність - Ваш запит на читання / запис завжди повинен бути успішним. Толерантність до розділів - Коли виникає мережевий розділ (проблема, коли деякі машини спілкуються між собою), система все одно повинна працювати.

У розподілених є шанси на те, що мережевий розділ відбудеться, і ми не можемо уникнути "P" CAP. Тож ми вибираємо між "Послідовністю" та "Доступністю".

http://bigdatadose.com/understanding-cap-theorem/

Простий спосіб зрозуміти теорему CAP:

У випадку з мережевим розділом потрібно вибрати між ідеальною доступністю та ідеальною узгодженістю.

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

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

Це пояснення з цієї чудової статті . Сподіваюся, це допоможе.

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

Тому я описую CAP дуже простими формулюваннями.

• Послідовність : Потрібно повернути ті самі Дані , незалежно від того, з якого вузла вони надходять.

• Доступність : Вузол повинен відповідати (повинен бути доступний).

• Толерантність розділів : Кластер повинен відповідати (повинен бути доступний), навіть якщо між вузлами є розділ (тобто відмова мережі).

(Також однією головною причини він плутає більш погано іменування його Якби я мав рацію, я міг би дати. DNC теореми замість: Data Консистенція , доступність вузла , доступність кластера , де кожен з яких відповідає консистенції , доступність і Partition Tolerance відповідно)

База даних CP: База даних CP забезпечує стійкість та толерантність до розділів за рахунок доступності. Коли розділ відбувається між будь-якими двома вузлами, система повинна вимкнути невідповідний вузол (тобто зробити його недоступним), поки розділ не буде вирішений.

База даних AP: База даних AP забезпечує доступність та толерантність до розділів за рахунок послідовності. Коли відбувається розділ, всі вузли залишаються доступними, але ті, що знаходяться в неправильному кінці розділу, можуть повернути старішу версію даних, ніж інші. (Коли розділ вирішено, бази даних AP, як правило, пересинхронізують вузли, щоб виправити всі невідповідності в системі.)

База даних CA: База даних CA забезпечує послідовність та доступність у всіх вузлах. Це не може зробити це, якщо є розділ між будь-якими двома вузлами в системі, і тому не може забезпечити відмовостійкість. У розподіленій системі розділів неможливо уникнути. Отже, хоча ми можемо обговорити розподілену базу даних CA теоретично, для всіх практичних цілей розподілена база даних може бути, але не повинна існувати.

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

Джерело: https://www.ibm.com/cloud/learn/cap-theorem