CAP Teoremi - Distributed Data Store İçindir

Giriş

1998 yılında Eric Brewer adındaki bir profesör tarafından ortaya atılmıştır. Dağıtık veri tabanlarıyla (Distributed Data tore) ilgilidir. Eğer kullandığımız veri tabanı dağıtık değilse CAP geçerli değil. Açıklaması şöyle.

The CAP theorem asserts that in any distributed data store only two out of three guarantees can be provided regarding consistency, availability, and partition tolerance.

BASE İle Olan İlişkisi

Açıklaması şöyle. BASE Properties For Distributed Database Transactions yazısına bakabilirsiniz.

ACID focuses on Consistency and availability.

BASE focuses on Partition tolerance and availability and throws consistency out the window.

1. Tanımlar

Önce tanımlara bakmak gerekir. Kısa bir açıklama şöyle. 

- Availability: All working members in a distributed system return a valid response to any request, without exceptions.

- Consistency: All the clients connected to the system see the same data at the same time, no matter which member they connect to; whenever data is written to a member, it is instantly replicated to all the other members in the system.

- Partition Tolerance: Partition refers to a lost or temporarily delayed connection between the members; partition tolerance refers to continued work of the cluster despite any number of communication breakdowns between the members of the cluster.

Availability mutlaka bir cevap alacağımızı belirtir, ancak aldığımız cevap en son bilgi olmayabilir.

Consistency mutlaka bir cevap alacağımızı belirtir, ayrıca eğer bir cevap aldıysak bunun mutlaka en son son bilgi olduğunu garanti eder

Partition Tolerance  üyeler arasındaki ağda koyma veya gecikme olsa bile her birinin çalışmaya devam edeceğini söyler.

2. CAP Teoremi Neyi Söyle

CAP bize şunu söyler. Aynı anda bu 3 özellikten sadece ikisini sağlayabiliriz. Bir tanesinden feragat etmek gerekir. Şeklen şöyle. Her kenarın kesişimi hangi özellikten feragat ettiğimizi gösterir.

Eğer sadece Consistency ve Availability istersek Partitioning-Intolerance seçiliyor. Bu da dağıtık yapı olmaması anlamına geliyor. Klasik dağıtık yapıda olmayan ACID veri tabanları böyle. Ama zaten konumuz bu değil. Bu yüzden Partition Tolerance özelliğinin mutlaka olacağını varsayıyoruz. Bu yüzden Consistency ve Availability arasında seçim yapmak gerekiyor.

2. Seçilen Özellikler

Şeklen şöyle

Bir başka şekil şöyle. İlk sütunda CA sistemler görülüyor. Yani dağıtık olmayan sistemler. Cp ve AP sistemler ikinci ve üçüncü sütunlarda

2.1 Partition Tolerance + Availability Özelliği Seçilirse

Availability seçilirse, Consistency 'den feragat etmek gerekir çünkü ağdaki kopmalar ve gecikmeler yüzünden veri her yerde aynı anda tek bir değere sahip olamaz.

Bu durumda 

1. BASE yani NoSQL veri tabalarından birisini seçmek gerekiyor. Örneğin Apache Cassandra seçilebilir. Apache Cassandra'nın available olmasının sebebi birden fazla master node olması. Açıklaması şöyle

Cassandra has multiple master nodes. To input data in the other nodes, these master nodes are used. Therefore, the more master nodes a cluster has, the better it will scale. After comparing the both, Cassandra has higher scalability than MongoDB.

Peki AP Özelliği Eventual Consistency Anlamına Gelir mi ?

Hayır gelmez. Çünkü Replication algoritmasının kopmaları dikkate alacak şekilde olması gerekir. Eğer Replication algoritması bunları dikkate almazsa, Eventual Consistency olmaz, Data Loss olur

2.2. Partition Tolerance + Consistency Özelliği Seçilirse

Consistency seçilirse, Availability 'den feragat etmek gerekir yani en son yazılan veriyi okuyamayabiliriz. 

Bu durumda 

1. Dağıtık ACID yani bir anlamda distributed relational (dağıtık ilişkisel) veri tabanlarından birisi. seçilebilir. Açıklaması şöyle

However, MySQL also has another configuration which is a clustered configuration. It prioritizes CP over availability eg. the cluster will shutdown if there are not enough live nodes to serve all the data.

 2. BASE yani NoSQL ancak Consistency özelliğine önem veren veri tabalarından birisi seçilebilir. Örneğin MongoDB seçilebilir. MongoDB'nin consistent olmasının sebebi tek bir master node olması. Açıklaması şöyle.

In MongoDB, there is only one master node. This master node only accepts the input. Apart from this, all the nodes are used as an output. Therefore, if the data has to be written in the slave nodes, it has to pass through the master node.

3. NoSQL ve Consistency İlişkisi

Açıklaması şöyle

The main distinction between database systems is not the language used to query the database, but rather the consistency model of the system. 

4. İlişkisel (Relational) Veri tabanı ve CAP İlişkisi

Açıklaması şöyle. Yani klasik bir ilişkisel veri tabanı olan PostgreSQL, Partition Tolerance özelliğini desteklemiyor.

- PostgreSQL is a CA system.

- Cassandra is an AP system

- Mongo DB is a CA system by default

Different databases have different goals. No matter what data type PostgreSQL offers, it will ultimately be a relational database and will sit within the CA part of the CAP theorem.

Açıklaması şöyle.

Transactions

ACID transactions by nature are typically hard to scale across multiple machines. This is the reason why replication in PostgreSQL or any relational database is done via a Write Ahead Log or WAL log.

This means a transaction is only sent across the wire after it is written to the WAL log, ensuring that there is consistency across different database instances. This is very different from Cassandra's consistency level (BASE) which scales across multiple nodes and uses something called eventual consistency.

Data Models

- Mongo DB is a document store

- Cassandra is a column family store

- PostgreSQL is a relational DB row store

At the end of the day, PostgreSQL is still a relational data model and does not have all the features of a NoSQL database such as an aggregation pipeline.

When you try to model data in PostgreSQL, the best practice is to default to a relational model and only use JSON when it makes sense.

Write Ahead Log

Açıklaması şöyle. Asenkron replication durumunda veri kaybı olabilir.

PostgreSQL Streaming Replication is asynchronous by default, so it is possible to have some transactions committed in the primary node which have not yet been replicated to the standby server. This means there is the possibility of some potential data loss.

This delay in the commit process is supposed to be very small... if the standby server is powerful enough to keep up with the load. If this small data loss risk is not acceptable in the company, you can also use synchronous replication instead of the default.

In synchronous replication, each commit of a write transaction will wait until the confirmation that the commit has been written to the write-ahead log on disk of both the primary and standby server.

This method minimizes the possibility of data loss. For data loss to occur you would need both the primary and the standby to fail at the same time.

The disadvantage of this method is the same for all synchronous methods as with this method the response time for each write transaction increases. This is due to the need to wait until all the confirmations that the transaction was committed. Luckily, read-only transactions will not be affected by this but; only the write transactions.