在可擴充性方面,客戶的要求變得越來越多,功能列表上經常會出現20條、50條甚至多達100多條要求,但總的來說,我們可以把它們縮短為五個大類,通過五條途徑來解決可擴充性問題:
1. 調整查詢操作
對查詢進行最佳化能夠讓你付出最少的精力就得到最多的成果。將查詢功能完善的發揮出來,達到業務需求,不會被過多的流量和過重的載荷壓倒。這就是為什麼我們經常看見客戶碰到的麻煩越來越多,隨著他們網站的訪問量越來越大,可擴充性的挑戰也變得越來越嚴重,這就是問題的所在。對網站角落裡那些不常用的頁面做查詢最佳化是並不必要的,那些頁面並不會收到真實世界的流量。根據反映對網路應用做一定的調整是很普遍的做法,而且效果很好。
查詢最佳化需要啟用緩慢查詢日誌並且不斷觀察。使用mk-query-digest這個Maatkit套件中的強大工具來分析日誌,而且要確定設定了log_queries_not_using_indexes標籤。一旦你發現某個查詢嚴重佔用資源,那就要最佳化它。使用EXPLAIN解釋機制,使用profiler,觀察索引的使用方式,建立失蹤的索引,理解它是怎麼進行添加和排序的。
2.使用Master-Master複製
Master-Master的active-passive複製模式,或者稱為迴圈複製,不僅能帶來高可用性,也能夠帶來高度的可擴充性。這是因為你能夠即刻給你的應用程式指派到一塊唯讀從屬盤。許多網路應用都按照80/20的規律來分割,80%的活動用來進行讀取或SELECT,剩下的分配給INSERT和UPDATE。配置你的應用或者進行重新架構,把讀取需要的流量發送到從盤,這樣做是可行的,這種類型的橫向可擴充能力可以進一步延伸,在必要時能夠附加更多塊唯讀從盤。
3. 使用儲存
這聽起來是很基礎的東西,也很直接,但是經常會被忽視,你至少應該確認設定了這些:
•innodb_buffer_pool_size
•key_buffer_size (MyISAM索引緩衝)
•query_cache_size – 使用大型SMP時需要小心
•thread_cache & table_cache
•innodb_log_file_size & innodb_log_buffer_size
•sort_buffer_size, join_buffer_size, read_buffer_size, read_rnd_buffer_size
•tmp_table_size & max_heap_table_size
4. 磁碟讀取的RAID
你的資料庫下面是什麼?不知道嗎,請找出來。你是在用RAID 5嗎?這對於效能來說可是一個巨大的阻礙。RAID5的插入和更新操作速度很慢,而且如果你丟失了一塊硬碟,RAID 5在重建時幾乎無能為力。RAID 5實在是太慢了,那麼應該用什麼代替它呢?用RAID 10做鏡像和分段,這就可以充分利用你的伺服器或機箱裡的所有硬碟了。即使你的記憶體能夠容納下整個資料庫,依然需要對硬碟進行許多讀取操作。為什麼呢?因為比如排序操作需要重新安排行列,群組和聯結等等也一樣,還有添加交易日誌等等這些都是磁碟I/O操作。
5. 調整Key參數
另外,有些附加的參數也可以用來提高效能:
innodb_flush_log_at_trx_commit=2
它可以極大的提升insert和update的速度,只是在清除innodb日誌緩衝區時有點偷懶。你可以對它多做些研究,但大多數情況下是非常值得推薦的。
innodb_file_per_table
innodb開發就像Oracle,儲存方面使用的是tablespace模式。顯然核心開發人員們做的並不完善,因為使用單獨tablespace的預設設定就會出現效能瓶頸。這個參數設定可以協助innodb為每個表建立tablespace和資料檔案,就像MyISAM所做的一樣。