目前公司的應用服務與資料庫在同台伺服器運行。
公司計劃 User <-> 應用伺服器 <-> 資料庫伺服器 分離成三層式架構甚至分散式。
User <-> 負載平衡 <-> 應用Server(多台) <-> 資料庫系統
但怕資料庫伺服器還是負載,所以在加上一台負載平衡
User <-> 負載平衡 <-> 應用Server(多台) <-> 負載平衡 <-> 資料庫系統(多台)
1.這樣是否架構是否可行?
2.在資料庫伺服是多台下時,是要執行分散式資料庫設計(以拆資料表結構方法),以SQL程式分配寫入不同資料庫伺服器的表位置?
2-1.那前方就不用掛負載平衡嗎? 因為已經將各功能的表分散負載
3.若是前方是有掛負載平衡對應多台資料庫,每台資料庫伺服器的資料即時同步,是使用Sql Server 的復寫方式還是鏡像技術?就不用重新設計拆資料表?
ymtangg提到:
負載平衡 <-> 資料庫系統(多台)
別鬧了, DB 哪有人這樣做負載平衡的...有哪家的 Load Balancer 可以讓你這樣用?
應該要組成 DB Cluster 才對....
在 Cluster 的環境中, DB 主機可以有很多台, 但是大家的後端都接到同一個外部儲存體 (通常是 SAN), 所有主機都寫入同一個儲存體內的一個 DB 而已, 也因為只有一個儲存體, 一個 DB, 所以主機之間根本沒有同步的需要.
目前公司的應用服務與資料庫在同台伺服器運行
先分了再說
目前家裡的 [載小孩上課] 與 [上班工作] 用同一台 [小轎車] 運行
我是否要買 大巴士 + 平衡派遣車系統 + 大7 + 法拉利 ?
回答您的問題如下:
1.如同Raytracy大所言,負載平衡設備是不能解決資料庫負載過重的問題,但DB Server效能不足的原因很多,應詳細探究為何效能不足,架DB Cluster能解決部份問題,但不一定能帶來太大的效能上的改進。
2.拆Table結構是一個方法,通常是用在資料量特大的Table才建議,但用這種方式程式開發人員保證會很痛苦,如果真要採取這種架構,建議您程式架構要多一層資料存取層,商業物件不能直接下SQL存取資料庫資料,要透過資料存取層元件來存取資料庫資料,才能避免程式設計師的人為錯誤。
2-1.是
3.還是建議您先分析資料庫效能瓶頸可能會出現在那裡再來決定架構,根據我個人經驗,Disk I/O是最大的問題,而造成Disk I/O的原因通常是Index沒設好或程式設計師的SQL指令沒考慮到因資料長大產生的效能問題,這些問題都先排除後再考慮作資料庫的覆寫或鏡像,將複雜的查詢指令、BI報表及Data Mining的資料來源指向覆寫或鏡像出來的那台主機,這樣應該就可以解決您的問題。
1.理論上可以行的通
但是通常沒有人在作DB 的 LB
不過沒人做不表示不能做,因為小弟的系統有把DB 接LB
但是只是把它當熱切換器而己
如果資料量大到一台DB無法負擔的話
考量拆DB的時後首要考量是你資料的同步該如何處理
2.不建議 速度會太慢
2.1 MYSQL 有M-S、M-M、讀寫分離等等技術
3.建議直接拿四台SERVER做CLUSTER
在做資料庫多台併行前要先決定你的資料一致性要多高
如果可以容忍有時間差的同步
可以考慮Big Table 架構的資料庫來進行處理
否則就是加快取吧~~
盡量把 讀/寫 的任務分散開來做