其實不是所有的資料都像 Excel 表格一樣，每一列都要一模一樣的欄位？事實上，並不是所有的資料都適合這種規矩的方式！這就是 NoSQL 登場的原因啦！ 😎
NoSQL 是什麼？
先想像一下：
- 如果 SQL 資料庫像是一本教科書，每一頁的排版都很固定，章節、標題、內容全都不能亂來。
- 那麼 NoSQL 就像一本手繪筆記，你可以隨意畫圖、記重點、畫心智圖樹，甚至有的頁面只寫兩行字，完全不用拘泥於固定的格式！✨
為什麼要用 NoSQL？
簡單來說，有三大理由讓人愛上 NoSQL：
1. 結構超級自由
傳統 SQL 資料庫就像一張正規的表格，必須先設好欄位：名字、年齡、電話......沒設好的話，資料根本塞不進去。
而 NoSQL 呢？完全不受限制，比如商品資料：
- A 商品有「顏色」和「尺寸」。
- B 商品只有「價格」和「品牌」。
可以透過 NoSQL 支援結構不固定的資料模型（例如 JSON 文件），允許同一表中每筆資料的欄位不同。
- 補充： JSON 資料介紹 （我還沒開始學😖）
2. 跑得快，資料太多加伺服器就好
有沒有想過 IG 那種每天幾百萬次的「按讚」「留言」怎麼處理的？NoSQL 最擅長的就是水平擴展（Horizontal Scaling）：需要更大儲存量？沒關係，多加幾台伺服器就好了！輕鬆撐起超大規模的用戶流量。💪
3. 多變的資料結構，你想怎麼存就怎麼存
舉個例子，NoSQL 支援多種模型：
- 文件型（Document-based）： 使用 JSON 一樣，適用於電商網站（如商品資訊）。
- 鍵值型（Key-Value Store）： 使用唯一鍵（Key）對應一個值（Value），可用在即時金融交易。
- 圖型資料庫（Graph-based）： 儲存節點和邊之間的關係，用於分析和查詢關聯性強的數據。像是 Facebook 好友，你可能認識的朋友。
NoSQL 適合誰？
- 你的資料結構多變，像社群媒體、電商平台那樣，每一條貼文都不一樣。
- 你的用戶量爆發式增長，需要快速擴展。
- 你想處理的數據是非結構化的，例如圖片、影片。
NoSQL 的餐廳評價 APP 範例
圖片截圖自
What is a NoSQL Database? How is Cloud Firestore structured? | Get to know Cloud Firestore #1
有一個 APP 使用 NoSQL 存餐廳所有的評價，首先先把餐廳放在一個資料庫，而評價放在另外一個資料庫。每筆評價會標記餐廳代號。使用者也可以編輯自己的個人資料、大頭照。
But ! 因為這個不是 SQL 資料庫，沒有 JOIN 的功能，當使用者更新大頭照時就需要把資料「複製」到 Reviews，還有可能不小心漏掉 。
天啊！怎麼會用那麼笨的方法？用關聯式資料庫就好了啊。但這個好處是，搜尋 reviews 的速度非常快，不需要用 JOIN 再把資料串起來，而且使用者換照片的次數不頻繁，所以當更換時再一個一個複製也無傷大雅。
另外，前面提到 NoSQL 的好處是擴展資料庫非常方便，只要加伺服器就好。
CAP 理論：魚與熊掌的抉擇 🐟
延續 NoSQL 的討論，很多人會問：「為什麼 NoSQL 不像 SQL 那樣，保證所有東西都『完美』？」這就涉及到 CAP 理論，也被稱為分散式系統的「鐵三角」原則。
CAP 理論告訴我們，在分散式系統中，你只能同時滿足三個特性中的兩個，而無法三者兼得。這就是「魚與熊掌不可兼得」的真實寫照。
圖片來源：Sumit Kar's LinkedIn Post, CAP Theorem
什麼是 CAP 理論？
CAP 理論的三個特性分別是：
- 一致性（Consistency，C）
- 每次讀取的資料都一致，即使分散式系統中有多個節點，所有節點的數據狀態都相同。
- 例子： 你在 A 伺服器上更新資料後，立刻去 B 伺服器查詢，看到的結果必須和 A 一樣。
- 可用性（Availability，A）
- 系統總是能夠回應請求，即使部分節點發生故障。
- 例子： 不管伺服器某一部分是否掛掉，使用者仍然能讀取數據（哪怕是舊的數據）。
- 分區容錯性（Partition Tolerance，P）
- 系統能在節點之間的網路斷開（分區）時繼續運行。
- 例子： 在伺服器分散在世界各地的情況下，網路可能斷開，但系統仍需保持某種程度的功能運作。
為什麼不能三者兼得？
在分散式系統中，網路的不穩定是不可避免的(Ｐ會變基礎要求）CAP 理論的三種取捨：
1. CA（一致性 + 可用性，但無法容忍分區網路斷開）
- 系統在分區（如網路斷開）時會完全停擺，因為它無法同時保證一致性和可用性。
- 適用場景： 分區很少發生的情況，例如公司內網。
- 缺點： 無法應對分散式系統的網路問題。
2. CP（一致性 + 分區容錯性，但犧牲可用性）
- 在網路分區發生時，系統選擇犧牲「可用性」，即暫停部分操作，關掉一些服務以維持數據一致性。
- 適用場景： 金融系統、銀行交易等對數據一致性要求極高的場景。
- 缺點： 在網路問題發生時，用戶可能無法存取系統。
3. AP（可用性 + 分區容錯性，但犧牲一致性）
- 在網路分區發生時，系統選擇保證「可用性」，允許不同節點的數據短暫不一致（最終一致性）。
- 適用場景： 社群媒體，對一致性要求較低的場景。
- 缺點： 用戶在短時間內可能看到舊數據。
簡單比喻
想像你和朋友一起開了三個分店，分別賣同樣的商品，你們面臨三個選擇：
- 一致性（C）： 所有分店的商品庫存必須完全相同，哪怕網路斷開也不能有差異。
- 缺點：如果連線中斷，暫停營業。
- 可用性（A）： 確保每個分店都能正常營業，即使庫存資料不完全正確。
- 缺點：用戶可能會看到過期或錯誤的庫存。
- 分區容錯性（P）： 確保即使分店之間的網路不穩定，系統仍能繼續運行。
要選擇哪一項？
沒有絕對，要看業務需求。
- 如果資料一致性極為重要：
選擇 CP，例如銀行系統，寧可暫時不能操作，也要保證交易數據不會錯亂。 - 如果高可用性更重要：
選擇 AP，例如社交媒體，寧可一部分數據稍有延遲，也要保證服務不中斷。
