Как называется теорема требований для NoSQL баз данных?

CAP-теорема: фундаментальный принцип распределённых систем и NoSQL

Вы, вероятно, имеете в виду знаменитую CAP-теорему (теорема Брюера), которая является краеугольным камнем при проектировании и выборе распределённых систем, включая NoSQL-базы данных. Её сформулировал профессор Беркли Эрик Брюэр в 2000 году, а позже она была строго доказана.

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

1. Согласованность (Consistency) – все узлы системы видят одни и те же данные в один и тот же момент времени. После выполнения операции записи все последующие операции чтения вернут самое актуальное значение.
2. Доступность (Availability) – система всегда даёт ответ (успешный или неуспешный) на любой запрос, гарантируя, что каждый клиент может читать и писать данные. Даже при частичном отказе системы.
3. Устойчивость к разделению (Partition Tolerance) – система продолжает работать корректно, несмотря на произвольное разделение сети (network partition), когда узлы теряют связь друг с другом.

Практическая интерпретация для NoSQL баз

На практике, поскольку отказ сети (Partition) считается неизбежным событием в распределённых системах, теорема сводится к выбору между C (Consistency) и A (Availability) в условиях разделения. Это и есть тот самый компромисс, который определяет архитектуру и поведение NoSQL-СУБД.

Классификация NoSQL баз по CAP:

// Упрощённая модель для понимания выбора в разных сценариях

type Database interface {
    Read(key string) (string, error)
    Write(key, value string) error
}

// 1. Системы, жертвующие Availability (CP-системы)
// Примеры: MongoDB (в определённых конфигурациях), HBase, Redis Cluster
type CPDatabase struct {
    // При разделении сети блокируют запись на разделённых узлах,
    // чтобы гарантировать консистентность, но становятся недоступными для записи.
}

// 2. Системы, жертвующие Consistency (AP-системы)
// Примеры: Cassandra, DynamoDB, CouchDB, Riak
type APDatabase struct {
    // При разделении сети остаются доступными для чтения и записи на всех узлах,
    // но данные на разных узлах могут расходиться (eventual consistency).
}

Важные уточнения и современный контекст

• Не «2 из 3», а компромисс при разделении: Современная трактовка подчёркивает, что CAP — это выбор в момент сетевого раздела. В штатном режиме система может стремиться обеспечивать все три свойства.
• PACELC-расширение: Более точная модель, которая дополняет CAP. Она гласит: в случае раздела (P) система выбирает между доступностью и согласованностью (A vs C), иначе (Else), в нормальных условиях (Latency vs Consistency) система выбирает между низкой задержкой и согласованностью. Это объясняет, почему многие AP-системы (например, Cassandra) настраиваются на уровень согласованности в каждом запросе (через параметры типа QUORUM).
• Согласованность не бинарна: На практике существует целый спектр моделей согласованности: строгая (strong), линейная (linearizable), сессионная (session), итоговая (eventual) и др. NoSQL базы часто позволяют гибко настраивать этот уровень.

Пример настройки уровня согласованности в Cassandra (CQL):

-- Запись с уровнем согласованности QUORUM (большинство реплик)
INSERT INTO users (id, name) VALUES (1, 'Alice') USING CONSISTENCY QUORUM;

-- Чтение с уровнем согласованности ONE (хотя бы одна реплика)
SELECT * FROM users USING CONSISTENCY ONE;

Почему CAP так важна для разработчика на Go?

При разработке на Go, который часто используется для создания высоконагруженных и распределённых систем (микросервисов, API-гейтвеев), понимание CAP критично для:

• Осознанного выбора хранилища под конкретную задачу. Для финансовых транзакций — lean towards CP. Для логов, аналитики, социального графа — возможно, AP.
• Проектирования отказоустойчивых архитектур. Знание ограничений вашей БД помогает правильно обрабатывать ошибки и задержки.
• Написания корректного кода. Например, при работе с AP-системой вам может потребоваться реализовать механизмы разрешения конфликтов (Conflict-free Replicated Data Types – CRDTs) или стратегии повторных попыток.

Таким образом, CAP-теорема – это не просто абстрактная концепция, а практический фреймворк для принятия решений, который напрямую влияет на надёжность, производительность и архитектуру вашего приложения, построенного на NoSQL базах данных.