1      
背景
我們知道資料是一個公司的命脈，隨著業務越做越大，資料量也會越來越大，計算也會越來越複雜，效能，可靠性，可擴充套件性的需求就會越來越強烈，這個時候一個集中式的資料庫顯然已經滿足不了需求了。對於技術決策者來說有兩條路可以走，第一：按照現有的大型資料庫的解決方案，比如SQL
SERVER Cluster或者Oracle RAC等,但是這也就等於走上了一條燒錢的道路，小則幾十萬，大則上百萬乃至更多；第二：使用真正能夠擴充套件的分散式資料庫，利用中小型伺服器甚至是PC機的累加來替代大型的伺服器，這也是很多公司希望的，卻苦於沒有合適產品，現在有了ClusterKiller，用它真正能給您帶來：      
高效能，高可用性，高擴充套件性，高性價比。

http://www.mediafire.com/?bd0bdjm2gxh
介紹的錄影版本
http://www.mediafire.com/?0tygenydtdg
demo的錄影版本
http://www.mediafire.com/?bhfalz09i4e 試用版
2      
方案比較
2.1    SQL SERVER的叢集模式


這種結構只能說是一種故障轉移的機制，當有一個節點出現問題後把負載轉移到另一個節點上。在負載能力上和擴充套件性上沒有任何辦法，而且還浪費了硬體資源
2.2    Oracle Real Application Clusters
(RAC)

Oracle Rac最多可支援64個節點，基本上算是解決了效能，擴充套件性的問題了，但是它在儲存上還是一個單點，且不說出現故障怎麼辦，IO也可能會成為效能瓶頸。 我們都知道一個數據庫大到一定程度的時候，在物理上分割槽才能從根本上解決問題，對幾十萬資料進行查詢和幾百萬上千萬的資料進行查詢在系統的消耗上以及響應時間上有著幾何級的降低。
2.3    Cluster Killer
 
 
從圖例中可以看出，下面的像網格一樣的機器叫資料層，每個機器上儲存著資料全集的一個分割槽，每一行組成一個數據全集，每一列是某個分割槽的多份相同的資料從而達到查詢時負載均衡的效果，同時也是高可用性的保障：某個列的機器出現問題後其他的機器會負載訪問。為了不讓這樣一個複雜的結構暴露給應用程式，在資料層上面又放了一層機器叫中間層，中間層機器的資料庫中駐留著的中介軟體來處理SQL語句，根據SQL語句的型別和條件來決定由哪些機器來提供服務。在中間層的外面加一個負載均衡裝置， 這樣應用程式或者開發/維護的人員通過負載均衡裝置連線到中間層的任意一臺機器上操作，感覺就像還在使用原來的一個數據庫那樣，易用性非常好。以下從各個角度具體的說明一下：
l        
開發：中介軟體是宿主在資料庫中的，所以面對資料庫寫SQL語句的方式沒有改變，只需要把SQL語句從語法的角度上封裝一下即可。還是利用原有的資料庫的管理工具，不需要使用的新的管理工具，不需要改變原有的使用習慣，不需要學習新的知識。
l        
資料庫維護：對於維護表，儲存過程，安全等資料庫物件還是像使用一個數據庫那樣在中間層的任意一臺機器上執行，中介軟體會抓取到更改並分發到其他的機器上。不會增加額外的工作量。
l        
機器維護：因為這個結構比集中式的結構在機器的數量上要增加了很多，所以在機器層面上的維護成本比以前要有所增加。不過對於機器的維護不會影響整個結構的可用性，只需要在中間層的任意一臺機器上更改一下配置就可以把某臺機器新增到結構中或從結構中移出。
l        
診斷：當出現異常後會明確的指定出錯原因以及出錯的機器，另外還有執行日誌詳細的記錄每個執行步驟的細節。
l        
分割槽：支援多種資料型別的分割槽，分割槽方式有靜態分割槽和線形增長兩種方式。靜態分割槽不言而喻就是一開始就要規劃好分割槽的個數；線形增長方式就是一開始只有一個或少數幾個分割槽列，隨著資料量和訪問的增長的時候再新增新的分割槽從而達到了線性擴充套件的效果
l        
總結：中介軟體的定位和作用是隻是把很多的資料庫伺服器聯合起來最終實現高擴充套件性，高可用性以及高效能。許多關鍵的資料庫技術比如事務，連線池，鎖，安全等還是依靠資料庫來完成，無論從研發成本還是實施的風險都降到最低。
 
2.4    指標比較
l        
故障轉移/可靠性
n        
SQL SERVER Cluster：能做到前面的計算節點的故障轉移，後面的儲存裝置還是單點
n        
Oracle RAC：能做到前面的計算節點的故障轉移，後面的儲存裝置還是單點
n        
Cluster Killer：從每個維度上都是可擴充套件的，所以無論從哪個維度上的機器損壞以後都能找到替代者從而實現故障轉移。
l        
負載均衡
n        
SQL SERVER Cluster：從它的工作機制上可以看出它的兩個節點只能有一個處於工作狀態，所以沒有負載均衡能力
n        
Oracle RAC：它前面的幾個計算節點是可以同時提供服務的，但是後面的儲存裝置只有一個。所以說是計算能夠均載，儲存不能均載
n        
Cluster Killer：即能夠計算均載也能儲存均載
l        
擴充套件性
n        
SQL SERVER Cluster：只能夠兩個計算節點帶一個儲存組成
n        
Oracle RAC：最多64個節點帶一個儲存組成
n        
Cluster Killer：每個維度上都能擴充套件，而且能夠根據資料的增加線形擴充套件，最小用兩臺機器就可以搭建起來，另外每個機器之間的關係是鬆散耦合的，擴充套件起來不需要複雜的安裝，配置。
l        
硬體要求
n        
SQL SERVER Cluster：因為要使用能夠連線儲存裝置的伺服器，而這類伺服器的配置都很高，都是中高檔伺服器，價格不菲。而且還有一個節點在正常情況下是閒置的，所以價效比低
n        
Oracle RAC：它的硬體配置要求同上，但是起碼沒有閒置的資源，價效比中
n        
Cluster Killer：不需要每個機器的緊密耦合，對機器的配置沒有要求，用買一個叢集的錢可以買幾十臺小型伺服器或者上百臺的PC機，Google的分散式結構已經驗證了它的高性價比。
 
3      
成功案例
3.1    某大型求職/招聘網站
l        
專案背景：給企業方使用的一個搜尋個人簡歷的系統，特點是資料量大，查詢條件複雜，更新頻繁。具體資料為：簡歷主表700萬，子表從1600萬到2000萬不等；每天查詢12萬次，40%的查詢條件中帶有關鍵詞；個人使用者每天新增/更新簡歷的事務數為120萬次。
l        
解決方案：使用30臺DELL 2950小型PC伺服器搭建起分散式資料庫結構。
l        
效能測試資料：
n        
測試模型：查詢
n        
查詢條件：大於等於線上使用者的實際條件
n        
測試工具：LoadRunner8.0
n        
測試時間：20小時
n        
併發數：50
n        
響應時間：平均1.5秒，90%的響應時間在1.9秒以下，方差：1.1
n        
查詢次數：成功487325，超時：98，沒有其它型別錯誤
l        
收益：
n        
因為元件不會影響業務邏輯，所以業務程式不用重構，只用2天就升級到新的架構上
n        
查詢時間從原來的10秒縮減到不到1秒，92%的查詢在秒以下，大大提高客戶體驗
n        
真正的7*24的持續提供服務
n        
系統的擴充套件能力大大增強，使得客戶有能力上原來不能上的更復雜的業務邏輯，建立更好的搜尋模型，從而提升了客戶在行業內的競爭實力。