Уточнення з приводу теореми CAP і помилок, пов'язаних з даними, Інші СУБД, Бази даних, статті

Оригінал: Michael Stonebraker. Clarifications on the CAP Theorem and Data-Related Errors. VoltDB.com,


Від перекладача: Догмати – гарантія прогресу, тлумачити їх небезпечно, доводиться руйнувати (Станіслав Єжи Лец)

Не зміг не перевести ще одну замітку Стоунбрейкера про теорему CAP, опубліковану на цей раз у блозі його компанії VoltDB. По суті, в ній немає нічого особливо нового, але її заключна частина цікавим чином перегукується зі статтею Іппократіса Пандіса та ін Виконання транзакцій, орієнтоване на дані, Переклад якої ми також публікуємо у своїй бібліотеці. Дійсно, продуктивність апаратури і "одновузлового" СУБД зростає, і наскільки об'ємні масивно-паралельні системи знадобляться у майбутньому (Принаймні, для підтримки додатків OLTP), стає просто незрозуміло.

Мене можна обгрунтовано дорікнути в тому, що я публікую переклад замітки, написаної у відповідь на замітку, яку я не переклав і не опублікував. Але я ніколи не приховував своєї упередженості. Я перекладаю те, що мені подобається, і те, з чим я, як правило, згоден. Якщо комусь ближче позиція Коди та його однодумців зі спільноти NoSQL, пишіть коментарі, пишіть свої статті, переводите близькі вам публікації, і ми все це з задоволенням опублікуємо (звичайно, при наявності необхідного технічної якості текстів).

До речі, сам я не є абсолютним захисником непорушності принципів ACID (на відміну від Стоунбрейкера, у мене немає своєї комерційної системи, принципи організації якої я був би зобов'язаний відстоювати хоча б з маркетингових міркувань). Тому мені, зокрема, близька і позиція Дональда Коссман (Donald Kossmann) та ін, яка полягає в тому, що не можна примушувати людей платити за узгодженість даних, якщо в їх програмах це не потрібно (так само як не можна позбавляти людей узгодженості даних, якщо в їх програмах вона необхідна). Світ багатоликий, і одним універсальним заклинанням, будь то ACID або теорема CAP, в ньому не обійдешся.

Сергій Кузнєцов


Відбувся ще один раунд онлайнових розмов про теорему CAP, оскільки Internet-спільнота продовжує обговорювати її наслідки для баз даних в комп'ютерних мережах. Коду Хейл (Coda Hale) нещодавно написав добре прийняту замітку під назвою "You Cant Sacrifice Partition Tolerance"(" Не можна жертвувати стійкістю до розділення "), визнану Еріком Брювером непоганий. Коду активно посилається на статтю про теорему CAP Brewer "s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services Гільберта (Seth Gilbert) і Лінч (Nancy Lynch).

У довгій замітці Коди всюди помітно неправильне сприйняття моєї позиції щодо теореми CAP. Коду пише: "Всупереч твердженням Майкла Стоунбрейкера, поділу (читай: відмови) дійсно трапляються". Інші люди виступають з аналогічними коментарями, так що дозвольте мені відновити справжній стан речей.

Я неухильно і багаторазово намагаюся висловити всього лише чотири міркування. Найбільш важливе міркування полягає в тому, що використання теореми CAP тільки для виправдання відкидання властивості узгодженості з набору властивостей ACID є збитковим. У реальному світі відмова від узгодженості не призводить до підвищення рівня доступності. Отже, узгодженість відкидається в обмін на ніщо. Це страхітливий технічний компроміс, і, отже, теорема CAP заохочує прийняття інженерами жахливих рішень.

Міркування 1: Теорема CAP спирається на ідеалізовану та неповну модель помилок, пов'язаних з даними

У мене є два основних заперечення проти формулювання поняття помилки в теоремі CAP:


  1. У цій моделі не зачіпається кілька важливих класів помилок, з якими доводиться справлятися адміністратору реальної системи.
  2. У моделі передбачається помилкове, з точки зору реального світу, поведінка, по крайней мере, для одного важливого виду відмов.

У зв'язку з цим, ставлення до теоремі CAP як до практичного керівництва є вкрай сумнівним. Дозвольте мені пояснити. У теоремі CAP не розглядаються такі важливі джерела відмов:

Борбагі (bohrbug): Це повторювані помилки в СУБД, які призводять до її виходу з ладу. Іншими словами, навіть якщо доступно кілька реплік бази даних, та ж сама транзакція, запущена над репліками, призведе до виходу з ладу їх усіх. Незважаючи ні на що, світ зупиниться, і висока доступність залишиться недосяжною метою.

Помилки додатків: Додаток ненавмисно змінює базу даних (всі копії). Тепер база даних пошкоджена, і розсудлива адміністратор зупинить світ і поверне базу даних в узгоджене стан. Знову ж, високої доступності досягти неможливо.

Людські помилки: людина вводить команду, еквівалентну rm * в світі баз даних, і викликає глобальну зупинку роботи. Немає можливості продовжити функціонування.

Зміна конфігурації апаратних засобів (reprovisioning): Багато хто (хоча і не всі) СУБД доводиться виводити з робочого стану для зміни конфігурації апаратури для збільшення (або зменшення) її обробної здібності. Знову ж, це типова операція, викликає "зупинку світу".

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

Тепер звернемося до відмов одного вузла. Коду вважає таку ситуацію поділом мережі. З точки зору Коди, що відмовив вузол є одним розділом, і що залишилися N -1 вузли утворюють інший розділ. Керуючись теоремою CAP, при наявності поділу мережі необхідно вибрати одне з двох – доступність або узгодженість. Однак реальний світ, очевидно, показує, що при такому відмову можна забезпечити і узгодженість, і доступність. Потрібно просто перемкнутися на вузол-репліку транзакційно узгодженим чином. Зокрема, по крайней мере, в системах Tandem і Vertica саме це робиться протягом багатьох років. Отже, ставлення до відмови вузла як до поділу мережі є, очевидно, некоректним висновком з теореми CAP.

Аналогічне твердження можна зробити з приводу розділень мережі, в яких один вузол відщеплюється від залишилися N -1 вузлів через відмову мережі.

Резюмуючи своє перше міркування, повторю, що в теоремі CAP передбачається наявність надійних програм, надійної СУБД, надійних людей і відсутність змін в апаратних ресурсах. На жаль, всі ці проблеми присутні, і їх наявність повинна прийматися до уваги. Крім того, ставлення до відмов вузлів як до розділення мережі призводить до очевидно неправильних висновків.

Міркування 2: Распределеленние системи рясніють технічними компромісами

Якщо до уваги беруться всі помилки, які тільки можуть проявитися, то реальним питанням, яким повинен потурбуватися інженер, є наступний: "Які помилки можна сховати і якою ціною?". Це інженерний компроміс між вартістю виконання системи і ймовірністю її відмов. Коду звертається до цієї проблеми в кінці своєї замітки. Для мене відповідь на сформульоване вище питання суттєво залежить від частоти різного роду помилок. На жаль, на відповідь дуже сильно впливає реальна операційне середовище. Наприклад, ОС MVS компанії IBM значно надійніше Linux або Windows. Він також залежить від того, наскільки важко приховувати помилки. Зокрема, з Візантійськими відмовами (Byzantine failure) Справитися набагато важче, ніж з помилками, що викликають безумовний зупинка системи.

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

Міркування 3: Теорема CAP часто використовується недоречним чином для обгрунтування технічних рішень

Це моє найбільш важливу заяву. Розробники багатьох систем NoSQL відмовляються від підтримки ACID-транзакцій, обгрунтовуючи своє рішення теоремою CAP. Зокрема, вони стверджують, що розділення мережі трапляються, роблячи з цього висновок, що потрібно пожертвувати або доступністю, або узгодженістю. Вони воліють жертвувати узгодженістю. Я вважаю, що це дуже поганий технічний компроміс.

Доводи дуже прості. З мого досвіду, поділу мережі трапляються не часто. Зокрема, вони відбуваються менш часто, ніж сумарний прояв борбагов, помилок програм, людських помилок і подій зміни конфігурації. Тому не так вже суттєво, що буде робитися при виникненні поділу мережі. Забезпечення стійкості системи до поділу мережі не призведе до значного підвищення рівня доступності, оскільки до глобальних відмов системи будуть проводити більш часто трапляються події. Отже, узгодженість жертвують в обмін на ніщо. Це міркування у більш розгорнутій формі представлено в моїй презентації про "міських міфах“.

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

Міркування 4: Продуктивність системи в одному вузлі докорінно змінює характер технічних обговорень

Деякі люди стверджують, що системи наступного покоління будуть виконуватися на тисячах сайтів. Теоретично, зростатиме ймовірність відмов всіх можливих видів. Захопленість індустрії технологіями типу MapReduce, прекрасного рішення для масивно-паралельного виконання пакетних операцій, як здається, призводить до висновку, що всі рішення, що стосуються роботи з великомасштабними даними (big data), повинні обов'язково розгортатися у великих мережах, які включають ненадійні сервери.

Технології нового покоління СУБД, таких як VoltDB, демонструють швидкість, більш ніж в 50 разів перевищує швидкість традиційних SQL-серверів. Тому, якщо для підтримки деякого SQL-програми потрібен 200 вузлів, то з використанням VoltDB для підтримки того ж додатка, ймовірно, вистачить 4 вузлів. Ймовірність відмови 200 вузлів значно відрізняється від імовірності відмови чотирьох вузлів.

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

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



 

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*