NewSQL大揭底：寻找NoSQL和SQL的平衡点(转)

【IT168 专稿】NoSQL最初为Not SQL的缩写，如今已经演变为Not Only SQL，因为开发商已经意识到，实际上更喜欢SQL的人以及有大量SQL经验的人比JAVA或其他程序员的雇佣成本更低，而且这样的人更容易被招募到。

　 　事实上，NoSQL不使用SQL是一个错误。不使用SQL不是因为它的性能不好，而是因为关系产品架构不适合某些类型的任务。但在没有这些类型的任务 时，又很容易陷入认为SQL等同于关系技术（Relational Technology）的陷阱。关系架构的关键一点是将物理实例从逻辑实现中分离了出来，不过大多数包含关系存储和关系访问层的关系产品也是如此。但该例 子无需演示DB2在关系型和基于XML数据存储引擎的不同。

　　无论如何，NoSQL开发商已经意识到他们的错误并加入了SQL功能。但笔者真正要讨论的是所谓的NewSQL数据库。这些数据库从一开始就设计包含了SQL接口(而不是之后才添加的)，而且在下层不需要关系存储引擎。

　 　最近出现的NewSQL数据库为VoltDB，为Michael Stonebraker的另一项作品。它是一种标准关系数据库，但是将所有关系发展累积超过四十年的不必要的小组件剔除，使其比传统版本更精简更有效，因 此它比商业数据库执行效率更好，并且缩小了它的覆盖面，而所有的NewSQL数据库都是如此。另一种NewSQL数据库是Xeround公司的，该公司是 一个基于云服务的数据库公司，提供灵活的scaling和NoSQL roots。像所有其他NewSQL数据库一样，该公司的NewSQL数据库主要侧重于事务处理，除了它固有的能力，Xeround公司数据库的另一个主 要不同为，它看起来像MySQL，这使其很容易将现有的MySQL用户迁移到云端。

　　还有两个有意思的NewSQL数据库：NuoDB(前身为NimbusDB)和JustOneDB。目前笔者尚未得到二者的测试程序，因为NuoDB目前处于beta阶段，JustOneDB项目也才刚刚开始。

　 　NuoDB在一个与BitTorrent类似的端到端环境中使用一种分布式对象架构(像许多NoSQL数据库一样)。当更新一条记录时，会将其改变追加 到已经存在的数据上，而不是替代它，因此可以看到数据库中的所有历史数据。该架构涉及到事务节点和归档节点的使用，其中前者使用内存， 后者使用键/值存储来保持数据。因多个归档节点可以保持没有请求备份的相同数据，也就不必要为高可用性来复制数据，以及不必要进行分块。这听起来很像标准 的NoSQL数据库，但最大的不同是，NuoDB数据库被特别设计来支持SQL，且完全支持ACID(原子性-Atomicity、一致性 -Consistency、独立性-Isolation、持久性-Durability)。

　　而JustOneDB又是另外一回事，它也 完全支持ACID(像Oracl NoSQL数据库)且被设计支持SQL。它的环境看上去像PostgreSQL，且运行在Heroku的云端。但是它使用完全不同的其公司称之为隧道存储 (tunnel storage)的存储架构。笔者无法具体解释隧道存储是什么意思(只能说它既不是基于column的也不是基于键/值的)，但我能肯定该技术有一定的效 果，它的特性包括完全支持联接，且不需要索引或分块。有趣的是它可能支持查询处理(例如你可能从来不需要对全表进行扫描)以及OLTP，虽然其公司发展的 重点为后者。并且，和NuoDB一样，JustOneDB总是追加数据且从不删除它们的源数据。但它与它的竞争对手的不同之处在于，它侧重于 scalling up而不是scalling out，至少目前是这样的，也就是说如何在一台服务器上scale而不是跨服务器的。 该公司的观点(一个并非不合理的观点)认为，在理想情况下人们一般希望越晚scale越好，也就是为什么公司会侧重于scalling up而不是scalling out。TPC-H基准的内部运行说明了与标准PostgreSQL orders(100X+)相比，其性能的巨大提升。

　 　如果你喜欢MongoDB、Cassandra或Hadoop，那么NoSQL很有意思，但这些数据库对于大多数人来说都显得经验不足。另一方 面，NewSQL则对于大多数人来说经验则丰富得多，很多人花了大量时间在其上面，而且NewSQL数据库也更有趣且值得检验。