Reading and Writing in Cassandra
Cassandra is a peer-to-peer, read/write anywhere architecture, so any user can connect to any node in any data center and read/write the data they need, with all writes being partitioned and replicated for them automatically throughout the cluster.
To access data in Cassandra, it is key to understand how C* stores data. The hinted handoff feature plus Cassandra’s ACID without the C (Atomic, Isolated and Durable) database are key concepts to understand reads and writes. In C* consistency refers to how up to date and synchronized a row of data is on all of its replicas.
Writes in Cassandra
Here are some key words to know to understand the write path
Partitioning Key — each table has a Partitioning Key. It helps with determining which node in the cluster the data should be stored.
Commit Log —the transactional log. It’s used for transactional recovery in case of system failures. It’s an append only file and provides durability.
Memtable — a memory cache to store the in memory copy of the data. Each node has a memtable for each CQL table. The memtable accumulates writes and provides read for data which are not yet stored to disk.
SSTable —the final destination of data in C*. They are actual files on disk and are immutable.
Compaction —the periodic process of merging multiple SSTables into a single SSTable. It’s primarily done to optimize the read operations.
How is data written?
- Cassandra appends writes to the commit log on disk. The commit log receives every write made to a Cassandra node and these durable writes survive permanently even if power fails on a node.
- Cassandra also stores the data in a memory structure called memtable and to provide configurable durability. The memtable is a write-back cache of data partitions that Cassandra looks up by key.
- The memtable stores writes in a sorted order until reaching a configurable limit and then it is flushed.
- Then it is flushed to a a sorted strings table called an SSTable. Writes are atomic at row level. Meaning…
