最近做的web網站本身遇到一個大表（萬rows左右）因為對於performanceweb本身可用性的考慮必須想辦法boost perf這種情況應該都用partition來搞定了這也符合分治等算法的思想想辦法降低問題本身的復雜度然後在一個一個解決
mysql中一般到萬操作就有點麻煩了index要好好的做這裡還遇到了一個文本檢索問題MyIASM storage engine裡面有個fulltext index但是不知道它對於中文支持如何而且不清楚它是怎麼分詞的不大清楚後台邏輯Mysql這種index limitation很多很難scalable所以基本上直接考慮用search engine那一套直接上了lucene+solr+solrsharp小表like還可以忽悠忽悠大點就慢的如老牛……
Partition通過了解發現解決方案倒是不少以前做過了解過這方面知識儲備
對hivedbhscale等都沒想過要嘗試發現net在使用open source很多都不是很舒服
最開始嘗試了mysql partition一開始聽起來方法這種方案很Perfect！是mysql解決horizontal partioning的很好方案等document看完了發現版本的partion limitation太多了只能適合某些特性的場景例如按照用戶id做split普通那種非unique keyprimary key是很難搞定的簡單方法是給表本身不添加任何主鍵自己來實現主鍵生成機制這樣仿佛可以了但是通過explain partitions來做下analysis發現結果定位具體parition不好這就很難降低IO本身的高成本了沒有通過具體測試不知道可能是explain partition本身不准確原因還是……
mysql partition還有一個很大的弊病就是很難跨機器當然如何能夠把Mysql存儲做成分布式也還好但是這個技術代價都上了不少檔次risk過高了只能算是下下策了備用好了這些不爽的地方導致偶們直接拋棄了這種方案直接用手工切分來搞定這種問題我想這也是大部分這種需求的常見solution把
手工切分本身技術還比較簡單
就是要考慮表的編碼管理等多個方面以及如何快速定位到可能的partition這些在設計方面都應該注意了
而且對於多partitions的結果應該使用多線程等並發同步技術來提高perf這裡的partition還做到支持對某一個partition做進一步切分這樣切分到每一個partition塊盡量表中數據在萬以下這樣加上db index速度應該能夠滿足一定的需求的手工切分本身很容易scale out可以把表放在不同的機器上等等load balance方法來scale回想感覺最有意思還是表編碼自身的考慮有點意思我很大程度的靈感來源於IP地址的劃分因為這個表自身增長速度會很慢所以采用unsigned int來搞定億來表示萬還是小意思嘛我主要是通過前綴+長度來定義表的標識前綴可以讓給數據比較密集的表因為它們可以支持位其它就用位來表示可能有些不再切分范圍內的就讓他們從開始增長把這裡partition list本身維護可以序列化到filesystem中每次Load class時候deserialize一下然後就是本身partition如何快速定位就需要用點復雜點的data stuctures了
From:http://tw.wingwit.com/Article/program/net/201311/13691.html
