转载： Scale OUT还是Scale UP？

Scale OUT还是Scale UP？ 

zz:http://samyu.blog.51cto.com/344284/169764

做web2.0网站，一个普遍的感觉就是计划不如变化。在吸引风险投资的时候，我们可以做出种种规划，在某某年吸引多少多少用户，PV/UV达到多少，我 们都期待用户量的快速增长，因为互联网的普遍模式还是先圈用户，但增长还是不增长，增长多少往往是无法事先预计的。在这种情况下，配置多少存储和运算能 力，在什么时候增加存储和运算能力是个考验人的问题。存储和运算能力的闲置，浪费金钱，但存储和运算能力不够，网站垮掉也是我们所不愿意看到的。云计算的 概念吹了很久，在中国还是看不到影子。作为技术人员，当然是期望有云计算平台的出现（其实很多web2.0网站也没什么多么核心的数据资产那么令人担 心），按需购置存储和计算能力就好，不要老深更半夜的往机房里面跑。但现实是在中国，我们还需要自己购置存储设备、服务器和带宽，自己去维护。

  从企业IT架构体系上来看，对于web2.0网站来说，必须考虑的就是可扩展性：随着使用人数的增多，能够及时的扩展IT系统的能力。解决这个问题，通常 有两种解决方式：Scale up和Scale out，两种扩容的方式分别从两个维度来解决数据库压力。所谓Scale up就是向上扩容，Scale out就是平面型的扩容。纵向的扩容就是将DB Server的配置提高，增加硬件配置，通过硬件速度提升来解决访问压力，横向扩容就是将应用的数据拆分，将原来集中存储的数据根据一定的规则分布到不同 的物理数据库服务器上。Up模式实施成本较高，大到一定压力之后，硬件可能无法满足这类需求。从web2.0网站来看，如果能够通过叠加相对廉价设备的方 式实现存储和计算能力的扩展，是长期可扩展的有效手段，这点是Scale out所带来的优势。

  对网络存储来说，共享存储是必须的。无论数据块或文件、本地化或远程，都不希望停留在单处理环境中。数据中心需要全新的服务，不只是关于服务器、存储或网 络产品的，而是关于建立系统的应用和基础架构资源，企业建立的系统要能够轻松适应未来的需求。目前来看，在存储领域采用Scale out的方式是一种比较流行的模式，很多公司也推出了相应的产品和服务。在最近IBM公司发布了一款全新的、可高度扩展的磁盘存储系统，该系统技术来自 IBM公司在今年一月份收购的XiV公司，旨在应对如今的多种复合信息，这些信息来自从Web 2.0到金融服务等传统应用。由XiV公司技术开发而来的这一全新企业级磁盘产品，展现了一种独特的基于网格的存储架构，可以更加轻松地管理，并可实现更 好的性能扩展，配有自调整/恢复及自动精简配置功能，能够帮助降低信息存储的成本和复杂性，同时支持现在动态工作负载下对数据进行持续快速访问的要求。根 据IBM公司的介绍，XiV系统基于SATA磁盘，运用了一种独特的并行架构及缓存算法，不但消除了热点，其性能水平也远远超出那些基于FC的磁盘系统。 此外，IBM发布的扩展文件服务(SOFS, scale out file services)能够帮助企业快速实现高度可扩展的全球化集群NAS系统，从而能够帮助缓解当前的数据存储挑战，尤其是当前存储网络带宽不足给企业所带 来的困扰。

  国外很多web2.0的网站通过Scale out的方式，比如Flickr和digg，解决了平稳服务下的计算能力扩展的问题。Flickr网站通过Shards这种模式，利用众多的价格低廉数据 库服务器横向分布信息，在每天处理亿级的事务情况下响应时间还是很快，同时在信息不断膨胀的情况下扩展的成本很低，扩展对于网站的影响基本没有。 Shards含义是碎片，在这里的意思是将应用的数据横向拆分，也就是说如果有几千万的用户信息，那么这些用户信息可以被分布在多个数据库服务器上，这种 分组分布数据到不同的数据库服务器上，横向切分数据块就叫做Shards。Digg的处理方式也蛮有意思，它把主要的用户访问量大的数据与其他的用户访问 量小的数据做sharding，对于那些访问量大的“热”数据用更好的硬件，提供更好的服务体验，而其他的数据尽管访问速度稍慢一点，对用户来说，影响也 很小。

  不过另外一方面，Scale out这种方式策略的制定复杂度以及维护成本要高于Scale up。采用Scale out这种方式，首先需要解决复杂的分布式计算的问题（相对来说Scale Up方案不需要考虑这个问题），这对于很多国内的web2.0网站的技术人员来说，是一个巨大的技术门槛；另外，Scale Out方案还需要对原先的软件进行大量的重写工作，以保证系统能在分布式服务器上运行（Scale Up方案则对现有软件几乎没有改动要求）；还有就是Scale Out方案始终面临着数据集中的问题，即拆分过的数据在服务器逻辑体系中仍然是各自相对集中的而非无限随意拆分。

  对于分布式计算的技术问题，国外有一些开源的项目，我们可以借鉴，在一定程度上可以去努力解决。与此同时，我们还需要考虑到我们自身网站的数据的特点。像 联机游戏、IM、BSP这些数据，通常每个用户都可以抽象成一个数据对象，可以独立存储在任何一个地方，数据之间关联度不大，这种情况比较适合采用 Scale Out的方式。但对于另外一些数据，比如电子商务网站的买卖信息，它们之间的关联度大，这时候往往查询需要耗费很多的资源；还有一些事物型的应用，保证数 据的完整性是更为重要的，在这个时候，采用Scale Out的方式不一定适合。从整体上看，采用Scale out的方式是web2.0网站的主流，适应了网站数据不断且不太好预计增长的主要需求，而Scale up这种方式更为适合业务数据具有较强关联性且数据增长可预期的企业。