# Rocksdb: Write (Continue...)
__*Level*__
__*compaction*__

![left](./student-guide/diagram/RocksDBWrite02_aa_001_20220511.png)

------------------------------------------------------------
Next, we will focus on the way RocksDB files are organized after the data is lost.

Files on disk are organized in multiple layers. Let's call them Level-1, Level-2... Wait, or a simple L1, L2... and so on. A special layer, Level-0 (L0), will contain data that has just been dropped from memory memTable. Reaching 4 will trigger compaction to the next layer, and if the backlog reaches 20, it will trigger a write stall. Each layer (except Level0) is an independent sort result.

At each layer (except Level-0), the data is split into multiple SST files.

The keys in each SST file are in good order. If we need to locate a key, we first find the start and end keys of all files in two parts, locate which file has this key, and then locate the specific file in two parts to locate the key location. In general, it is a binary search of all the keys in that layer.

All non-0 layers have a target size. The goal of compression is to limit the data size of these layers, and the size goal is usually an exponential

Finally, for WAL logs, WAL serializes MemTable operations and stores them in the form of log files on the persistent media. In the event of a crash, the WAL log (log) file can be used to rebuild MemTable to help recover the database to a consistent state. When a MemTable is safely placed on persistent media, the associated WAL log (log) becomes out-of-date and then archived. The final archived logs are deleted from the hard drive after a certain period of time.

At this point, the data has been persisted. We can see that the WAL guarantees that the writes will not be lost at the beginning. Next, let's summarize the general CRUD process of RocksDB:

Write operations
The write operation first needs to write data to the disk log (Log) through the WAL to prevent data loss, and then the data will be written to the memTable in memory. Once the write operation is completed, it only takes 1 disk IO and 1 more memory operation. Significantly improved efficiency compared to multiple random disk IOs in B+ trees. Subsequently, the data in MemTable will be merged into SSTable on disk in batch, and random writes will be changed to sequential sequential write.

Delete operation
When there is a delete operation, it is not necessary to find the corresponding data on the disk like a B+ tree and then delete it. You only need to insert a piece of data into MemTable as a flag, such as delete key: 1233. When the read operation reads this flag in memTable, it will be known that the key has been deleted. Then in log merging, the deleted data will be deleted along with the merging process.

Update operation
The update operation is similar to the delete operation, which only operates on memTable, writes a flag, and then the actual update operation is delayed and completed at the time of the merge.