How Cassandra Writes Data?
How can we say Data has been written successfully?
Cassandra writes data in 4 stages.
When Application send request to write data, there is a coordinator which actually hash the data( it’s partitioner role) and create a token and then coordinator identify this token range belongs to which node and it send write request to those nodes.
1. It first write to Commitlog :-
Once request come from coordinator, it first write to commitlog for durability purpose and it survive even in case of power failure.
2. Write to MemTable :-
After writing to Commitlog, it write data to MemTable. The MemTable is a write-back cache of data partitions. The MemTable writes the data in sorted order and once reach the configuration limit it flush the data to SSTable.
3. Flushing the Data from Memtable:-
Once configuration limit of MemTable reached, i.e. commitlog_total_space_in_mb, the MemTable put the data in the queue which is going to be flush to the disk(SSTable).
We can configure the queue with option memtable_heap_space_in_mb or memtable_offheap_space_in_mb in cassandra.yaml file. If the data which is going to flush to disk exceeds the memtable_clean_threshold then Cassandra blocks writes until the next flush succeed. We can manually flush using nodetool flush.
4. Storing Data on disk in SSTable:-
Memtables and SSTables are maintained per table. The commit log is shared among tables. SSTables are immutable i.e. not written to again after the memtable is flushed. Consequently, a partition is typically stored across multiple SSTable files.
Diagram of how Cassandra writes data.