{"id":25549786,"url":"https://github.com/stormdotcom/nosql_lsm","last_synced_at":"2026-01-25T07:03:31.637Z","repository":{"id":271856515,"uuid":"914781464","full_name":"stormdotcom/nosql_lsm","owner":"stormdotcom","description":null,"archived":false,"fork":false,"pushed_at":"2025-01-10T09:50:55.000Z","size":9,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-05-30T17:48:21.260Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/stormdotcom.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2025-01-10T09:44:10.000Z","updated_at":"2025-01-10T09:50:58.000Z","dependencies_parsed_at":"2025-01-10T11:05:11.764Z","dependency_job_id":null,"html_url":"https://github.com/stormdotcom/nosql_lsm","commit_stats":null,"previous_names":["stormdotcom/nosql_lsm"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/stormdotcom/nosql_lsm","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stormdotcom%2Fnosql_lsm","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stormdotcom%2Fnosql_lsm/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stormdotcom%2Fnosql_lsm/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stormdotcom%2Fnosql_lsm/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/stormdotcom","download_url":"https://codeload.github.com/stormdotcom/nosql_lsm/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stormdotcom%2Fnosql_lsm/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28747308,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-25T05:12:38.112Z","status":"ssl_error","status_checked_at":"2026-01-25T05:04:50.338Z","response_time":113,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-02-20T10:20:18.250Z","updated_at":"2026-01-25T07:03:26.629Z","avatar_url":"https://github.com/stormdotcom.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Database Components Documentation\n\n## 1️⃣ Write-Ahead Log (WAL)\n\n### Purpose:\nThe Write-Ahead Log (WAL) ensures durability and data integrity by logging every write operation before applying it to the in-memory structure (MemTable). This protects data against system crashes.\n\n### How It Works:\n1. Every write (PUT or DELETE) is first appended to the WAL on disk.\n2. Once logged, the write is applied to the MemTable.\n3. In case of a system failure, the WAL is replayed to recover the data.\n\n### Advantages:\n- **Guarantees durability:** Data is safe even if the system crashes.\n- **Provides fast recovery:** Logs are replayed to recover data.\n\n### Example Workflow:\n1. Client sends `PUT(\"key1\", \"value1\")`.\n2. Append `\"key1:value1\"` to the WAL.\n3. Insert `\"key1\":\"value1\"` into the MemTable.\n4. On a crash, the WAL is read, and the MemTable is rebuilt.\n\n---\n\n## 2️⃣ MemTable (In-Memory Tree)\n\n### Purpose:\nThe MemTable is a fast, in-memory data structure (e.g., Red-Black Tree, AVL Tree) that stores active data.\n\n### How It Works:\n1. New writes are added to the MemTable after being logged in the WAL.\n2. When the MemTable grows beyond a threshold, it is flushed to disk as an SSTable.\n3. The MemTable supports quick reads and writes.\n\n### Advantages:\n- **High write throughput:** Operations are in-memory.\n- **Efficient data retrieval:** Sorted structures optimize lookups.\n\n### Example Workflow:\n1. `PUT(\"key2\", \"value2\")` → WAL → MemTable.\n2. MemTable reaches size limit → Flushed to SSTable.\n\n---\n\n## 3️⃣ SSTables (Sorted String Tables)\n\n### Purpose:\nSSTables are immutable, sorted files stored on disk, created when the MemTable is flushed.\n\n### How It Works:\n1. MemTable data is written to disk in a sorted format.\n2. Each SSTable is immutable and optimized for sequential reads.\n3. An index is maintained for faster lookups.\n4. Over time, many SSTables are created and later merged by compaction.\n\n### Advantages:\n- **Efficient storage:** Data is stored in a sorted format.\n- **Simplifies writes:** No in-place updates required.\n\n### Example Workflow:\n1. MemTable flushes sorted data → `sstable_1.db`.\n2. Newer writes go to MemTable → Flushed into `sstable_2.db`.\n\n---\n\n## 4️⃣ Bloom Filter\n\n### Purpose:\nA Bloom Filter is a space-efficient, probabilistic data structure used to quickly check if a key might exist in the database.\n\n### How It Works:\n1. Each key is hashed using multiple hash functions.\n2. Bits are set in a bit array based on these hashes.\n3. On a read:\n   - If any bit is unset, the key definitely does not exist.\n   - If the bits are set, the key might exist → Check SSTables.\n\n### Advantages:\n- **Reduces disk I/O:** Filters out non-existent keys.\n- **Space-efficient.**\n\n### Limitations:\n- False positives are possible (key might exist when it doesn’t).\n- False negatives are impossible.\n\n### Example Workflow:\n1. Insert `\"key1\"` → Hashes → Bits set.\n2. `GET(\"key2\")` → Bloom filter returns false → Skip SSTable lookup.\n3. `GET(\"key1\")` → Bloom filter returns true → Search SSTable.\n\n---\n\n## 5️⃣ Compaction\n\n### Purpose:\nCompaction is a background process that merges multiple SSTables, removes duplicate entries, and reclaims space.\n\n### How It Works:\n1. Multiple SSTables are merged into a new, sorted SSTable.\n2. Duplicate keys are replaced by the most recent value.\n3. Deleted keys (tombstones) are permanently removed.\n4. Older SSTables are deleted after merging.\n\n### Advantages:\n- **Reduces read amplification:** Minimizes the number of SSTables.\n- **Frees up disk space:** Removes redundant data.\n- **Optimizes reads:** Keeps data sorted.\n\n### Types of Compaction:\n- **Minor Compaction:** Merges small SSTables.\n- **Major Compaction:** Merges all SSTables into one.\n\n### Example Workflow:\n1. `sstable_1.db` → `{key1:value1, key2:value2}`\n2. `sstable_2.db` → `{key2:value3, key3:value4}`\n3. Compaction merges → `{key1:value1, key2:value3, key3:value4}`\n4. Deletes `sstable_1.db` and `sstable_2.db`.\n\n---\n\n## 🔄 Overall Data Flow\n\n### Write (PUT):\n1. Log to WAL → Write to MemTable → Bloom filter updated.\n2. MemTable flushes to SSTable when full.\n\n### Read (GET):\n1. Check Bloom Filter → MemTable → SSTables (newest to oldest).\n\n### Delete (DELETE):\n1. Insert a tombstone marker in the MemTable.\n2. Tombstones are cleaned during Compaction.\n\n### Recovery:\n- Replay WAL to restore MemTable after a crash.\n\n---\n\n## 📊 Advantages of LSM Tree-based Databases\n\n### ✅ High Write Throughput:\n- Sequential writes in WAL and MemTable are fast.\n\n### ✅ Efficient Reads:\n- Bloom filters and sorted SSTables allow quick lookups.\n\n### ✅ Space Efficiency:\n- Compaction removes redundant data and optimizes storage.\n\n### ✅ Fault Tolerance:\n- WAL ensures durability and crash recovery.\n\n---\n\n## 📝 Conclusion\nThe LSM Tree architecture with its core components—WAL, MemTable, SSTables, Bloom Filter, and Compaction—provides a scalable and efficient way to handle large-scale data in NoSQL databases. This structure balances the needs for high write throughput, efficient reads, and data durability.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstormdotcom%2Fnosql_lsm","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fstormdotcom%2Fnosql_lsm","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstormdotcom%2Fnosql_lsm/lists"}