雲端 MongoDB 之 scale out issue
-
目前部署於雲端之 MongoDB cluster,對雲架構的 scale out ,是否有良好的 solution ?
也就是說,當現有 MongoDB 不敷使用時,雲系統 create 出新的 MongoDB instance,它如何自動加入 cluster 中,隨即擴充 MongoDB 服務量?
-
不敷使用的情況是指儲存容量不足或是系統效能不足?
是寫入瓶頸還是讀取瓶頸?
-
一般而言,儲存容量不足或是系統效能不足在測試階段就應該要部署好了。不敷使用通常是指 "連線數" 已經用完。不管是讀或寫,連線數用完,client 就無法跟 mongodb 連上線,問題就來了。
-
這個情況是需要佈屬數量多一點的 mongos 而連線數又和伺服器本身分配給 mongos 的資源有關係。
如果可以在應用層先處理好,必要時刻才發起連線到 mongos 也能降低無效的連線占用資源問題。
-
『必要時刻才發起連線到 mongos』這個似乎跟目前 mongo client driver 的行為不一樣。mongo driver 從第一次連線開始就會連住 server 不放,以求下一次的使用,不需再耗時去重連。
所以,如果 client 數量超過部署的 mongo server 總連線數,那麼應該很快就會把連線數耗光。
-
這議題有趣了,可能得自幹驅動。
-
嗯。有改過驅動,單支程式用完即斷,每一支新程式就重新連線,效能還真是不彰,更嚴重的是 .... 還是把連線數耗光了。只不過耗光時間往後挪一點而已,不過卻付出很大重連時間成本。
-
如果建立一個中間層的應用程式負責做持續性的連線,統一負責處理資料庫的更新,同時也開 socket 接受原本應用程式的連接,
把原本的隨機連線整合到同一個 pool 裡面,中間層應用程式再連線資料庫整批一次性的處理。
只要把增加了中間層的 Latency time 控制在原本應用程式可以接受的範圍內,這樣可以省去很多的短暫發起連線。
-
DB proxy/router 是可以解決這種問題,不過就得犧牲一點效能,而且也會取決於 proxy 的能力,是否會造成更大的問題,比如效能瓶頸、session keeping、...等等。
-
感覺真的面臨這個大的連線壓力時候,第一線的壓力會先來自於網路,只能用分散式架構把壓力分流掉。
DB Proxy 則必須要應用程式是可以批次作業,對於需要即時反應的會有延遲性的問題,這必須在應用層解決。
以通訊機制來看如乙太網路的隨機大家搶也沒什麼不好,但是效能就是隨線上用戶數量而遞減,而且是非線性的關係。
這種的效能差異鎮起伏比較大,Token-Ring 的方式則是有平均分配還可能比較公平一點。
應用層得考慮實作個 Token 確保即時性的應用,其餘的資料就交給 DB Proxy 慢慢餵進去給資料庫。
-
-
@kevinl 我是用 php 開發,使用 php-mongodb extension 連線。它的行為不是 proxy,也只能單工。之前與 DBA 測試過,就算 socket timeout 機制有作用,idle 一段時間就斷線,它還是會自動連起來,這是目前 php-mongodb extension 的行為。所以一個 php-fpm runner 就會至少佔掉一條連線,目前是無可避免。就算用 haproxy 來做為 mongo proxy,情況一樣。因為 haproxy 只有分流,不是 pool。