“云计算将带来一场革命”。在如今这个概念满天飞的时代，这是否又是一次商业炒作？本文不想对此进行评论，而更愿意关注这背后带来的变化。技术革命一定是源于某项技术突破，那么云计算又是源于何？从技术的视角看，云计算所突破的就是海量存储技术以及在此基础上的并行计算技术的突破。正是这些突破，造就了诸如Google、Facebook、Twitter这些新兴互联网企业。另一方面企业信息系统正日益变得复杂与庞大，上述技术突破展现出来的几乎无限的扩展、海量计算以及高可用的特性正是企业所迫切需要的。

本文将就企业信息系统中如何更好应用上述技术进行探索。在讨论云存储技术的之前，我们来回顾一下现在企业所使用的关系型数据库所存在的问题。

1970年IBM的Edgar F. Codd博士发表一篇著名的论文《一种用于大规模共享数据存储系统的关系数据模型》，由此奠定了现在诸如Oracle、MSSQL、MySQL、Postgres等关系型数据库的理论基础。40年过去了，关系型数据库不可辩驳地坐上了数据世界中的头把交椅。如此成功的技术会有什么问题？

问题来自于访问量急剧增长所带来的可扩展性。所有具有最基本功能的关系型数据库都会支持join操作，不过join操作可能会很慢。由于数据库通常依靠事务来保证一致性，而事务需要锁住数据库的一部分，使之不能被其他用户访问。因为锁本身意味着竞争同一数据的用户会被放入队列，等待获得读写权限，这在高负荷的情况下可能会成为系统的死穴。

通常我们会用下面几种方法解决上述问题：

• 提升硬件能力，如增加内存、用更快的处理器或硬盘，这被称之为垂直扩展，可解一时之忧。
• 增加新的计算机，构成数据库集群。不过，这样就会在正常使用及故障时遇到数据复制与一致性问题。
• 更新数据库管理系统的配置。例如要优化数据用来写底层文件系统的通道。
• 审视自己的应用，优化索引、优化查询。不过，当我们的应用达到这个规模的时候，恐怕不太会完全没有做过索引和查询优化。那么，只好重新审视所有数据库的访问代码，想发现零星的可以调优的机会，这是一件相当头疼的事情。
• 增加一个缓存层。现在我们又需要面临更新缓存和更新数据库的一致性问题了，对于集群来说，问题更加严重了。
• 审视我们想要的查询，复制那些访问频率较高的数据，让它们更接近于查询想要得到的形式，这个过程被称为反范式化，也就是说违反了Codd提出的关系模型12条准则。这时我们只能安慰自己说我们是生活在现实世界之中。

这一幕是何等熟悉，现如今的企业应用的规模已经远不是Codd提出关系模型的年代所能够想象的。TB级别的数据库已经并不罕见，一些数据表动辄上亿条记录，甚至几十亿条记录。笔者遇到的一位客户仅每年增长的数据量就达到了3TB，要知道这一数据在5年前仅有大约500GB。这样的数据量已经开始给构建在此之上的企业应用造成巨大的压力。我们接下来看看云存储技术又是如何解决这一问题的。

云存储技术最早来源于那些互联网企业，这也是可以理解的，毕竟这些企业所面临的访问量也是之前任何应用所不曾遇到的。从一个数据就可以得知：现在支付宝每天新增的记录数为3亿条。显然这样的数据量以及在此之上的运算，不是传统关系型数据库可以支撑的了。

这里所说的云存储技术并非特指某项技术，而是一大类技术的统称，一般来自只要是具有以下特征的数据库都可以被看作是云存储技术。首先是几乎无限的扩展能力，可以支撑几百TB直至PB级的数据；然后是采用了并行计算模式，从而获得海量运算能力。简而言之，就是当计算能力不足，无论是存储还是运算，对于需求提出方而言，就是简单的增加机器即可实现。更进一步的特征便是高可用性，也就是说，在任何时候都能够保证系统正常使用，即便有机器发生故障。目前常见的符合这样特征的系统，有Google的GFS以及BigTable，Apache基金会的Hadoop（HDFS和HBase），最初来自于Amazon现在也属于Apache基金会的Cassandra，此外还有MongoDB、CouchDB、Hypertable、Redis等等。

作为可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。通过现有的机器增加硬件的容量、内存进行垂直扩展，是最简单的达到可扩展性的手段，但这有个限度。而水平扩展则需要增加更多机器，每台机器提供全部或部分数据，这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。而云存储技术所带来的可扩展性几乎是无限的，并且对于投资者而言投入（硬件投资）与产出（提供更多的服务）几乎是线性的。

水平扩展说到底就是使用更多的主机来承担运算。假设一台主机在运行一年的时间里发生故障的概率是n，那么20台主机在运行一年的时间里发生故障的概率则为20×n，由此看出当某个集群中主机的数量达到一定程度，在一年中发生故障的概率将会非常大，甚至每天有机器发生故障也不是危言耸听。许多云存储技术都将此作为基本的设计前提，因此云存储技术天生具有良好的高可用性与容错。

怎么样？是否很诱人。这么好还不如把现在的这些企业应用都替换了。先别着急，享受这些好处也是有代价的。说到这里就不得不提Eric Brewer的CAP理论（2002年被理论证明）。依据这个理论，对于一个大规模分布式数据库系统，有以下三个需求：

• 一致性（Consistency）：对于所有的数据库客户端使用同样的查询都可以得到同样的结果，即使是有并发更新的时候也是如此。
• 可用性（Availability）：所有的数据库客户端总是可以读写数据。
• 分区耐受性（Partition Tolerance）：数据库可以分散到多台机器上，即使发生网路故障，被分成多个分区，依然可以提供服务。

CAP理论指出，同时只能具有这三个特性中的两个。传统的关系型数据库所强调的是一致性（C）与可用性（A），而在分区耐受性（P）的方面的支持十分有限，这一点从本质上揭示了上述关系型数据库的问题。再来看云存储技术，都特别强调了分区耐受性（P）从而弥补关系型数据库在此方面的不足，接下来的区别就是选择可用性（A）还是一致性（C）了，反正是不能都选。对于CP系统，放弃的是可用性（A），你的数据将保持一致性，但如果有节点发生故障，仍然会有部分数据无法访问；而对于AP系统，放弃的则是一致性（C），那么你的系统就有可能返回不太精确的数据。

以上技术特点决定了云存储技术有一些特别擅长的领域。例如访问流量可能会非常大，即随时访问数据量非常大，从而需要大规模分布式部署。考察读写操作的比例，特别适合统计分析型工作，但是写可能是密集型的。有时对于数据一致性要求并不高，即可以容忍当某个数据被写入后，在一段合理的时间内可能会有部分用户读到的是写入之前的数据，搜索业务就是一个典型例子。

但同时也有些计算领域并非云存储技术擅长。例如事务密集型计算，这类计算对一致性要求非常高。相比读操作，写操作会频繁持续发生。在企业中存在大量这种类型的计算。

通过以上分析，我们发现，“年轻的”云存储技术并非完美无暇，看似“古老的”关系型数据库在其面前并非一无是处。云存储技术现在不是，将来也不应该是关系型数据库的终结者。在我们为它所展现出来的那些令人激动的特性面前，必须冷静分析，这是否就是企业运算所需要的？至少现在看来不是全部。

显然不是所有的企业计算都适合使用云存储，采用关系型数据库也许仍然是目前的最佳选择。问题就变成了应该将其用在哪里？接下来将会列举两个目前特别适合采取云存储技术的应用领域，这两个案例都来自于笔者比较熟悉的商业应用领域。

数据仓库将集中来自几乎所有业务生产系统的数据，对外提供企业的各种查询报表以及数据分析。从功能看这是一个典型的统计分析型工作，日常大量发生的都是读操作。另一方面需要周期性地从业务生产系统收集原始数据，并可能需要对其进行进一步的数据加工，这一过程是写密集的。数据量无疑会是非常大的，实际生产中的数据仓库通常需要保留几年至十几年的数据，可以达到TB级，其中一些数据表可能会达到几十亿条甚至更多的记录数。以上这些需求特点决定了其特别适合采用云存储技术。

所谓企业统一资料库，就是将企业运行中所基于的各种资料集中到一个应用系统中进行统一管理，再由这个系统以服务的方式，提供给所有需要的其它业务系统，所提供的服务除普通查询外，还应该包含基于搜索引擎的资料搜索服务，包括商品（以及商品类别、品牌）、合作伙伴（供应商、客户、加盟商等）、合同（采购合同、销售合同、加盟合同等）等。在这个应用中读操作发生的频率将远大于写操作，尤其当其以在线方式提供资料服务时更是如此，例如为网店提供资料服务。

需要说明的是，笔者所在的海鼎公司对以上这两个方向都已经做了相当的工作。企业统一资料库的第一个版本已经完成开发，并将在今年10月份在东莞美宜佳投入使用。而下一代的数据仓库解决方案已经完成了前期预研工作，开始进入开发设计阶段。