雲端 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。
