【IT168 评论】今天对于传统的数据库解决方案，我们面临着很多有关扩展性的问题，而 NoSQL 运动将这些问题的根源归罪于 SQL 查询语言。

　　我认为，如此多的人将 SQL 视为“万恶之源”的主要原因在于这样一个事实：查询语言通常被紧密地融入了数据库的部署之中。因此，当提到“NoSQL”时，我们本质上是在对非扩展的传统 RDBMS 部署说“不”(No)。

　　对于查询语言大量的替代方案，这一说法也是适用的。这些替代语言中的每一个都致力于解决传统 SQL 查询方案所欠缺的某一个方面，比如文档模型，或者提供一种更为简洁的方案，如键/值(Key/Value)程序。

　　曾与我交谈过的大多数人对于这个话题都相当困惑，并且往往交替地使用查询语言和结构。所以，我想通过本文抛砖引玉，希望能够为 NoSQL 环境中每个查询术语所表示的含义提供一个简单快捷的概述。之后，我还会试图通过讲解来消除某些常见的误解。

　　后 SQL 世界中常用的查询语法

　　以下为 NoSQL 语境中一些常用的查询语法。

　　键/值查询：正如字面含义，键/值查询应该是最为基本的查询格式。每个数据项关联一个唯一的标识符(键)。在 NoSQL 语境中，memcache 是这种接口最常用的部署方式之一。使用 memcache 执行一个复杂的查询时，最为常见的模式是将查询延迟至用作搜索引擎的底层数据库。这些查询的结果是一个键或一组键，然后利用这些键通过 memecache 数据存储来执行相应的值提取。这种方式在后 SQL 语境中获得了新的发展动力，原因在于它们自身能够相当自然地与分区和分发概念相融合，而分区和分发正是使得数据存储具有可扩展性的关键所在。换句话说，当人们别无选择时，他们愿意用大多数传统 RDBMS 所提供的强大的查询概念来交换可扩展性，即使只提供基本的查询支持。

　　基于文档的查询：文档查询这种模型的主要用途在于搜索引擎，在这中环境中最常见的是存储不同类型的温度，即使每个文档代表的是截然不同的对象。在 NoSQL 环境中，文档并不是我们在搜索引擎中见到的那种典型的 Word 或 PowerPoint 文件，而是 Jason 或 XML 形式的对象，或者关联一组键/值的二进制对象，比如 Cassandra。使用 SQL 术语来描述，文档可视为一个 blob(一种数据类型)，关联着一组键，每一个键独立地进行索引并且维持着至该 blob 的引用。每个 blob 可以是不同的类型(表)，每个 blob 可以具有不同的关联索引组(键)。通过关联索引来完成匹配工作。结果组通常包含多种类型，每个又包含不同的数据组。由于索引和 blob 无需与行和表的严格结构保持一致，所以将其称为“非结构的”(schemaless)，也就是说，它可以具有同一类型的不同版本，并且向新的表中添加字段时无需修改任何表而且无需更新数据的旧版本。支持这种文档模型的数据库有 CouchDB 和 MongoDB。

　　模板查询：模板查询在 JavaSpaces 和 Hibernate 较新的版本中常常用到。利用基于模板的匹配，你可以根据类类型或遗传等级抓取一个对象，以及该对象的属性值。对于更为面向对象的模板匹配，你还可以根据图标(graph)属性中的特定项来执行匹配任务。在支持 JavaSpaces 模板查询模型的解决方案中，GigaSpaces 是较为知名的实现方式之一。

　　映射/化简(Map/Reduce)：映射/化简通常用于执行分布式数据存储上的聚集查询。一个简单的例子，比如 Max 或 Sum。对于这种情况，查询全球需要在每个分区(映射)中独立的执行，然后进行聚集后返回客户端(化简)。隐式的映射/化简可以进行某个查询请求并隐式地传播该查询的执行。客户端获取聚集查询，就像它是一个单一查询。显式的模型运行用户执行自由格式(free-form)的代码，你可以控制映射模型(哪个调用指向哪些数据)、每个节点(即任务)中运行的代码以及结果。在一个常规的 Hadoop 部署中，映射/化简常常通过显式某些来进行。类似 Hive 和 Pig 的框架提供给了一个概要模型，可以隐式地处理进程。

　　SQL 查询：让我们思考一下，SQL 也算是另一种形式的动态语言，专门用于复杂的数据管理。使用 SQL，通常可在表和行中对数据进行排序。SQL 中的某些查询语法，比如 Join、分布式事务，以及为了获得扩展性而较常用的反模式语法。大体上来讲，正是 SQL 语法的这一点将 SQL 与有限的可扩展性关联起来了。支持 SQL 的 NoSQL 实现有使用 JPA 的 Google Bigtable、Hive/Hadoop、MongoDB 和 GigaSpaces。有关具体含义我将在下文进一步详述。