读“DataBase Sharding at Netlog”，看DataBase Scale Out

taobao的同学?数据我是直译的,阿软sip一天也就有5000w的服务调用了，今年1.6亿吧，也就这么几台破机器：），这里还是说那种扩展的思路，当然适用于某一些场景，呵呵，这种思路用在一天10亿的设计中也未尝不可。

是的， 但是， 这个思路很多人都会。 估计是大部分解决思路的， 问题在难度在于， 管理这么庞大的数据源是个很难解决的问题， 开发上很难做到透明。 虽然这些架构设计很多人滚瓜烂熟了， 但是实践起来， 估计都不是简单的事情， 我很难想象， 一个应用要连接30－50个MYSQL的配置应该如何做。

所以， 我们团队设计了ameoba这个工具， 解决sharding的透明开发， 透明管理的问题。MYSQL大规模部署， DDL是个很大的问题。 无法在线DDL， 哎。

楼上的我知道你是谁了,以前的同学么,我也看过你ameoba的部分设计，不过没有很深入，感觉的却很不错的。是的，其实技术就是要在实施过程中才会有体验，就好比erlang很多人都只觉得天生并行计算的好语言，但是它的优点也带来了很多问题，用起来就知道了。不过么，呵呵，象你对横向阔展有那么多研究的同学还是有限的，因此开阔一下眼界也还好了，文中提到的横向扩展很多都是理论性的东西，但是将关系型数据弱化感觉在某些情况还是有效的。如果楼上同学有blog请站内给我一个消息，我也希望好好学习一下这方面的内容，因为我的方向起码在过去还和你不太一样：）

很好的文章，谢谢

如果不介意，可以指教个问题吗？
假如把，好友表，按用户id切分了。对于查询我好友信息就很好查了。
但是如果要查我好友的好友就很麻烦了。。如果是同表，那自己连接自己就可以得出了。。

但是分表的话，首先要得出我好友信息，然后在去分表查好友的好友。。
这样数据会好多。。。

不知道有没比较好的查询方法。。

如果是这样的话,应该和文中提到的最后一种手段,也就是对用户的好友建立搜索引擎,建立索引,只能通过几次搜索引擎的检索先得到用户的基本id，然后再根据需要去查询出用户的基本信息。不过我没有实施过，只是空谈^_^，我现在还没有实际的sharding，现在我所关注的是open api，其他方面有涉及，但是不深入，因此只能给个仅作石头的引子。

我们通常要做SHARDING的情况， 必然应用会受到限制的。 很多设计师在这个上面撞破了头， 分区后， 还想做各种复杂的join, 多库分别查询并且结果排序，聚合等操作。 这个是不对的， 业务方应该知道， 这个规模下要实现过于复杂的代价是非常庞大的。 如果设计者还是想做这些操作， 那我们只能说， 他对业务的数据的切割没有理解到位， 或者大规模应用的代价还不清楚。

一般来说， 类似SNS的应用， 按用户分割数据， 就要在表的设计上需要一定的灵活度， 比如，每个人的好友列表必须位于本人所在的数据库， 不然查询是非常困难的。 象好友的好友都是通过多次操作数据库得到， 或者在CACHE里已经建立好关系了。 依赖数据库来获得是数据的行为应该受到极大的限制。

另外， SHARDING以后， 可能要求很多数据是冗余的， 这个冗余正是为了避免多库join。 我们不能严格遵守数据库范式来设计表。 比如， SNS应用里的每个好友的状态活动信息， 如果不限制的情况下， 按照普遍的原则， 每个人差不多有200－500的好友， 那么将会产生极大的数据。 所以单一数据库是无法承受的， 即使有了CACHE也是承受不了的。 很容易产生数十亿行数据。 那么我们宁愿向每个好友分发数据， 来避免多库join, 尽管我们极大的冗余了数据， 但是也降低了复杂的多库查询。 业务上， 我们需要限制这些好友信息的数量， 以及过期时间。 以期获得更好的性能。

实际上， 架构师应该把握避免多数据的查询， 以灵活的手段解决 n:m 的数据分区的问题。

也许很多人反对我的观点， 但是事实就是这样， 超大规模的应用， 业务是受数据分区极大的影响的， 不能想干什么就干什么。

最近在看数据库发展方面的， 有的开源组织已经开始研究数据库的实时的map/reduce系统。 也许有一天，数据库透明的为我们解决很多问题。像hadoop类似工具，无法替代数据库的功能。 如果数据库有M／P能力， 最好不过了。 当然也有人说m/p系统是开历史倒车。 尽管他取得了极大的成功。

我咋感觉这句话跟我一直的想法不太一样那，我咋一直觉得你只有业务跟数据之间的关系摆明了，你才可能更合理的作partition那？照你这句话，我是不是可以理解成反而是数据的分区主导了前者那？ wondering...