Что такое CAP-теорема, как она связана с Big Data и NoSQL-СУБД

CAP – это акроним от англоязычных слов Consistency (Согласованность, Целостность), Availability (Доступность) и Partition tolerance (Устойчивость к разделению). Согласно утверждению профессора Калифорнийского университета в Беркли, Эрика Брюера, сделанному в 2000-м году, в распределенных системах осуществимы лишь 2 свойства из указанных 3-х. В частности, считается что нереляционные базы данных жертвуют согласованностью данных в пользу доступности и устойчивости к разделению, когда расщепление распределённой системы на несколько изолированных частей сохраняет корректный отклик от каждой из них [1]. В 2002 году Сет Гилберт и Нэнси Линч из MIT опубликовали формальное доказательство гипотезы Брюера, после чего она стала считаться теоремой [2].

Классы NoSQL-СУБД с точки зрения CAP-теоремы и их значимость для Big Data

По аналогии с железным треугольником проектного менеджмента, когда требуется найти баланс между сроками, затратами и качеством выполненных работ [3], тройственная ограниченность характерна и для распределенных систем. В этом смысле фактически, любое Big Data решение, не только NoSQL-СУБД, можно рассматривать с точки зрения ограничений CAP-теоремы, классифицируя ее по сочетанию 2-х свойств из 3-х возможных [4]:

CA (Availability + Consistency — Parition tolerance), когда данные во всех узлах кластера согласованы и доступны, но не устойчивы к разделению. Это означает, что реплики одной и той же информации, распределенные по разным серверам друг другу, не противоречат друг другу и любой запрос к распределённой системе завершается корректным откликом. Такие системы возможны при поддержке ACID-требований к транзакциям (Атомарность, Согласованность, Изоляция, Долговечность) и абсолютной надежности сети. На практике таких решений на основе кластерных систем управления базами данных почти не существует. Классическим примером CA-системы называют распределённую службу каталогов LDAP, а также реляционные базы данных (PostgreSQL, MySQL, MariaDB, MS SQL Server).
CP-система (Consistency + Partition tolerance — Availability) в каждый момент обеспечивает целостность данных и способна работать в условиях распада в ущерб доступности, не выдавая отклик на запрос. Устойчивость к разделению требует дублирования изменений во всех узлах системы, что реализуется с помощью распределённых пессимистических блокировок для сохранения целостности. По сути, CP – это система с несколькими синхронно обновляемыми мастер-базами. Она всегда корректна, отрабатывая транзакцию, только в том случае, если изменения удалось распространить по всем серверам. Она продолжает корректно читать данные даже при отказе одного из узлов кластера. Но в этом случае запись будет обрываться или сильно задерживаться, пока система не убедится в своей целостности и согласованности (консистентности). Из NoSQL-СУБД к CP-системам принято относить Apache HBase, MongoDB, Redis, MemcasheDB, Berkley DB, HyperTable и Google Big Table.
AP-система (Availability + Partition tolerance — Consistency) не гарантирует целостность данных, обеспечивая их доступность и устойчивость к разделению, например, как в распределённых веб-кэшах и DNS. Считается, что большинство NoSQL-СУБД относятся к этому классу систем, обеспечивая лишь некоторой уровень согласованности данных в конечном счете (eventually consistent). Таким образом, AP-система может быть представлена кластером из нескольких узлов, каждый из которых может принимать данные, но не обязуется в тот же момент распространять их на другие сервера. Такая система отлично справляется с отказами нескольких узлов, но, когда они снова начинают работать, возможна выдача пользователям старых данных. К AP-системам относят CoucheDB, Cassandra, Riak, Amazon DynamoDB.

CAP, NoSQL, Big Data, распределенные системы, тройственная ограниченность, проектный менеджмент, железный треугольник — Тройственная ограниченность баз данных и распределенных Big Data систем с точки зрения CAP-теоремы по аналогии с железным треугольником проектного менеджмента

При всей понятной на первый взгляд концепции, CAP-теорему критикуют за чрезмерное упрощение важных понятий, что приводит к неверному пониманию первоначального смысла модели. В результате этого теорема из строгого, математически доказанного утверждения превращается в маркетинговый термин с расплывчатым смыслом [5]. О критике CAP-подхода и альтернативных концепциях (BASE, PACELC) мы расскажем в отдельной статье.

Источники

Классы NoSQL-СУБД с точки зрения CAP-теоремы и их значимость для Big Data

Related Entries