关于数据库扩容与缩容

   当我们的应用达到一定的规模的时候，我们的数据会暴涨。   当初的数据库可能就不满足我们的读写要求。  然而数据的增长在商业层面上是令我们欢欣鼓舞的，然而更头疼的是如何实现有效的扩容。 怎样才能不出错。

最简单的就是分库分表。 

那么数据库怎么知道去哪个机器上读那些数据呢？

比如我之前有10w记录   。  现在考虑将前10w 放在A   然后增加10台数据库服务器。   理论上容量可以到100w

那么如何屏蔽数据库的改动，对上层应用透明呢？  这是我们应该考虑的。

假如你做到的对上层系统透明。  那么这就结束了吗？

由于各个数据库是不同的数据，那么其中一个机子当掉，那么数据就会丢失。  可能大家会想到冗余，利用slave 实现+ 心跳检测。     那么数据库恢复大概会需要多久呢？   以目前的数据量来看，假设每个存储节点服务的数据量为1TB，内部传输带宽限制为20MB/s，那么增加副本拷贝数据需要的时间为1TB/20MB/s = 50000s ，大约十几个小时，由于拷贝数据的过程中存储节点再次发生故障的概率很高，所以这样的架构很难做到自动化，不适用大规模分布式存储系统。

那么大型系统是如何实现的？

在此之前，我们来看一下MogoDB提供的解决方案-sharding

原文：http://my.oschina.net/wanjubang/blog/519214