update nav

docs/LevelDB/01_table___sstable___tablecache.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Table, SSTable & TableCache"
+parent: "LevelDB"
+nav_order: 1
+---
+
 # Chapter 1: Table / SSTable & TableCache
 
 Welcome to your LevelDB journey! This is the first chapter where we'll start exploring the fundamental building blocks of LevelDB.

docs/LevelDB/02_memtable.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "MemTable"
+parent: "LevelDB"
+nav_order: 2
+---
+
 # Chapter 2: MemTable
 
 In [Chapter 1: Table / SSTable & TableCache](01_table___sstable___tablecache.md), we learned how LevelDB stores the bulk of its data permanently on disk in sorted, immutable files called SSTables. We also saw how the `TableCache` helps access these files efficiently.

docs/LevelDB/03_write_ahead_log__wal____logwriter_logreader.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Write-Ahead Log (WAL)"
+parent: "LevelDB"
+nav_order: 3
+---
+
 # Chapter 3: Write-Ahead Log (WAL) & LogWriter/LogReader
 
 In [Chapter 2: MemTable](02_memtable.md), we saw how LevelDB uses an in-memory `MemTable` (like a fast notepad) to quickly accept new writes (`Put` or `Delete`) before they are eventually flushed to an [SSTable](01_table___sstable___tablecache.md) file on disk.

docs/LevelDB/04_dbimpl.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "DBImpl"
+parent: "LevelDB"
+nav_order: 4
+---
+
 # Chapter 4: DBImpl - The Database General Manager
 
 In the previous chapters, we've explored some key ingredients of LevelDB:

docs/LevelDB/05_writebatch.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "WriteBatch"
+parent: "LevelDB"
+nav_order: 5
+---
+
 # Chapter 5: WriteBatch - Grouping Changes Together
 
 Welcome back! In [Chapter 4: DBImpl](04_dbimpl.md), we saw how `DBImpl` acts as the general manager, coordinating writes, reads, and background tasks. We learned that when you call `Put` or `Delete`, `DBImpl` handles writing to the [Write-Ahead Log (WAL)](03_write_ahead_log__wal____logwriter_logreader.md) and then updating the [MemTable](02_memtable.md).

docs/LevelDB/06_version___versionset.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Version & VersionSet"
+parent: "LevelDB"
+nav_order: 6
+---
+
 # Chapter 6: Version & VersionSet - The Database Catalog
 
 In the previous chapter, [Chapter 5: WriteBatch](05_writebatch.md), we learned how LevelDB groups multiple `Put` and `Delete` operations together to apply them atomically and efficiently. We saw that writes go first to the [Write-Ahead Log (WAL)](03_write_ahead_log__wal____logwriter_logreader.md) for durability, and then to the in-memory [MemTable](02_memtable.md).

docs/LevelDB/07_iterator.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Iterator"
+parent: "LevelDB"
+nav_order: 7
+---
+
 # Chapter 7: Iterator - Your Guide Through the Database
 
 Welcome back! In [Chapter 6: Version & VersionSet](06_version___versionset.md), we learned how LevelDB keeps track of all the live SSTable files using `Version` objects and the `VersionSet`. This catalog helps LevelDB efficiently find a single key by looking first in the [MemTable](02_memtable.md) and then pinpointing the right [SSTables](01_table___sstable___tablecache.md) to check.

docs/LevelDB/08_compaction.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Compaction"
+parent: "LevelDB"
+nav_order: 8
+---
+
 # Chapter 8: Compaction - Keeping the Library Tidy
 
 In [Chapter 7: Iterator](07_iterator.md), we saw how LevelDB provides iterators to give us a unified, sorted view of our data, cleverly merging information from the in-memory [MemTable](02_memtable.md) and the various [SSTable](01_table___sstable___tablecache.md) files on disk.

docs/LevelDB/09_internalkey___dbformat.md

@@ -1,3 +1,10 @@
+---
+layout: default
+title: "InternalKey & DBFormat"
+parent: "LevelDB"
+nav_order: 9
+---
+
 # Chapter 9: InternalKey & DBFormat - LevelDB's Internal Bookkeeping
 
 Welcome to the final chapter of our deep dive into LevelDB's core components! In [Chapter 8: Compaction](08_compaction.md), we saw how LevelDB keeps its storage tidy by merging and rewriting [SSTables](01_table___sstable___tablecache.md) in the background. This compaction process relies heavily on being able to correctly compare different versions of the same key and discard old or deleted data.