3.2 NoSQL的起源

进入21世纪后，互联网经济走出了20世纪90年代互联网泡沫的阴影，开始快速发展，多数大型网络公司的规模都在急剧增加，运用超链接、社交网络、活动日志、博客、微博客、微信、测绘数据等服务吸引人气，并开始用非常详细的方式来记录活动，出现了结构化、半结构化和非结构化的大型数据集。据统计，人们每秒钟发送的电子邮件高达290万封，每分钟向YouTube上传60个小时的视频，每一天在Twitter上发1.9亿条微博和3.44亿条消息，在Facebook发出40亿条信息。社交网络和微博等新型应用的兴起对数据管理技术提出了新的挑战，包括更高的并发读/写、海量数据的高效存储和访问以及高扩展性和高可用性等需求，传统的关系型数据库管理系统（RDBMS）无法满足这些需求，因此，必须投入更多的计算资源才能应对数据和流量的增加。在可选的解决方案中，一种是纵向扩展（scale up），即增加功能更加强大的计算机（更多的处理器、硬盘存储空间和内存），但投入的成本越来越高，同时其扩展的空间也非常有限。另一种是横向扩展（scale out），即采用由多个小型计算机组成的集群。集群中的小型机采用性价比较高的硬件，这样可以有效降低扩展所需的成本，同时使架构富有弹性（集群中的某些小型机甚至微型机即使发生故障也不至于影响整个集群的运行）。为降低建设成本，几乎所有的互联网公司都选择了后者。

在大型企业向集群迁移的过程中产生了一个新问题：关系型数据库并不是针对集群这种模式设计的，虽然可以把数据分为几个集合，并将其分别放在各自独立的服务器上运行，成功地对数据库进行了分片，但是数据库分片后，虽然将负载分散到多个服务器之中，却带来了另一个问题，即查询、参照完整性、事务、一致性控制（consistency control）等操作都无法以跨分片的方式执行了，从而导致应用程序极其复杂。同时，由于商用的关系型数据库通常按单台服务器计费，导致在集群环境中使用成本的大幅上升。

针对上述问题，人们开始考虑新的存储数据的办法。谷歌、亚马逊这两家互联网龙头企业更是如此，他们凭借自身雄厚的技术实力开始探索研究解决这个问题的思路和办法。2003至2009年间，谷歌和亚马逊分别将各自的研究成果以极具影响的论文形式发表出来，他们就是BigTable（谷歌）和Dynamo（亚马逊）。

2009年6月，在旧金山参加Hadoop峰会（Hadoop Summit）的英国学者Johan Oskarsson先生发起并召开了寻找新型数据存储方案的技术大会。当时，Johan想给会议征集名字，希望这个名字同时适合做Twitter话题。在IRC即时聊天服务中发出后，他在众多的回答中选中了Eric Evans先生提出的名称“NoSQL”。在会议中，来自Voldemort、Cassandra、Dynomite、HBase、Hypertable、CouchDB和MongoDB的技术代表纷纷介绍了自己的技术方案及特点。不过，至会议结束，也没有哪位技术权威对“NoSQL”下定义。

不久，“NoSQL”一词以燎原之势迅速流行起来。虽然，到目前为止学术界也没有给它一个严谨的定义。但NoSQL数据库所具备的共同特征日益清晰：第一，NoSQL数据库不使用SQL，有些NoSQL带有查询语言，如Cassandra的CQL，看上去很像SQL，但从广义的角度看，没有一个NoSQL数据库真正实现了标准的SQL语言；第二，通常都是开源项目，虽然NoSQL这个术语也经常用在系统中，但是业内人士普遍认为NoSQL数据库就应该是开源的。

NoSQL数据库通常是为Web 2.0应用的互联网企业设计的，操作NoSQL数据库不需要使用“模式”，不用事先定义结构，即可自由添加字段。这在处理不规则数据和自定义字段时非常有用。NoSQL数据库的出现使人们多了一种选择，那就是在不同场景下使用不同的数据存储方式。人们可以不再因为别人都使用关系型数据库而自己也跟风使用它，相反，可以根据实际的应用场景选用合适的数据存储技术。

无论如何，关系型数据库都不会被NoSQL取代，关系型数据库依然是最常用的数据库形式，Google的关键产品也不例外，是基于MySQL实现的。使用关系型数据库，通常情况下如果关系型数据库无法承担负荷，则考虑使用NoSQL，即让与NoSQL数据库对关系型数据库的不足进行弥补，引入NoSQL数据库时的思维方法如图3-1所示。选用NoSQL数据库，通常是以下两种情形：一是待处理的数据量很大，或对数据访问的效率要求很高，从而必须将数据放在集群上；二是希望采用一种更为方便的数据交互方式来提高应用程序的开发效率，尤其是互联网应用。NoSQL数据库需要量材使用，如果用错地方，可能会发生使用NoSQL数据库比使用关系型数据库效果更差的情况。NoSQL只是对关系型数据库不擅长的某些特定处理进行了优化，一定要量材使用。

图3-1　引入NoSQL数据库时的思维方法