雲端 MongoDB 之 scale out issue


  • Lv 1

    目前部署於雲端之 MongoDB cluster,對雲架構的 scale out ,是否有良好的 solution ?

    也就是說,當現有 MongoDB 不敷使用時,雲系統 create 出新的 MongoDB instance,它如何自動加入 cluster 中,隨即擴充 MongoDB 服務量?


  • 註冊用戶

    不敷使用的情況是指儲存容量不足或是系統效能不足?

    是寫入瓶頸還是讀取瓶頸?


  • Lv 1

    一般而言,儲存容量不足或是系統效能不足在測試階段就應該要部署好了。不敷使用通常是指 "連線數" 已經用完。不管是讀或寫,連線數用完,client 就無法跟 mongodb 連上線,問題就來了。


  • 註冊用戶

    這個情況是需要佈屬數量多一點的 mongos 而連線數又和伺服器本身分配給 mongos 的資源有關係。

    如果可以在應用層先處理好,必要時刻才發起連線到 mongos 也能降低無效的連線占用資源問題。


  • Lv 1

    『必要時刻才發起連線到 mongos』這個似乎跟目前 mongo client driver 的行為不一樣。mongo driver 從第一次連線開始就會連住 server 不放,以求下一次的使用,不需再耗時去重連。

    所以,如果 client 數量超過部署的 mongo server 總連線數,那麼應該很快就會把連線數耗光。


  • 註冊用戶

    這議題有趣了,可能得自幹驅動。


  • Lv 1

    嗯。有改過驅動,單支程式用完即斷,每一支新程式就重新連線,效能還真是不彰,更嚴重的是 .... 還是把連線數耗光了。只不過耗光時間往後挪一點而已,不過卻付出很大重連時間成本。


  • 註冊用戶

    如果建立一個中間層的應用程式負責做持續性的連線,統一負責處理資料庫的更新,同時也開 socket 接受原本應用程式的連接,

    把原本的隨機連線整合到同一個 pool 裡面,中間層應用程式再連線資料庫整批一次性的處理。

    只要把增加了中間層的 Latency time 控制在原本應用程式可以接受的範圍內,這樣可以省去很多的短暫發起連線。


  • Lv 1

    DB proxy/router 是可以解決這種問題,不過就得犧牲一點效能,而且也會取決於 proxy 的能力,是否會造成更大的問題,比如效能瓶頸、session keeping、...等等。


  • 註冊用戶

    感覺真的面臨這個大的連線壓力時候,第一線的壓力會先來自於網路,只能用分散式架構把壓力分流掉。

    DB Proxy 則必須要應用程式是可以批次作業,對於需要即時反應的會有延遲性的問題,這必須在應用層解決。

    以通訊機制來看如乙太網路的隨機大家搶也沒什麼不好,但是效能就是隨線上用戶數量而遞減,而且是非線性的關係。

    這種的效能差異鎮起伏比較大,Token-Ring 的方式則是有平均分配還可能比較公平一點。

    應用層得考慮實作個 Token 確保即時性的應用,其餘的資料就交給 DB Proxy 慢慢餵進去給資料庫。


  • 註冊用戶

    @Triton

    使用該驅動的連線是已經使用裡面的連接池進行連線的嗎?

    有沒有調整過 Socket timeout 的參數?

    這篇可以參考看看 

    本帖下載内容已隐藏,请登入以查看隐藏内容!


  • Lv 1

    @kevinl 我是用 php 開發,使用 php-mongodb extension 連線。它的行為不是 proxy,也只能單工。之前與 DBA 測試過,就算 socket timeout  機制有作用,idle 一段時間就斷線,它還是會自動連起來,這是目前 php-mongodb extension 的行為。所以一個 php-fpm runner 就會至少佔掉一條連線,目前是無可避免。就算用 haproxy 來做為 mongo proxy,情況一樣。因為 haproxy 只有分流,不是 pool。


登录后回复
 

与 萌阔论坛 的连接断开,我们正在尝试重连,请耐心等待