CAP теорема для Data Engineer

CAP формулировка

Eric Brewer 2000.

C — Consistency. Все nodes видят same data.

A — Availability. Every request получает response.

P — Partition tolerance. System operates при network failures между nodes.

Утверждение. В distributed system невозможно одновременно guarantee все три. При network partition — choose between C и A.

CP системы

При partition — sacrifice availability, maintain consistency.

Examples:

• HBase, MongoDB (default config).
• ZooKeeper, etcd.
• Most banks.

Поведение. При partition — minority side returns error («cannot serve»). Majority continues.

AP системы

При partition — sacrifice consistency, maintain availability.

Examples:

• Cassandra, DynamoDB, Riak.
• DNS.
• Web cache layers.

Поведение. Both sides serve. Conflicts resolved later (eventual consistency, last-write-wins, vector clocks).

PACELC

Расширение CAP.

If Partition: choose A или C.
Else: choose Latency или Consistency.

Нормально operating system — все равно trade-off latency vs consistency.

• PA/EL. AP с low latency normal time. Cassandra, DynamoDB.
• PC/EC. CP с consistency normal time. Postgres replication.

Применение для DE

OLTP БД. Postgres, MySQL — CP. Strong consistency обязательна для финансов.

OLAP DWH. Часто eventual consistency OK. Read replicas могут lag.

Кэши. AP — Redis cluster, Memcached. Stale data tolerable.

Стриминг. Kafka — CA на partition, AP cross-cluster (mirror maker).

Sufficient. Ни одна system pure C / pure A — design choices, не absolute.

Связанные темы

• CAP теорема для SA
• Транзакции и MVCC для DE
• Database sharding для DE
• WAL и репликация для DE
• Подготовка к собесу Data Engineer

FAQ

Это официальная информация?

Нет. Статья основана на работе Brewer 2000, доказательствах Gilbert / Lynch 2002.

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.