MySQL分片水很深
在與客戶討論分片決策的時候,我經常會先給他們講下面這個真實的故事。幾年前,有客戶來找我,希望獲得關於如何對系統分片的一些指導建議。他告訴我說,自從他知道很多應用MySQL的巨頭(比如Facebook和Twitter)都在使用分片技術以後他就也想這麼做。他們(這些巨頭)都是聰明人,所以很自然他也相信自己需要這麼做。
我停了一會然後問他的資料庫有多大規模。
他說:“有10GB”。 我點頭表示理解,並繼續問他是否要處理許多查詢或者有很多非常複雜的查詢。 他回答說:“沒有。每秒鐘只有幾百個查詢,這些查詢給系統帶來的效能消耗只佔很少的百分比。 我有問他是否預期在不遠的未來資料量有指數級增長,比如每週資料量就會翻倍之類的情況。 “不會的。我們的負載和資料規模去年增長了大約7%,我們預計今年乃至可預見的未來增長率也差不多。” 我給他的建議是不要在分片上浪費時間和精力了,因為他公司的情況需要的不是這個。 是否真的需要分片 在你決定如何分片之前,你最好從一開始弄明白你是否真的需要分片。誠然,在超大規模資料庫需求的情況下,分片是唯一的途徑。不只是對於MySQL,對大部分同類技術都是一樣。
然而,由於出現了很多新興技術,越來越多的應用都支援無需分片執行資料庫。現在,我們可以很輕鬆地在每個MySQL例項上執行TB級資料,並在許多OLTP環境下支援數以萬計的查詢。可見我們可以構建非常龐大的應用而無需分片。 我們應該銘記:分片對所有環境都是不得已而為的做法。即便你使用的資料庫支援開箱即用的分片功能,那也會由於引入更多元件和複雜度而帶來麻煩。構建良好的分散式查詢執行計劃是非常複雜的任務,需要考慮網路拓撲結構和負載情況,另外還要考慮資料分佈和每個獨立節點的負載。 在判斷是否需要分片之前,你應該首先考慮是否有替代方法可以擴充套件你的應用。在MySQL的世界裡,通常有以下一些方案可以考慮。
分片的替代方案 功能分割槽:在許多環境中,單獨的MySQL例項變成了各種資料庫的傾銷之所。你可能最終讓你的主應用與Drupal共享一個數據庫例項,用WordPress增強你的站點,用vBulletin增強你的部落格,甚至論壇。把所有這些應用碎片分入不同的資料庫例項是你首先應該考慮的,而不是直接考慮分片。客戶定製系統經常有不同資料集的應用,所以這個分法很容易實現。 複製:許多應用都是“讀操作”的壓力大,而擴充套件讀操作效能要比擴充套件寫效能更容易一些。如果是這種情況,那麼複製就是非常好的選擇。MySQL有自帶的複製功能非常健壯,雖然其非同步特性增加了應用的複雜性。這種情況下,開發人員必須判斷從哪臺複製伺服器上讀取資訊,不可以從哪裡獲取。因為你必須絕對保證你讀取到的是最新的實際資料。這也正是針對MySQL出現的可替代的非同步複製技術廣受歡迎的原因(例如PerconaXtraDB)。這些工具把大部分叢集環境下的功能提供給向單個數據庫操作的能力。
快取和佇列:快取是降低資料庫讀取量的出色技術。有許多應用使用這種技術可以降低資料庫讀負載高達80-95%。與之相對的是佇列,它是用來優化寫操作的。通過合併多次寫操作,提高了對資料庫操作的效率。大部分大型應用都應該重點考慮這兩種技術。Memcached和