企业中的NoSQL

引子

作为企业架构师，我的职业习惯之一，就是不断的探求各种新的有前景的概念和思想，看其是否有潜力为我所服务的来自各行各业的企业客户带来价值。同样出于对这种理念的追求，我对NoSQL领域的关注了也有一段时间了，甚至从这个术语产生（或者错误的产生？）之前就开始了。Google首先在这方面点了一把火，发布了论文Big Table架构，对关系数据库是银弹这种普遍的信念提出了质疑，而Amazon关于Dynamo的论文则紧随其后。 过去的一年中我们见证了NoSQL强劲的势头，在这一领域有多达25种产品/解决方案发布，并且NoSQL的触角已经伸向了业界的各个角落。在此前提下，我最近考虑深入这一领域，评估一下我的客户究竟如何才能从这种NoSQL运动中获益。不仅如此，我还想探究对于企业来说，是否是到了该认真考虑采纳NoSQL的合适时机了。

什么是NoSQL——快速回顾

像许多关注这一领域的人一样，我不喜欢从本质上将SQL与NoSQL这一术语对立起来。同时我对该术语现有的解释“Not Only SQL”也不甚满意。对我来说，我们这里所讨论的并非是是否使用SQL。（相反的是，我们仍然可以选择类似SQL这样的查询接口（缺少对join等的支持）来与这些数据库交互，使用现有的资源和技术来管理开发伸缩性和可维护性。） 这一运动是要找到存储和检索数据的其他高效的途径，而不是盲目地在任何情况下都把关系数据库当作万金油。因此，我认为‘Non Relational Database’（非关系型数据库）能够更好的表达这一思想。

无论采用哪个名字，“非关系型数据库”这一范围所传达出来的“囊括所有”类型的意味，使得这一概念比较模糊（并且它还是否定型的）。这又使得人们（特别是企业中的决策者）对于哪些是属于这个范围，哪些不是，更重要的是，对他们来说这到底意味着什么，感到非常迷惑。

为了解答这些疑问，我尝试通过以下几点特征的描述，来刻画“非关系型数据库”的内在本质。

所谓“非关系型数据库”指的是

使用松耦合类型、可扩展的数据模式来对数据进行逻辑建模（Map，列，文档，图表等），而不是使用固定的关系模式元组来构建数据模型。

以遵循于CAP定理（能保证在一致性，可用性和分区容忍性三者中中达到任意两个）的跨多节点数据分布模型而设计，支持水平伸缩。这意味着对于多数据中心和动态供应（在生产集群中透明地加入/删除节点）的必要支持，也即弹性（Elasticity）。

拥有在磁盘或内存中，或者在这两者中都有的，对数据持久化的能力，有时候还可以使用可热插拔的定制存储。

支持多种的‘Non-SQL’接口（通常多于一种）来进行数据访问。

围绕着图中四个特征的（数据持久性、逻辑数据模型、数据分布模型和接口）“非关系型数据库”的各种变形，在最近的一些文章中有详尽的描述，并且在因特网上有着广泛的传播。所以我就不做过多繁复的描述，而是通过一些例子对关键的方向进行总结，供快速参考：

接口——REST （HBase，CouchDB，Riak等），MapReduce （HBase，CouchDB，MongoDB，Hypertable等），Get/Put （Voldemort，Scalaris等），Thrift （HBase，Hypertable，Cassandra等），语言特定的API（MongoDB）。

逻辑数据模型——面向键值对的（Voldemort，Dynomite 等），面向Column Family的（BigTable，HBase，Hypertable 等），面向文档的（Couch DB，MongoDB等），面向图的（Neo4j， Infogrid等）

数据分布模型——一致性和可用性（HBase，Hypertable， MongoDB等）， 可用性和可分区性（Cassandra等）。一致性和可分区性的组合会导致一些非额定的节点产生可用性的损失。有趣的是目前还没有一个“非关系型数据库”支持这一组合。

数据持久性——基于内存的（如Redis，Scalaris， Terrastore），基于磁盘的（如MongoDB，Riak等），或内存及磁盘二者的结合（如HBase，Hypertable，Cassandra）。存储的类型有助于我们辨别该解决方案适用于哪种类型。然而，在大多数情况下人们发现基于组合方案的解决方案是最佳的选择。既能通过内存数据存储支持高性能，又能在写入足够多的数据后存储到磁盘来保证持续性。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友