Теорема CAP

menu icon

Теорема CAP

В этом руководстве рассматривается теорема CAP и обсуждаются ее следствия для процессов разработки распределенных приложений и выбора хранилища данных NoSQL или реляционного хранилища данных.

Что такое теорема CAP?

Вы когда-нибудь видели рекламу ландшафтного садовника, маляра или другого мастера, которая начинается с заголовка «Дешево, быстро и качественно: выберите два варианта»?

Теорема CAP применяет похожую логику к распределенным системам — а именно, она утверждает, что любая распределенная система может обладать только двумя из трех следующих характеристик: согласованность, доступность и устойчивость к разделению (C, A и P — это первые буквы английских наименований этих характеристик).

Распределенная система представляет собой сеть, в которой данные одновременно хранятся на нескольких узлах (физических или виртуальных машинах). Поскольку все облачные приложения являются распределенными системами, в процессе проектирования облачного приложения важно учитывать теорему CAP, чтобы выбрать систему управления данными, обладающую самыми нужными вашему приложению характеристиками.

Теорема CAP известна также как теорема Брюера, поскольку впервые она была сформулирована профессором Эриком А. Брюером в 2000 году в ходе доклада по распределенным вычислениям. Два года спустя профессора Сет Гилберт и Нэнси Линч из MIT опубликовали формальное доказательство гипотезы Брюера.

Расшифровка сокращения CAP

Давайте подробнее рассмотрим три характеристики распределенных систем, на которые распространяется теорема CAP.

Согласованность

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

Доступность

Доступность означает, что обработка всех запросов данных клиентов гарантируется даже в том случае, если отдельные узлы недоступны. Другое определение: все активные узлы в распределенной системе возвращают допустимый ответ на любой запрос без каких-либо исключений.

Устойчивость к разделению

Разделение — это нарушение связи в пределах распределенной системы — потерянное или временно приостановленное соединение между двумя узлами. Устойчивость к разделению означает, что кластер должен продолжать работать, несмотря на любое число нарушений связи между узлами системы.

Теорема CAP и баз данных NoSQL

Базы данных NoSQL (нереляционные базы данных) оптимальным образом подходят для приложений в распределенной сети. В отличие от вертикально масштабируемых (реляционных) баз данных SQL, базы данных NoSQL масштабируются горизонтально и по определению являются распределенными — их можно быстро масштабировать в растущей сети, состоящей из нескольких взаимосвязанных узлов. (Дополнительная информация приведена на веб-странице «Базы данных SQL и NoSQL: в чем разница?»).

Сегодня базы данных NoSQL классифицируются в зависимости от пары практически поддерживаемых характеристик CAP:

  • База данных CP: база данных CP обеспечивает согласованность и устойчивость к разделению в ущерб доступности. Если возникает разделение между двумя узлами, то система вынуждена завершить работу несогласованного узла (сделать его недоступным) до тех пор, пока разделение не будет устранено.
  • База данных AP: база данных AP обеспечивает доступность и устойчивость к разделению в ущерб согласованности. Если возникает разделение, все узлы остаются доступными, однако часть узлов могут возвращать не актуальную версию данных. (После устранения разделения базы данных AP выполняют синхронизацию всех узлов, чтобы восстановить согласованность системы).
  • База данных CA: база данных CA обеспечивает согласованность и доступность всех узлов. Однако это невозможно, если существует разделение между двумя узлами в системе — таким образом, устойчивость к разделению не обеспечивается.

Мы упомянули этот тип баз данных в последнюю очередь не просто так — в распределенной системе разделения нельзя игнорировать. Мы можем рассматривать базу данных CA с теоретической точки зрения, однако практическая реализация распределенной базы данных CA не имеет смысла. Тем не менее, это не означает, что вы не можете создать базу данных CA для распределенного приложения, если такая необходимость возникнет. Многие реляционные базы данных, такие как PostgreSQL, обеспечивают согласованность и доступность и допускают развертывание на нескольких узлах с помощью механизмов репликации.

Теорема CAP (CP) и база данных MongoDB

MongoDB — это популярная система управления базами данных NoSQL, в которой данные хранятся в виде документов BSON (бинарный JSON). Она часто используется для больших данных и динамических приложений, работающих в нескольких разных расположениях. В контексте теоремы CAP база данных MongoDB представляет собой хранилище данных CP — она отличается устойчивостью к разделению и обеспечивает согласованность, но не гарантирует доступность.

MongoDB — это система с одним главным узлом, в которой каждый набор реплик (внешняя ссылка) может иметь только один главный узел, принимающий все операции записи. Все остальные узлы в том же наборе реплик выполняют роль вспомогательных узлов — они получают от главного узла копию журнала операций и применяют ее к своим наборам данных. По умолчанию клиенты отправляют запросы на чтение главному узлу, однако они могут настроить параметры предпочтения чтения (внешняя ссылка), позволяющие обращаться для этой цели к вспомогательным узлам.

В случае потери доступа к главному узлу вспомогательный узел с самой последней версией журнала операций выбирается в качестве нового главного узла. После того как все остальные вспомогательные узлы зарегистрируются на новом главном узле, доступ к кластеру восстанавливается. Поскольку в течение этого времени запросы на запись от клиентов не принимаются, данные остаются согласованными во всей сети.

Теорема CAP (AP) и Cassandra

Apache Cassandra — это база данных NoSQL с открытым исходным кодом, разработанная Apache Software Foundation. Это колоночная база данных позволяет хранить данные в распределенной сети. Но в отличие от MongoDB, Cassandra имеет архитектуру без главных узлов, что приводит к увеличению числа точек отказа.

В контексте теоремы CAP база данных Cassandra представляет собой хранилище данных AP — она обеспечивает доступность и устойчивость к разделению, но не гарантирует согласованность. Поскольку Cassandra не имеет главного узла, все остальные узлы должны все время оставаться доступными. Однако, Cassandra предлагает модель согласованности в конечном счете — клиенты могут записывать данные на любые узлы в любое время с максимально быстрым устранением несоответствий.

Поскольку несоответствие данных может возникнуть только в случае сетевого разделения и согласованность быстро восстанавливается, Cassandra предоставляет функцию исправления (внешняя ссылка), помогающую узлам вернуться в актуальное состояние. Постоянная готовность позволяет получить высокопроизводительную систему, что во многих случаях перевешивает все недостатки.

Работа с микросервисами

Микросервисы — это слабо связанные между собой компоненты, поддерживающие независимое развертывание, которые имеют собственный стек, включая базу данных и модель базы данных, и взаимодействуют друг с другом по сети. Возможность запуска микросервисов на облачных серверах и в локальных центрах обработки данных сделала их очень популярными компонентами гибридных и мультиоблачных приложений.

Понимание теоремы CAP может помочь вам в выборе оптимальной базы данных в процессе проектирования приложения на основе микросервисов, работающего в нескольких расположениях. Например, если вам важна возможность быстрой доработки модели данных и горизонтального масштабирования, но при этом приемлема согласованность в конечном счете (в противоположность строгой согласованности), вам может подойти база данных AP, такая как Cassandra или Apache CouchDB. С другой стороны, если работа приложения во многом зависит от согласованности данных (например, в случае приложения электронной коммерции или платежного сервиса), вы можете остановить свой выбор на реляционной базе данных, такой как PostgreSQL.

Теорема CAP и IBM Cloud

IBM предлагает широкий спектр услуг полностью управляемых баз данных . Помимо реляционных систем управления базами данных, в IBM Cloud также можно запустить MongoDB, Cloudant (еще одно распределенное хранилище данных AP), Elasticsearch, etcd и другие решения для работы с базами данных.

Чтобы ознакомиться с полным перечнем поддерживаемых баз данных (без каких-либо обязательств), зарегистрируйтесь для получения IBMid и создайте учетную запись IBM Cloud.