CAP-дилеммa. Быстро, качественно или дешево

 АЛЕКСАНДР КАЛЕНДАРЕВ, программист в РБК Медиа, akalend@mail.ru

CAP-дилеммa
Быстро, качественно или дешево

Продолжая серию статей о NoSQL-хранилищах, нельзя не упомянуть теорему Брюера (утверждение о том, что в любой реализации распределенных вычислений возможно обеспечить не более двух из трех свойств: Согласованность, Доступность и Устойчивость)

В 2000 году профессор Калифорнийского университета Эрик Брюер выдвинул тезис, касающийся ключевых свойств распределенных систем, который затем доказали в Массачусетском технологическом институте. С тех пор он называется теоремой Брюера или теоремой CAP (по первым буквам: Consistency-Availability-Partition tolerance).

Рассмотрим составляющие CAP:

• Согласованность данных (англ. Consistency) – во всех вычислительных узлах в один момент времени данные не противоречат друг другу. Иными словами, как только мы успешно записали данные в наше распределенное хранилище, любой клиент при запросе получит эти последние данные.
• Доступность (англ. Availability) – любой запрос к распределенной системе завершается корректно при наличии операций обновления; на любой запрос к системе мы получаем наши данные или информацию об их отсутствии, если их не сохраняли.
• Устойчивость к разделению (англ. Partition tolerance) – расщепление распределенной системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций. Или, другими словами, если какие-то компоненты выходят из строя, то можно считать, что данные компоненты просто теряют связь со всей остальной системой, а система в целом остается работоспособной.

Под Устойчивостью понимается, что данные внутри кластера не смогут потеряться.

Нарушение принципа Cогласованности данных может возникнуть там, где имеется распределенное хранение данных.

Пусть ваше хранилище имеет пять узлов, и оно спроектировано так, что все данные дублируются на соседних узлах. При приходе данных на Узел_2 они будут скопированы на Узел_1 и Узел_3. И для передачи данных (репликации) с узла на узел понадобится какое-то время. В случае выхода из строя одного из узлов системы, данные должны отдаваться с соседнего узла распределенного хранилища.

К примеру: на Узел_3 пришли некоторые данные по ключу KEY_***, они не успели передаться на соседние Узлы 2 и 4, и в это время Узел_3 вышел из строя. При запросе данных по ключу KEY_*** система отдаст старую версию данных с узла Узел_2 или Узел_4.

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

Доказательство самой CAP-теоремы строится эмпирически – сначала доказываем на двух узлах, далее в соответствии с принципом математической индукции распространяем на n- узлов.

Первоначально рассматривается сеть из двух узлов G1 и G2, между которыми пропала связь. В узел G1 идет запрос на запись, а затем в G2 на чтение. Если выполняется доступность, то будет получен ответ на запрос чтения, но получены будут старые данные, так как между узлами нет связи (несогласованные данные). То есть либо свойство доступности не выполняется либо согласованности.

Доказательство теоремы избавляет нас от иллюзии иметь «идеальную» систему, которая выдает все актуальные данные и никогда не ломается. Мы имеем известное предложение менеджера: «быстро, дешево, качественно – выбирайте любые два».

Говоря о CAP-теореме, принято рассматривать ребра CAP-треугольника. Так что же собой представляют CAP-ребра (см. рис.1)?

Рисунок 1. CAP-треугольник

Статью целиком читайте в журнале «Системный администратор», №12 за 2013 г. на страницах 44-45.

Комментарии могут оставлять только зарегистрированные пользователи