通过ibatis实现轻量级的水平切分(已更新，ibatis原生api也可以实现sharding)

非常感谢你的鼓励
关于你第一点的建议这个我不是没有考虑过，但是即使基于sqlmapclient现有的api也很难做到开发人员在开发时不去关心如何分表。打个比方说如果不做分表是直接存放在表（sub_table）中，调用sqlmapclient的insert方法是传递的参数可能直接用SubTable这个pojo。但是如果这个应用要根据数据产生的时间按月分表，这个时候仅靠pojo里的参数就不够了。因此我就新开了方法来做sharding的功能。不过我刚才考虑了一下可能很多时候靠sqlmapclient原有的api和外加一些配置是可以完成sharding功能的。这个可以做后新的特性在后面的版本中实现。谢谢你的建议。

至于你提到的第二点我理解的是不是你说的读写分库？关于数据库路由的功能准备在后面版本里加，在rodemap里我也写了，具体的实现方式欢迎您一起讨论，谢谢。

比较牛。轮子上加个胎或绣朵花才是正途。

以前我也参考hibernate-sharding的思路做过一个封装 http://code.google.com/p/ibatis-sharding/

目标是尽量保持原来ibatis的使用习惯，功能和hibernate-sharding类似，很久没维护了，有兴趣的可以看看，代码也很简单

哈哈， 直接在JDBC上做WRAPER的话， 会更干净～

大牛，果然就是大牛，一句话就给出了很好的解决方案。
让我开阔了思路。通过在sqlmap的xml里添加配置，程序的处理通过对jdbc的包装来处理。

请问可以支持分页查询吗？
如果不支持，有这方面的计划吗？
谢谢！

我个人认为如果对水平切分的数据要进行分页查询的话，可能会带来一些性能问题，可能最后没有了水平切分带来的优势。我觉的如果对水平切分的数据还要做分页查询的话，那还不如不要切分，可以选用其他的技术方案。比如说利用搜索引擎等

如果你在一家小公司， 拥有数十亿的数据， 有比较大的访问要求， 买不起昂贵的存储， 买不起昂贵的小鸡。 你会怎么做？  搜索引擎。。。OPENSOURCE的， 有几个能处理大规模索引的？

那也要比select count(*) 数十亿数据来的快吧？如果分表，就不能多表联合查询了，要不分表还有什么意义。对于分页，应该通过分表的策略，让可能分页查询的数据都尽量在一个小表中。如果不能做到，或者单独计数，或者就不提供这种功能。

个人认为，分表分库不是用来做搜索的。更多用于服务器的负载均衡，我们也在iBatis基础上，结合spring实现了分库（保留分表的后期改造能力）。从性能上讲，分库（使用不同的物理服务器）视乎更好一些。