大数据浪潮袭来 企业该如何选择NoSQL

在当今这个大数据时代下，优秀的传统关系型数据库管理系统已经无法应对很多数据库处理任务。在今天的文章中，我们将一同探讨如何在各类NoSQL后备方案中找到适合自己的选择。

　　在过去几个礼拜里，我一直在芝加哥为自己的公司部署卫星办公室。虽然硅谷确实算得上是大数据供应商的摇篮，但芝加哥作为大数据用户及从业者们的根据地、重要程度同样不容忽视。无论是有心参与还是无意偶遇，这里的人们每一天都会跟大数据活动产生不少交集。在每一次大数据相关活动当中，我们都不可避免地要与NoSQL打交道、议题也总会谈到为什么传统关系型数据库管理系统已经无法满足如今的新需求。就目前来看，大部分读者朋友对这一问题还不太熟悉。NoSQL数据库分为几大不同种类，我们拥有多种合理的出发点来针对不同数据集选用不同的NoSQL数据库类型。总而言之，其实际复杂程度远远超出了技术业界在营销中所宣称的“NoSQL就是规模化”。NoSQL数据库种类如此众多，部分原因可以归结于CAP原理，又被称为Brewer原理。

　　根据CAP原理的说法，在以下三种特性当中我们只能同时实现两者：一致性、可用性以及划分限度。不同的数据集以及不同的运行时间规则迫使我们采取不同的解决方案。各类数据库技术针对的具体问题也有所区别。数据自身的复杂性以及系统的可扩展能力都是需要认真考虑的重要因素。

　　产生分歧的另一个理由则源自基础计算机科学、甚至可以算是基础数学运算。某些数据集能够轻松与键-值对进行映射;从本质上讲，数据的表格化并不会削弱其实际意义，我们也没有必要对数据关系进行重组。在另一方面，数据集与其它数据项目间的关系可以说同数据项目本身一样重要。

　　换句话来说，关系型数据库在能够作为键-值对处理的数据领域发挥极大效力，但却不善于处理要求更多背景信息的数据。前者对可扩展性提出要求，后者则需要我们为其提供更多性能资源。

　　关系型数据库以关系代数为基础，我们基本上可以将其视为集合论的衍生产物。基于集合论的关系适用于多种数据集，但对于必须要求具备父-子或者关系距离要素的内容来说效率不高。在这种情况下，大家可能需要采用图论来设计数据解决方案。

　　键-值对数据库

　　键-值对数据库当中包括Couchbase以及Apache Cassandra。这些方案具备高度可扩展性，但却无法帮助开发人员顺畅处理复杂数据集。如果大家需要进行磁盘备份、分布式散列表并通过一致性对数据内容加以检查，那么上述方案既具备良好的规模化能力、又能提供出色的处理速度。然而如果我们需要通过某个键来获取另一个键、进而访问第三个键以查询相关值，那么问题就会变得非常复杂。

　　列族/大表数据库

　　大部分键-值数据库(包括Cassandra在内)都会提供某种形式的列组，我们可以将其理解为“列族”或者“大表”。而以HBase为代表的某些数据库则从开发之初就以列族作为设计思路。这是键-值数据库的一种更为先进的表现形式。从本质上讲，其中的键与值 存在一定程度的复合。我们可以将其视为一套贯穿多维数组的散列映射。基本每一个列都容纳着一行数据。根据DataStax公司(一家专门销售Cassandra认证版本的企业)产品副总裁Robin Schumacher的观点，“Cassandra人气最高的使用实例就是处理时间序列数据，这些数据可以来自设备、传感器、网站(例如Web日志)乃至金融记录数据等等。这些数据的产生速度通常非常之快，而且往往一次性来自多个位置、增长幅度惊人，需要出色的写入能力以及以时间片段为基础的高性能读取配。

　　大家也可以利用MapReduce来打理这类实例，这是因MapReduce最擅长的就是解析半结构化数据。它们具备极高的可扩展性，但通常不具备事务型处理能力。如果数据之间的关系与数据本身的重要性不相上下(例如距离或者路径计算)，那么请不要使用列族/大表数据库。

　　文档数据库

　　很多开发人员认为文档数据库可以算是解决问题的灵药，因为这类方案非常适合面向对象型编程。10gen(MongoDB)、Couchbase以及Apache CouchDB等发展迅猛的厂商都将此作为自己的起步平台。来自Couchbase的Frank Weigel指出，该公司正在着手从1.8版本开始将原本的键-值数据库转化为2.0版本下的文档数据库。根据他的说法，“文档数据库属于自然而然的发展趋势。从集群化到数据访问，文档数据库与键-值数据库几乎完全一致;惟一的区别在于，文档数据库能够理解所存储数据中的文档内容。”换句话来说，文档数据库会将值作为JSON、而JSON文档中的元素则能够通过检索轻松进行查询与搜索。

　　在此类方案中，最理想的状态就是大家可能已经完成了JSON文档的生成工作。正如10gen公司总裁Max Schireson在采访中所说，如果大家的“数据太过复杂，以至于无法通过关系型数据库进行打理，那么应该考虑尝试文档数据库。举例来说，一套复杂的衍生安全性实例可能很难以关系形式加以保存。电子健康记录同样面临着这样的问题。如果大家考虑利用XML方案，那么我强烈各位使用MongoDB——这种数据库使用的正是JSON/BSON。”

　　这可能正是大家在企业运作过程中遇到的实际情况——来自用户、系统、社交网络或者其它来源的数据不断产生并纷至沓来。也许这些数据并不一定都是以报告的形式出现，但MongoDB等方案通常也会包含一定程度的MapReduce功能。至少在MongoDB当中，大家可以对任何内容加以查询，而且即使不借助索引机制也不至于出现我们无法接受的性能问题。

　　图形数据库

　　图形数据库并不太关注数据规模或者可用性，而主要针对我们的数据之间存在怎样的相关性以及用户需要如何执行计算任务。正如Neo Technologies公司(主要产品为Neo4j数据库)产品工程高级主管Philip Rathle所说，图形数据库的威力主要体现在“数据集在本质上存在关联且非表格形式的情况下。其首要数据访问模式采用事务型机制，即OLTP/记录系统而非批量处理机制……请大家记住，图形数据库允许以事务性方式执行关联性操作，这一点在关系型数据库管理系统领域只能通过批量处理来完成。”

　　这种特性在大部分NoSQL营销活动中都得到了反复强调：我们选择图形数据库的主要理由之一，就在于我们需要在自己的数据结构中使用超出关系型数据库能力范围的准确事务型处理方式。

　　图形数据库的常见用途包括地理空间计算、推荐引擎、网络/云分析以及生物信息学——基本上，任何重视表达位置之间关系的数据都适合利用图形数据库进行处理。这种技术在各类金融分析体系当中同样扮演着重要角色。如果大家希望了解某家企业的弱点或者“负面消息”，这种直接性关系将成为计算流程中的关键所在。要想通过查询实现同样的效果，我们不仅需要通过大量代码编写SQL查询语句，其执行速度也不会太快。相比之下，图形数据库显然更擅长此类任务。

　　如果大家的数据内容比较简单或者已经存在于表格当中，那么实在没必要使用图形数据库。另外，图形数据库也不太适合处理OLAP或者长度分析工作。通常情况下，图形数据库往往与索引机制紧密相连、从而实现更理想的搜索与查找效果，但图形部分必须经过遍历;对于这一点，大家需要在一部分初始节点上加以修正。

　　概述：如何挑选？

　　图形数据库的出现很好地诠释了为何开发人员很难为这些新的数据库类型命名。“NewDB”是我个人最偏爱的名称——当然，某些与关系型数据库管理系统同时代甚至更早的数据库名称也不错。“NoSQL”这个名字就不太好，因为其中或多或少还是支持了一部分SQL功能，而且SQL与这些系统在功能性上也存在着某些交集。

　　最后，“大数据”这种描述也并非完全正确，因为我们并不一定要通过大型数据集来充分发挥这类数据库方案的能力——只要它比关系型数据库更适合即可。“非关系型”也不准确，因为图形数据库当中同样蕴含着明确的关系结构;它们只不过遵循着与传统关系型数据库管理系统不同的关系逻辑。

　　事实上，这些只是一部分能够解决我们特定难题的特定数据库。过去十年以来，市场营销策略总是喜欢把硬件规格、带宽局限以及更理想的延迟及规模预期作为主要宣传手段，旨在防止某些早期数据库像关系型数据库管理系统那样遭受广泛恶评。

　　正如我们不应该尝试利用同一套关系型数据库管理系统解决全部难题，我们同样不应该尝试利用集合论本身解决所有数学问题。如今的数据难题正日趋复杂：可扩展能力、性能表现(即低延迟)以及规模化需求正持续走高。为了满足实际需求，我们需要调整思路、尝试利用多种数据库技术完成不同背景下的具体任务。