数据库水平切分的实现原理解析

我已经期待很久了!

不知 c-jdbc 及 后续的 sequoia 是不是做此类事情的。

我在单机上模拟过2个h2 做 db  raid1，性能很差。。。估计分布式环境会好些吧

想知道楼主如何处理水平切分后的搜索处理？

比如取一个用户的好友列表。
是通过merge各个分库的搜索结果，还是依赖于搭建的搜索引擎。或者是更好的方法。

之前有个设想：构建索引分区表，在每个分库机器上保存索引段，但过于繁杂。

也尝试过mysql的集群，不过使用时出现过节点内存不够的情况（mysql集群将索引保存在内存）

我认为水平切分难点还是在于处理搜索

搜索？你说的是走搜索引擎吗？还是跨多表多库的查询的merge？

1.为什么分片？

数据库分片的缘起是为了减小大小，这包括减小表的大小，索引的大小；同时提高并行，最终目标是提升性能。

分片不应该承担起负载均衡应该承担的责任，比如稳定性。

理解为什么分片很重要，你只需要对你部分表进行Sharding，而不是所有的

2.如何分片

假设你的电子商城系统有10亿用户，每天会上来逛逛，看看你的商品，下下订单。

你的用户白领较多，每天早上九-十点都会有峰值，她们上班了，晚上9-10点也有个峰值，她们吃晚饭了

那么你应该想一下，这俩个峰值时出现的大量用户登录请求该如何处理，从一个亿级记录表里是不是很糟糕，那么好吧，我们针对user id取模，分16个库，反正你有上亿用户，钱不是问题。

那么这16个库放什么呢？

把所有表都放进去，别逗了，你的商品表每天更新1000个，也shard一把？

我们只需要把访问量最大的那些相关的表放进去就好了，user和order。

我看来Sharding的最大未解决问题是，目前没有一种很好的产品能够允许使用动态语言来配置shard，能让我很轻松的扩展到32、64个DB。

3.LB、Cache、buff这些都是设计Sharding应该考虑的，但是注意，这些不属于Sharding.

LZ我们期待你的完善已有半年了

接下来的 由于一些原因 暂时不能写上来了 加之 这段时间忙的不行  没时间写了。。。 不好意思呀 楼上的同学

bluemeteor写道：

一语中的啊！

俗话说打江山容易，守江山难。解决问题的办法是多种多样的，重点个人也觉得在于如何进行后期维护与调整。数据扩展的方式容易了，数据扩展的管理也要跟上。

“你”我都明白，没有绝对的通用解决框架，但楼主搜集、整理了一种通用的解决方法和思路，成功的经验是可以复制的，期待楼主的收尾工作，赞一个。

看完了，恭喜一下自己吧。

楼主说有线上运行的产品，不知道是怎么实现统计和连接查询的？还是这个方案不考虑这些，而只是针对与其他没有任何关系的单独数据实体（如Log)?

有没有实践过HBase, 我对Hbase的理解，觉得它也是针对这种单一的数据实体来解决关系数据库的效率问题，不太确定能不能在高效的基础上也加入“关系”的特性？HBase号称取代MySQL的地位呢。

目前整个的设计有个限定条件：假设DB仅仅是Table的一个容器，而忽略关系。。