导读：Mike Loukides是O'Reilly传媒的内容战略副总裁，他对编程语言和UNIX系统管理非常感兴趣，著作有System Performance Tuning和Unix Power Tools。本文中，Mike Loukides提出了自己对NoSQL的精辟见解，并对现代数据库架构的方方面面进行了深入思考。

在去年的一次谈话中，basho公司的CTO Justin Sheehy认为，NoSQL是一场运动，而非技术。我立刻深表赞同，因为以往关于NoSQL的探讨并不舒心。

那么，为什么说NoSQL是一场运动，而非技术呢?Justin的说法直截了当：之所以说NoSQL是一场运动，是因为这是对数据库架构的选择。任何一种单一的技术主题，反而会掩盖NoSQL运动的实质。

自八十年代以来，关系型数据库(如SQL Server、Oracle和DB2)一直都是后端业务系统的主导。这些关系型数据库产品都非常优秀，它们之间有许多共通之处。

回顾一下以往15年的软件开发历程，我们已经构建了许多优秀的大型数据库应用，其中不乏Web应用。但是自关系型数据库诞生以来，数据库领域已经产生了许多变化：

• 数据激增。虽然存储的容量和CPU的速度都在飞速发展，使得数据库可以应对数据量的激增，但是数据量的确是一个棘手的问题，对于任何重要的数据库而言，分布式必不可少。
• 亚秒级的查询响应。在八十年代，数据库查询以批处理的方式运行，查询效率低下。现在的互联网，已经从静态文件发展到由复杂数据库支撑的站点，而且对于大多数查询，我们需要亚秒级的响应时间。
• 7*24小时正常运行。为静态HTML文件设置冗余服务器非常容易，但复杂的数据库复制就另当别论了。
• 对高速数据流的捕捉越来越重要。许多应用的后台数据库吸纳数据的速度远远快于处理数据查询的速度。比如，在日志应用或者分布式传感应用数据库中，写入比查询频繁的多。ETL(数据提取、转换和加载)固然不可或缺，但对高速数据流的捕捉显得越来越重要。
• 非结构化数据。非结构化数据早就存在，并不是数据世界里的新景观，但我们越来越不希望强制数据结构。
• 牺牲ACID。ACID(原子性、一致性、隔离性、持久性)虽然很重要，但现代应用带来的挑战让我们意识到，为了实现其它特性(如低延迟和可用性)，我们必须做出牺牲。

需求的不断变化，迫使我们不得不思考全新的数据库解决方案：

• 分布式。庞大的数据库只是采用分布式的一个原因，另一个原因是现代应用(尤其是Web应用)要求满足许多在线用户的瞬时响应。响应时间每超时一秒，都会造成大量用户流失。
• 实时计算。如果你正通过构建在线应用支持业务分析，那么用户必然期望实时业务分析。这不仅便捷，每天执行成百上千的查询，彻底改观了我们的工作。
• 可扩展性。如果你正在构建一个面向客户的应用，进行业务分析，那么可扩展性是一个大问题。垂直可扩展性已经近乎极限，物理定律的制约使得Intel架构的时钟频率在3.5GHz的范围内徘徊不前，水平可扩展性(构建多节点分布式系统)成了唯一的途径。
• 高可用性。应用系统架构中的任何一部分出现单点故障，都会导致灾难性的后果，数据库系统必须提供高可用性支持。一个高可用性系统天然就是一个分布式系统。
• 数据分片。对于一个给定的分布式数据库，接下来的问题就是数据分片。关系型数据库在多台主机之间采用手动分片，或者基于数据本身的某些属性对数据集进行分区。MongoDB非常容易进行数据分片，HBase、Riak和Cassandra本身就是分布式数据库。
• Schemaless(无模式)。NoSQL数据库通常称为schemaless(无模式)，因为它们与关系型数据库的架构形态无关。事实上，NoSQL并非完全无模式。在像CouchDB或MongoDB这样的文档数据库中，文档是许多键值对(key-value)。Riak也可以被看做是一个文档数据库，但比文档类型更灵活。Cassandra和HBase被称为面向列的数据库。在大多数应用开发中，NoSQL数据库前期规划更少，灵活性更大，更适合敏捷开发。
• ACID和CAP。ACID属性深入人心，但如果我们仔细思考数据库的架构，就会发现对一个分布式系统实现一致性和隔离性等ACID属性非常困难。ACID属性非常重要，但自由的选择需要折中。CAP定律指出，对于一个分布式计算系统，一致性、可用性和分区容错性只能同时满足其中二者。