YeSQL：问题与 SQL 无关!

　　上文已经讲述了查询格式背后的某些概念，某个结论现在更为明朗了——过错的确与 SQL 无关。与许多语言一样，SQL 为你提供的是一根足够长的绳子，如果你喜欢，甚至可以那它来做悬梁自尽之用。几乎每种语言都是如此。如果想要将数据模型设计为与分布式模型相匹配，你会看到 SQL 在管理数据方面具有非常强大的功能。比如 Hive/Pig/Hbase 和谷歌的 JPA/Bigtable 就是很好的例子。对于这两种情况，底层的数据存储是基于可扩展的键/值存储，但前端查询语言刚好是基于 SQL 的。MongoDB 瞄准的也是类似的目标，主要的区别在于，这种数据库提供类似 SQL 的支持但并不完全遵守任何现有的标准。

　　请注意：事关架构!

　　诸如 Hive/HBase 以及 JPA/Bigtable 之类的 NoSQL 实现，可以视为很好的示例：下一代数据库如何同时支持线性扩展和 SQL API 接口。

　　关键之处在于将查询语法与底层数据存储剥离开来，如下图所示：

　　谷歌的 Bigtable 在 NoSQL 数据存储只是提供对 SQL API 的支持

　　融合正在发生

　　上周作者参加了 Hadoop summit 会议。Hadoop 提供的环境类似一个非常通用的培养基，这将为其带来一个生机勃勃的微生物系统。今天已经存在许多新的框架，它们在查询和处理方面对 Hadoop 数据管理方式进行了不同等级的萃取，比如 Hive、Cascading 和 Pig。许多框架提供的工具已经远远超出了 Hadoop 创建者最初的设想。

　　这让我想到一点：我们可以利用上文提到的分离模式，从而在与 SQl 的连接中提供对稳定模型的支持。也可以这样表述，我认为大多数数据库中领先者将支持所有上述语法，并且用户将不用只是因为某个数据库实现支持某种查询语言而选择它。

　　我们已经在动态语言上看到类似的趋势。以前，一门语言必须提供完整的工具、编译器、库和支持该语言的开发工具，这让选择某种语言成为一种重要的战略。而今天，Java 中的 JVM 或 .Net 中的 CLR 提供了相同的环境，能够支持更多的同一 JVM 运行时之上的动态语言。类似的例子，比如：Groovy 和 Java 或 Jruby。

　　最后的话

　　在本文中我一直在讲，SQL 事实上是一个相当不错的查询语言并且将继续在后 SQL 世界中发挥重大的作用。不过，一家通吃的情况不会继续下去。数据管理的世界将建立在多种工具盒数据管理语言之上，每种语言或工具提供将某种特定的功能或服务。最为理想的情况，无论数据存储方式如何，我们应能够使用任何查询语言来访问任何数据。例如，我应能够使用文档模型来存储 JSON 对象，而且，无论任何时候，我都应能够使用 SQL 查询语法或简单的键/值 API 来查询这个 JSON 对象。

　　原文标题：YeSQL: An Overview of the Various Query Semantics in the Post Onl