最近做的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了
