鱼缸的启示:Scale-out和Scale-up架构

本文通过养鱼的例子形象地对比了Scale-out与Scale-up两种存储扩展方式。Scale-up意味着更换大型设备并迁移数据,可能导致服务中断;而Scale-out则通过增加额外的小型设备实现无缝扩展,避免了数据迁移的复杂过程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

转载自:

http://storage.ctocio.com.cn/comment/139/9065639.shtml

 提到Scale-out和Scale-up,初看到可能会有点晕。其实我认为Scale-out和Scale-up的概念可以用一个简单的例子来解释。

不知您有没有养过鱼?当你只有六七条鱼的时候,一个小型鱼缸就够了;可是过一段时间新生了三十多条小鱼,这个小缸显然不够大了。

  如果用Scale-up解决方案,那么你就需要去买一个大缸,把所有沙啊、水草啊、布景啊、加热棒、温度计都从小缸里拿出来,重新布置到大缸。这个工程可不简单哦,不是十分钟八分钟能搞得定的,尤其水草,纠在一起很难分开(不过这跟迁移数据的工程复杂度比起来实在是毛毛雨啦,不值一提)。

  那么现在换个思路,用Scale-out方案,就相当于是你在这个小缸旁边接了一个同样的小缸,两个缸联通。鱼可以自动分散到两个缸,你也就省掉了上面提到的那一系列挪沙、水草、布景等的折腾了。

  回到存储架构。用户在采购之初很难准确预测未来数据增长的速度和总量。用户往往不得不采购比自己目前实际需求容量更大的存储,这就导致两个问题,一是预算的浪费,很多存储空间都是为未来数据增长采购的,花了10TB的钱,但是可能只利用上了5TB,另5TB的资金都白白放在那里。另一个问题是,随着时间推移,数据增长,数据量超过了10TB。

按照过去Scale-up的理念,解决方案就是购买更大容量的存储,那么难免面临数据迁移的问题,用户必须停机迁移数据,意味着服务的中断。而Scale-out架构解决了这个矛盾。用户按需采购存储,一旦容量不够了,再购置一台接到原有存储上就可以了。

这只是我的一点想法,如有不对的地方,欢迎大家批评指正、展开讨论。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值