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

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

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

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

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

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

　　键-值对数据库

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

　　列族/大表数据库

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

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