关于数据库扩容与缩容

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

最简单的就是分库分表。 

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

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

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


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

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


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

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


转载于:https://my.oschina.net/wanjubang/blog/519214

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值