MongoDB：分區（簡介 & 自動分區 & 片鍵）

標籤：模式   sof   使用者   分數   添加   lib   src   串連   流量   

分區（增加伺服器，水平擴充）是MongoDB的擴充方式，通過分區能過增加更多的機器來應對不斷增加的負載和資料，還不影響應用。

【簡介】

分區（sharding）是指將資料拆分，將其分散存在不同的機器上的過程。在關係型資料庫中，當一個表太大（超過幾億行資料）時，我們也有分表的做法，和這裡的分區是類似的概念。

手動分區：當我們應用的瓶頸出現在資料庫系統時，如果我們使用的是關係型資料庫，我們通常要進行手動分區。即通過我們的應用程式層代碼去維護與若干個資料庫系統的串連，並且每個串連都是獨立的。我們應用程式層代碼負責屏蔽底層的多個資料庫執行個體，查詢時導向到特定的執行個體上進行，這種方式有個缺點，就是維護起來太麻煩！比如向底層資料庫叢集添加或刪除節點，調整資料分布和負載模式等，都是對我們這層應用程式層代碼提出不小的挑戰！

MongoDB從設計時考慮的就是橫向擴充，其支援自動分區！我們可以很輕鬆的向一個MongoDB資料庫伺服器叢集添加或刪除機器，叢集會自動切分資料、進行負載平衡！

【自動分區】

“片”是一個獨立的MongoDB服務（即mongod服務進程，在開發測試環境中）或一個複本集（在生產環境中）。將資料分區，其思想就是將一個大的集合拆成一個一個小的部分，然後放置在不同的“片”上。每一個“片”只是負責總資料的一部分。自動分區就是：應用程式層根本不知道資料已被分區，也全然不會知道具體哪些資料在哪個特定的“片”上。在MongoDB中，提供了一個路由服務mongos，在分區之前需要先運行這個服務，這個路由服務具體知道資料和“片”的關係。應用程式和這個路由服務通訊即可，路由服務會將請求轉寄給特定的“片”，得到響應後，路由會收集響應資料，返回給應用程式層程式。下面兩幅圖展示了不使用分區和使用分區，使用者發送請求的處理路徑：

分區前：

 

分區後：

 

那我們該何時給我們的老系統（）改進為分區後的新系統（），通常有如下原則：

1》 機器的磁碟不夠用了，資料量太大

2》 單個mongod已經無法滿足寫資料的效能需要了（這裡複習一下，如果想要增加讀效能，較好的方案是採用搭建主從結構，且讓從節點可以響應查詢請求）

3》 想將大量的資料放到記憶體中提高效能，一台機器的記憶體大小永遠有極限（這就是縱向擴充和橫向擴充的區別）

 

【片鍵】

設定分區時，需要從集合中選取一個鍵，用該鍵作為資料拆分的依據。這個鍵就稱為“片鍵”。我們可以提供一個簡單的例子，對於一個儲存人員資訊的集合users，我們要將其分區，選擇的片鍵是人員姓名name，則最後分區的結果就可能為：第一片中存放的人員名稱是A-F開頭的，第二片中是G-P開頭的，第三篇中是Q-Z開頭的。當使用者提交的查詢是：db.users.find({"name" : "jimmy"})，該查詢請求會分配給第二片進行處理；當使用者提交的查詢是：db.users.find({"name" : {"$lt" : "j"}}，則這個查詢請求會被分配給第一片和第二片進行處理；當使用者提交的查詢並不包含片鍵的資訊，則這個查詢會被發送到所有片上進行處理。對於插入操作，路由服務會根據插入文檔的鍵name對應的值將這個請求發送到特定片上進行！這就是片鍵的作用。

隨著資料的增減，可能會出現某一片負載很大，另一片負載輕鬆的情況，對於這種情況，MongoDB也會自動平衡資料和負載，是最後每片的流量基本相同！

對於選擇哪個鍵作為片鍵？有個原則就是，片鍵應該有較多變化的值，如果片鍵設定為性別，只有“男”和“女”兩種值，則這個集合就最多被分為兩片，如果集合太大，這種分區不會最終解決效率的問題！這裡我們可以看出，片鍵的選擇和建立索引時鍵的選擇原則是相似的，實際使用中，通常片鍵就是建立索引使用的鍵！

 

這裡先介紹一下分區的簡介和原理等內容，下一篇我們會搭建自己的第一個分區出來！

MongoDB：分區（簡介 & 自動分區 & 片鍵）