NoSQL概述介绍

　在过去的几年里我们已经看到崛起的一种新型的数据库，称为NoSQL数据库正在挑战关系数据库的优势地位。 关系数据库一直主导着软件行业，其提供机制保证存储数据能够持续很长一段时间，实现并发控制与事务，优点是提供标准接口和与应用程序数据集成。 然而,关系数据库的统治地位是被危及。

NoSQL是什么意思？

　　NoSQL意味着不仅仅是SQL，还意味着在设计一个软件解决方案或产品时，可以根据需求有一个以上更多选择的存储机制,。 NoSQL是一个新数据库标签(# NoSQL)。 NoSQL崛起的最重要的结果是多种范式的持久机制出现。 NoSQL没有约定俗成的定义，常见观点如下：

• 不使用关系模型
• 在集群上运行良好
• 主要是开源的
• 适合构建21世纪Web应用
• 非模式化
  

为什么要用NoSQL数据库

　　应用程序开发人员已经对关系数据结构和应用程序内存中的数据结构两者之间的阻抗失配非常烦恼(见对象与关系数据库阻抗不匹配)。 使用NoSQL数据库允许开发者编写代码时无需将内存结构转换为关系结构。

　　还有其他远离关系数据库的运动，如使用服务而不是关系数据库作为系统的集成点(见SOA)。

　　互联网作为一个平台的崛起也创建了一个至关重要的变化因素：其数据存储需要支持大量数据在集群上运行。

　　而关系数据库的设计并不能在集群上有效运行。

　　Facebook或Etsy的ERP等应用程序的数据存储也需要更多不同的数据存储。

聚合数据模型

　　关系数据库模型是截然不同于应用程序开发人员使用的数据结构。 使用数据结构建模的开发人员以便解决不同的领域问题，这场运动已经开始从关系模型转向到聚合模型，主要是由 领域驱动设计 Eric Evans一本书(本站DDD)。 一个聚合是数据的集合，是我们元进行交互的一个基础单。 数据聚合成单元可以分为数据库ACID操作、键值存储、文档存储和列族数据库，它们都可以被视为aggregate-oriented数据库的形式。

　　聚合方便数据库通过集群管理存储，因为当从数据库检索这些数据单元是可以驻留在任何机器上，当大多数数据使用聚合实现时，这时非常适合使用Aggregate-oriented面向聚合数据库，例如订单和它的所有细节，最好方式是存储订单作为一个聚合对象，而订单的细节如果作为聚合根就不优雅了。

　　Aggregate-oriented面向聚合数据库使inter-aggregate关系比intra-aggregate关系很难处理。 Aggregate-ignorant数据库适合当交互是使用不同形式数据场景。 Aggregate-oriented数据库通常使用不同计算方式来提供数据组织。 比如通过Map/Reduce模式计算，如每天使用Map/Reduce计算获得已经销售出去订单细目。

分布式模型

　　面向聚合的数据库使得数据分布更加容易，因为已经将聚合从数据中独立出来，因此分发数据时就不必担心数据之间的关系，因为有关系的数据都包含在聚合体内部了，有两种方式分布数据：

　　1.分片Sharding：将数据按种类分区到不同服务器上，每个服务器作为数据子集的唯一来源。

2.复制：将数据跨服务器复制，每一份数据都可以在不同服务器中找到，复制有两种形式：

（1）主从复制，使用一个主服务器处理写操作，从服务器则同步主服务器数据，处理读取操作。

（2）对等复制(peer-to-peer)，，复制数据可以写入任何节点服务器，节点之间协调数据的同步。

　　主从复制会降低更新的冲突率，而对等复制能避免加载所有写操作于一个服务器，避免单点故障，一个系统可能采取一种或两种技术。

CAP定理

　　在分布式系统中，管理Eric Brewer提出CAP定理，有就是一致性(C)、可用性(a)和分区宽容(P)是很重要的。在任何分布式系统我们只可以选择一致性、可用性和分区容忍其中两个。 许多NoSQL数据库试图提供这种选项。开发人员可以根据需要优化数据库。 例如，如果您考虑 Riak 这样一个分布式键值数据库。 基本上有三个变量r,w,n：

• r =被认为是成功响应读请求的节点数量。
• w =被认为是成功响应些请求的节点数量。
• n =数据复制的节点数量即复制因子。
  

　　在一个5个Riak集群节点中，我们可以调整r,w,n值：比如过设置r = 5和w = 5保证高一致性，但会导致集群在网络分区容错的丢分，导致有节点可能没有成功响应。 我们通过设置r = 1和w = 1获得写入或读取的高可用性，但严格的高一致性需要妥协，因为某些节点可能没有最新的数据的副本。CAP定理指出，如果你想得到一个网络分区容错，你必须权衡数据的可用性和一致性。 耐用性也必须和延迟一起权衡考虑，尤其是如果你想在复制数据时避免失败。

　　NoSQL数据库提供开发人员调整系统的选择和具体要求。 理解需求的数据会被系统消费的，，是以写为主还是以读为主？是否需要查询数据携带随机查询参数？系统如何可以处理不一致的数据？

　　理解这些需求变得更为重要，长时间我们一直使用默认的RDBMS，无论选择哪一个产品都附带了一组标准的功能，也缺少了选择的可能性。 使用NoSQL数据库是有选择的，这也有好坏。好是因为我们选择根据需求设计系统。不好是因为你有一个选择了，我们必须根据要求做出一个更好的选择，使用相同的数据库产品也有正确使用与否的选择。