mongodb資料庫分布式讀寫操作教程

一. 分布式讀操作

介紹分區叢集和複本集如何影響讀操作的效能。

1.1 分區叢集讀操作

分區叢集允許資料分割到叢集內的不同mongod執行個體上，這對應用程式來說幾乎是透明的。

對於分區叢集，應用程式發出操作與叢集相關的mongos執行個體。

 

 

讀操作直接定向到一個特定的分區上，叢集讀操作是最有效。

查詢到分區集合應該包括集合分區片鍵。 當一個查詢包含分區片鍵，mongos從config server使用叢集中繼資料將查詢路由到分區。

查詢條件包括分區關鍵。查詢路由器mongos將查詢直接到定位到相應的分區。

 

 

如果查詢不包含分區片鍵，mongos將查詢廣播到叢集中的所有分區。 這種分散聚集查詢是非常低效的。對於大型叢集，這種操作是要命的。

 

 

1.2 複製集讀操作

複本集使用讀的優先模式來決定在哪裡以及如何路由讀操作到複本集的成員。

預設情況下，應用程式讀操作在複製集的primary上。從primary讀可以保證文檔的最新版本，因為複製集是非同步複製的。然後，通過分配部分或者全部讀操作到複製集的secondary節點上，可以提高讀取輸送量或減少等待時間，對即時性應用程式需要並不高。

可以通過修改讀操作的優先模式來更改讀的特性。

讀操作的模式有：

讀操作的模式有：

讀模式	描述
primary	預設模式。所有讀操作都從primary節點讀取。
primaryPreferred	在大多數情況下，讀操作從primary節點讀取，但如果primary節點不可用，讀操作從secondary節點讀取。
secondary	所有讀操作都從secondary節點讀取。
secondaryPreferred	在大多數情況下，讀操作從secondary節點讀取，但如果secondary節點不可用，讀操作從primary節點讀取。
nearest	讀操作從複本集網路延遲最小的節點讀取，無論該節點的類型。

根據應用程式的需求，選擇不同的讀操作模式。

最大限度的一致性：在任何情況下，避免讀取到舊資料，使用primary模式。在沒有primary節點，發生在選舉階段，或大部分節點不可用，將阻塞所有的讀取操作。

最大限度的高可用性：儘可能的保證讀操作，使用 primaryPreferred 模式。當有一個primary節點會得到一致性讀，如果沒有，仍然可以查詢secondary節點。

減少等待時間 ：要始終從低延遲的節點讀取，使用nearest。驅動和mongos從最少延遲讀取。nearest不保證一致性。如果複寫延遲，查詢可能返回到期資料。nearest只反映網路的延遲，並不能反映I/O和CPU的負載。

 

 

從secondary節點讀取，並不能反映primary當前的狀態，非同步複製下，secondary節點可能落後primary節點一定的時間。通常情況下，應用程式不要求這種嚴格的一致性，對於高可用性的要求是最多的。

二. 分布式寫操作

1.1 分區叢集寫操作

對於分區叢集分區集合，mongos將應用程式的寫操作直接特定到指定的分區。mongos從config server使用叢集中繼資料將寫操作路由到適當的分區上。

 

 

基於片鍵將資料分區，然後，MongoDB將這些塊分區到分區上， 片鍵決定塊分區的分布情況。這可能會影響叢集寫操作的效能。

 

 

注意：

影響單個文檔的更新操作必須包括片鍵或_id欄位。

影響多個文檔的更新操作，​​在某些情況下更有效，如果有片鍵，但是可以廣播到所有的分區。

如果片鍵的值增加或每個插入減少，所有的插入操作目標是單一的分區。因此，一個單一的分區容量成為限制分區叢集的插入能力。

1.2 複製集寫操作

在複製集下，所有的寫操作在primary節點。所有的寫操作記錄在動作記錄中oplog。oplog是對資料集的可再現序列。secondary節點不斷複製oplog並應用，該過程是非同步。

 

 

大量的寫操作，特別是大量操作，可能會創造一個問題，secondary節點難以從primary節點複製並應用oplog，從而導致secondary節點落後於primary節點。

當secondary顯著落後於primary時，對於正常的複製集來說是個問題，特別是在容錯移轉時，需要復原資料以便達到資料的一致性。

為了避免這個問題，可以自訂寫關注來確認寫到另一個節點上。這提供了一個機會，讓secondary趕上primary。 寫關注可以減緩寫操作的整體進展，但是可以保證了secondary節點目前狀態與primary節點大致相同。

 

 

設定寫關注層級為w:2, 確保寫入到primary節點和至少一個secondary節點上。