資料儲存的三種形態
大多數資料庫分為三個家族。你不需要去背產品——你需要認出哪種形態適合你的問題。
| 型別 | 例子 | 最適合 | 取捨 |
|---|---|---|---|
| 關係型（） | PostgreSQL, MySQL, SQLite | 帶關係的結構化資料；任何與金錢或準確性相關的關鍵場景 | 你必須預先設計 schema；把寫入擴充套件到非常大的規模更難 |
| 文件型 / | MongoDB, Firestore, DynamoDB | 靈活或巢狀的資料、快速迭代、形態各異的記錄 | 容易產生不一致的資料；關係和報表處理起來很彆扭 |
| 鍵值型 | Redis, Memcached, Cloudflare KV | 快取、會話、計數器、按已知鍵的快速查詢 | 無法按內容查詢；通常不是你的事實來源 |
這三種形態以確實不同的方式儲存資料。把它們並排來看：
關係型 (SQL) 文件型 (NoSQL) 鍵值
行 + 列 自包含的資料塊 一鍵 → 一值
┌────┬───────┬──────┐ ┌──────────────────┐ ┌─────────┬─────────┐
│ id │ email │ name │ │ { │ │ key │ value │
├────┼───────┼──────┤ │ id, email, │ ├─────────┼─────────┤
│ 1 │ a@... │ Ana │ │ name, │ │ session │ "x9f2" │
│ 2 │ b@... │ Bob │ │ posts: [ ... ] │ │ count │ "42" │
└────┴───────┴──────┘ │ } │ └─────────┴─────────┘
表彼此 └──────────────────┘ 內部無法查詢 —
相互引用 一切都巢狀著 只能按鍵查詢
把關係型資料庫想像成一組彼此知道如何相互引用的電子表格。你用來跟它對話的語言就是 SQL（Structured Query Language，結構化查詢語言）。對 90% 的專案來說一個好的預設選擇：從關係型資料庫（Postgres）開始。 它成熟、可預測、強制結構化，並能處理真實應用不可避免會長出來的關係。當你的資料確實沒有固定形態時，再去考慮文件儲存；而鍵值儲存則作為一個輔助層（快取），而不是你的主儲存。
要避免的陷阱是憑感覺選。"NoSQL（不使用 SQL 表的資料庫——它儲存靈活、自由形態的記錄）擴充套件性更好"只對一小撮大多數應用永遠碰不到的問題成立，而即便如此，代價也是放棄那些讓資料可信賴的一致性保證。挑選與你的資料相匹配的形態，而不是在系統設計影片裡聽起來最唬人的那個。拿不準時，關係型是穩妥的選擇——快取或文件儲存你以後隨時可以加上，但解開一團亂麻的 NoSQL 資料模型卻很痛苦。