Baron Schwartz創建了一個關於MMM使用情況的討論，並迅速轉向到一般集群的辯論，正如Florian Haas在他的博客上寫的，這不僅僅是DRBD與MySQL復制進行對比的問題。
你認為通過一些像MMM等零碎的東西拼湊起來的方案是數據庫集群嗎?或者是整合了一些東西我們就可以叫它集群了嗎?這是決定開源數據庫集群未來的核心問題。
我個人對這個問題非常感興趣，我設計的Tungsten集群認為答案就是兩個最根本的變化。首先，集群解決方案在不斷發展演變，反過來，它會對現有的集群產生非常大的變化;第二，對於大部分用戶而言，新的集群方案要比從多個獨立的塊構建起來的解決方案要好得多。
要知道為什麼，讓我們從人們使用開源數據庫的歷史談起吧，為什麼過去十年左右他們一直關心集群，開源數據庫有廣泛的用戶，小到中型業務應用如內容管理系統是一個非常大的部分，大型網站如Facebook或GameSpot是另一類例子。有大量的定制應用介於兩者之間，它們不適合使用單個采用雙核或四核CPU的數據庫，但使用2-4台服務器就完全沒有問題了。
很長一段時間以來，部分用戶引入集群主要是基於兩方面的考慮：確保可用性和提高性能。對於跨集群的分散處理，小型商務機是一個很好的解決方案，MySQL復制的也常常用在多主機集群上，但這一技術在過去幾年得到較大的改變。
改變的理由很簡單：硬件。多核架構、便宜的內存和閃存不僅改變了數據庫的成本，同時還改變了數據庫計算的基本方法，從1991年到現在，內存的價格發生了天翻地覆的變化。例如，在兩年之內在固態硬盤上建立大型數據庫是完全可能的，假設有合理的軟件支持隨機讀寫磁盤將會接近內存的速度，極其便宜的磁盤歸檔已經在互聯網上傳播開來，離線磁帶的成本下降到快要崩潰的邊緣。
此外，開源數據也開始跟上硬件的發展水平，在MySQL社區，MySQL 5.4和Drizzle主要集中在多核擴展上，PostgreSQL已經攻克了這個問題，商業供應商如Schooner真在推進定制設備，集成新的硬件要比用戶自動做要好得多，並提高了數據庫啟動時的性能改善。
有了多核的利用，加上便宜的內存和固態硬盤，對於絕大多數用戶而言，一台數據庫主機上基本上就能提供足夠的運行性能，不用再在每個節點上部署 2-4台服務器了。換句話說，性能可伸縮正在迅速成為用戶群越來越關注的問題，這些用戶並不需要無限的性能，只要滿足他們的需要即可。
未來幾年基於三個方面的原因，會促進開源MySQL數據庫集群的發展：
1、 可用性
保持數據庫的可用性一直以來都是開源數據庫用戶關注度最高的一個方面，這不是猜測的，自2006年以來，我和成千上萬的人都談過這個問題，並且大多數用戶都希望不用經過大量的集成和配置就可以開始運行。
2、 數據保護
數據丟失是一件糟糕的事情，大多數用戶都希望每隔幾分鐘就對數據做一次拷貝，這樣就不用擔心什麼時候發生大的數據丟失了。異地保護也相當受推崇，不信你可以找任何一個DBA談談這個問題。
3、 硬件利用率
隨著硬件成本的下降，關注前端硬件投資正變得有些過時，現在重點需要考慮的是運營成本，我們先來看看功耗，假設有一台雙核CPU主機功率是250W，我們就需要一倍的功率用來冷卻和其它消耗，按照最近加州的電價計算，一年大約需要600美元的電費，電力只是其中一部分業務開支。
繼續來看數據庫集群的未來：肯定會大量存在。但現有的集群需要滿足開源數據庫在效率和成本方面新的需要，但從緊耦合的主/主模式到共享磁盤的如 Postgres-R和RAC將會完全不一樣。相反，我們將看到更多主/從復制的擴展性，為了符合大眾市場的需要，它們需要涵蓋下面這些特性：
1、 簡化管理和監視
關於集群最大的抱怨是它復雜難懂。如果你使用主/從方式代替了其它復雜的方式，那這個問題是可以解決的。你可以基於業務規則使用簡單可配置的策略來控制失效切換，使用作業管理隊列調度周期性任務，如備份。
2、 快速、靈活的復制
大型服務器會造成大型的更新負載，單一的從服務器肯定受不了，要麼需要並行數據庫復制，要麼需要磁盤級的方法，如PostgreSQL 8.5的日志流/熱備或DBRD。許多用戶都需要同步復制，跨站點復制也越來越常見。最後，復制方法需要可插拔的，因為不同的復制方法有不同的長處。復制本身只是集群解決方案的一部分，不管復制類型如何，大部分都是相同的。
3、 自頂向下的數據保護
簡化備份是一個良好的開端，異地數據存儲，自動數據一致性檢查和數據修復是必要的功能。大多數集群和復制框架都很少或沒有提供這方面的功能，對於集成數據保護的用戶將從新的集群方法獲得巨大的好處。
4、 分區管理
在不遠的將來，大多數應用程序都只需要單一的數據庫服務器，但大多數組織都有多個應用程序，而對於互聯網服務供應商來說則可能有成千上萬個，我們必須要為數據庫指定分區，並允許應用程序透明地找到它們，這種大規模的水平分區是單個應用數據庫運行在單一主機上遺留下來的問題。
5、 雲和虛擬化操作
長遠來說，虛擬化是硬件利用率問題的最簡單的治療方案，比其它方法更簡單和透明，目前已有很多應用運行在ISP的虛擬機或雲環境中，為了能夠在虛擬環境下運行，數據庫集群必須只能是軟件，安裝簡單，要最低限度占用資源，同時，還需要支持無縫數據庫配置，並具有可伸縮的能力，如添加一個新的虛擬機，或在現有4核心虛擬機上增加到8核心，同時按需增大內存。
6、 透明應用程序訪問
應用程序要能夠使用常見的API無縫連接到集群，並且無需更改SQL，對於采用簡單的主/從式或磁盤塊方法實現的集群要比其它更復雜的方法實現的集群要更容易做到，同時，應用程序訪問需要能夠處理簡單的基於性能的路由，如指導報告或備份副本數據庫。
7、 開源
由於種種原因，閉源集群對於開源市場而言注定會是厄運，基礎的集群組件必須開源，其中部分依賴於現有的用於存儲和數據庫日志級的開源技術，通過開放源碼的方式創造大眾市場解決方案。
前面我已經說過，我們正在構建Tungsten，Tungsten的目標是讓越來越多的應用程序運行在單一數據庫上，當然，我們也會提升數據庫性能，但我們認識到久而久之其它問題也會來臨，上面描述的技術屬性還是容易實現的，我們已經實現了一部分功能，不久將會更加完善。主/從集群模式不僅是可行的，對於大多數用戶它都工作得很好。
目前許多應用程序都有嚴重的性能問題，現有的軟件不能滿足需要。Facebook和其它大型站點將會繼續使用大規模的，定制的MySQL集群以及非SQL方法。分析和報告業務將繼續需要越來越大的數據庫，並要求具有並行查詢和自動分區的功能。有一些特殊的應用程序，如Telco，需要一個緊密耦合的集群，這種環境下可能需要重新改寫應用程序，這是高端市場的特殊情況。
大部分用戶需要更簡單的，更實際的東西，假設選擇了結合大量技術，如MMM，各種備份方案，cron作業，Maatkit 等組成的綜合方案，有些人可能會不知從何下手，硬件功能的轉變和對應數據庫的改進是集群解決方案的發展趨勢，如Tungsten就是切實可行的實現，它包括了用戶的實際需要，並是完全集成的。我打賭大部分用戶會認為這就是數據庫集群的未來。
p.s.我在Tungsten上已經工作了很長的一個夏天了，我們正努力工作，為了能夠在9月7日發布一個完整的開源集群解決方案。關於Tungsten的更多信息，請去該項目的主頁http://tungsten.sourceforge.Net/獲取信息。
原文出處：http://scale-out-blog.blogspot.com/2009/09/future-of-database-clustering.Html
原文名：The Future of Database Clustering
作者：ROBERT HODGES
