「我應該使用 SQL 還是 NoSQL？B 樹還是 LSM 樹？」如果您曾經為您的應用程式選擇合適的資料庫而感到不知所措，那麼您並不孤單。每個資料庫的背後都有一個豐富的儲存引擎和事務協議生態系統——正確的選擇可能意味著極快的效能和痛苦的瓶頸之間的區別。
在這篇部落格中，我們透過故事的視角進入資料庫內部的世界，並探索 MySQL、MongoDB、Cassandra 和 PostgreSQL 等系統在底層是如何運作的。
讓我告訴你一個故事。
這一切都始於我為一個快速發展的電子商務應用程式設計後端系統時。它需要處理數千個並髮用戶、即時產品庫存更新、個人化推薦以及比「缺貨」更新更快的儀表板。和我之前的許多開發人員一樣，我也遇到了這個問題：
“我應該使用哪個資料庫？”
接下來是對資料庫內部的深入探究——在這個世界裡，儲存引擎相互衝突，事務以微妙的同步進行，選擇並不總是黑白分明的。
這篇文章就是那段旅程——也許，它會幫助你找到自己的答案。
📁 資料庫幕後
乍一看，資料庫看起來很簡單。您插入資料。你去查詢一下。也許更新或刪除幾行。
但在引擎蓋下，它是一台瘋狂的機器——由如下層組成：
-
傳輸：你的查詢如何傳輸到伺服器
-
查詢解析器和優化器：你的 SQL 其實變成了什麼
-
執行引擎：一切完成的地方
-
儲存引擎：核心、保險庫、讓一切成為可能的東西
我們的旅程才真正開始。
🍊 儲存引擎對決：B 樹 vs LSM 樹
🎓 經典英雄：B 樹
想像一座古老的圖書館，裡面的各個部分排列整齊，抽屜都有標籤。那是一棵 B 樹。
高效、有條理且經過時間考驗。每個插入件都知道要放到哪裡。每個查詢都能快速找到所需內容。
它的工作原理如下：
-
您的資料儲存在已排序的區塊中
-
每次讀取都很快（像
O(log n)一樣快） -
更新發生在原地——這意味著一些隨機的磁碟 I/O，但這對 OLTP 系統來說沒問題
MySQL（InnoDB）和PostgreSQL等資料庫喜歡 B 樹。當您需要強一致性、快速尋找和ACID 事務時，它們非常可靠。
但…
🔥 年輕的顛覆者：LSM 樹
然後你會遇到 LSM 樹－對數結構合併樹。
這個不需要就地更新。它首先將所有內容寫入內存，然後將其以稱為SSTables 的排序區塊形式刷新到磁碟。它會不時地透過合併進行清理 — — 這個過程稱為「壓縮」 。
這就像在便箋簿上寫筆記，然後稍後寫一本乾淨的筆記本。
結果如何？超快的寫入效能。非常適合日誌、指標、物聯網流和其他寫入密集系統。
LSM Trees 為Cassandra 、 RocksDB 、 HBase甚至MongoDB的部分提供支援。
⚖️ 當你必須做出選擇時
我感覺自己就像置身於一場西部決戰之中：
|如果…則 B 樹獲勝 |如果…則 LSM 樹獲勝 |
|------------------------------|------------------------------|
|讀取頻繁 |寫入頻繁 |
|您需要遵守 ACID |最終一致性是可以的
| OLTP 風格的交易 |流或時間序列資料|
但事情還沒結束。一個好的資料庫不僅涉及讀取或寫入。
🔐 交易掛毯
還記得每一部搶劫電影中時機就是一切的那一刻嗎？
交易就是這樣的。您需要您的操作具有原子性、一致性、隔離性和持久性- 又稱為ACID 。
✪️ SQL 資料庫（關係型）
在 MySQL 或 PostgreSQL 等系統中，這是透過以下方式處理的：
-
撤銷日誌
-
WAL（預寫日誌）
-
MVCC（多版本並發控制）
一切都被鎖定、追蹤且可逆。
🌐 NoSQL 資料庫
相較之下，Cassandra 和 DynamoDB 等系統更傾向於最終一致性——它們追求BASE （基本上可用、軟狀態、最終一致性）。
它們的運作方式就像最終同步的筆記本一樣：
更新到達一個節點，其他節點在後台跟進。速度快、分佈廣，但不太嚴格。
🧵 關於並發的討論帖
並發使得事情變得更加棘手。
使用B 樹，可以透過仔細的鎖定來控制並發性：
-
共享鎖、排他鎖、甚至更新鎖
-
B-Link 樹（巧妙的增強功能）讓讀取在寫入過程中也能流暢進行
使用LSM 樹，它更加無鎖：
-
MemTables 並發寫入
-
SSTable 是不可變的
-
壓縮是後台工作
這就像是將銀行金庫與旋轉門系統進行比較。
🧬 混合時代
在現實世界中，不存在一個萬能的資料庫。
有些系統開始結合兩者的優點：
-
MySQL有RocksDB插件
-
MongoDB切換到類似 LSM 的引擎（WiredTiger）
-
Aurora將 SQL 相容性與 NoSQL 效能融為一體
🧠 我的外賣
選擇正確的資料庫並不關乎趨勢，而是關於權衡。
問問自己：
-
您的工作量是讀重還是寫重？
-
您需要嚴格的交易嗎，還是速度更重要？
-
您是否正在處理結構化業務資料或數百萬個串流事件？
一旦你回答了這些問題，你的儲存引擎幾乎就會自行選擇。
✍️ 最後的想法
您的程式碼中是否有那行「插入使用者」？它開啟了跨越數十年的邏輯和工程輝煌。
了解資料庫內部結構使我成為更好的後端工程師——希望現在它也能為您做同樣的事情。
原文出處：https://dev.to/dhanush___b/how-to-choose-the-right-db-for-your-application--c7h
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
