【資料庫寶典 - MongoDB】基礎介紹

2023/08/08閱讀時間約 5 分鐘

我們在「【資料庫寶典】什麼是NoSQL？能吃嗎？」有談到一些NoSQL的特性，雖然本質上有所差異，但兩方技術發展的產品也都開始互相支援了，比如說MongoDB後來也發展出類SQL語法讓熟悉SQL的開發者可以降低進入門檻，而SQL、postgresql…等也紛紛納入一些NoSQL的元素，雙方都有開始接納不同陣營的開發者，就讓我們來好好了解一下MongoDB吧！

與RDBMS的對應

圖片來源…

SQL有join, 那mongo呢?

Embedded Document。
Document reference Document。
Aggregate & $lookup。

特性

Schema Free, 因應各種不同結構的資料來源。
反正規化，減少過多的表。
高度相容於javascript, 並以json作為儲存格式。
讀取效能高於寫入效能。
Sharding機制, 可以將資料水平切割。

適用場景

網站登入/登出。
快取。
易擴充的系統。
Event log。
關聯性較簡單、業務邏輯單純。

不適用場景

高交易需求的系統, 銀行/會計系統, 不嚴謹保證ACID。
BI應用。

Replica Set

MongoDB 是 NoSQL 的一種，因此也有提供這種高可用性架構。這在 MongoDB 的術語中被稱為 Replica Set。

典型的架構

圖片來源…

預設所有的請求都是對 Primary 節點進行。
Client也可以指定Secondary做為讀取節點。
資料會自動複製到另外兩組 Secondary 節點。
這些節點彼此透過 Heartbeat (每隔一段時間試探節點是否存活的方式) 檢測狀態，正常的情況每 2 秒會送出 Heartbeat，若是超過 10 秒沒有回覆，代表連線故障。如下：

圖片來源…

當主要連線的節點發生故障時, mongo有自己的機制, 透過選舉的方式會選出一台 Secondary 成為 Primary 接手工作，這樣的能力稱為 Automatic Failover，如下：

圖片來源…

primary到secondary的切換過程中，這一段時間，mongodb是無法提供寫操作的。因此這個時候應用程式需要判斷這些錯誤，然後做retry。

Arbiter

一個 Replica Set 中可以有零個或一個 Arbiter。
不實際儲存資料內容，僅參與選舉的投票，為的是讓選舉可以達成有效人數。
較節省硬體資源。

圖片來源…

MongoDB Sharding 簡介

圖片來源…

每一個Shard都是由獨立的mongod 實體或者 Replica Set 所構成。
Sharding 機制本身是不負責備份的。
建議使用 Replica Set 來搭建 MongoDB Sharded Cluster，如下。

Sharded Cluster 運作機制

圖片來源…

Router: 主要處理Client端的請求, 並存取Config Servers來決定要往哪個Shard來存取資料。
Config Servers: 儲存集群的位置、資料及分片的關係，建議要有三個實體以上，因為Meta太重要了。
Shard: 實際儲存資料的地方, 可以是單一的mongod也可以是Replica Set。

角色及權限控管(Role Base Access Controller)

圖片來源…

對每個創建的user設置對應的角色:

use test // 到test這個db底下建立user
db.createUser({
  user: "boss",
  pwd: "boss",
  roles: [
    {
      role: "userAdminAnyDatabase",
      db: "admin",
    },
  ],
});

也可以自訂角色來對db進行更細部的控管

建立的角色也能繼承其他角色的權限。
每個角色可以對db、collection定義可以執行的操作。

db.createRole({
  role: "customRole", // 自訂的角色
  privileges: [
    {
			// 對哪個db裡面的哪個collection配置允許的操作
      resource: { db: "users", collection: "usersCollection" }, 
      actions: ["find"], // 允許的操作
    },
  ],
  roles: [],
});