非关系型数据库（NoSQL）综述_键值对模型的非关系型数据库

非关系型数据库（NoSQL）综述

简介以及与关系型数据库的对比

• 简介：

  非关系型数据库也叫Nosql数据库，全称是not only sql。
  2009年初，Johan Oskarsson举办了一场关于开源分布式数据库的讨论，Eric Evans在这次讨论中提出了NoSQL一词，用于指代那些非关系型的，分布式的，且一般不保证遵循ACID原则的数据存储系统。Eric Evans使用NoSQL这个词，并不是因为字面上的“没有SQL”的意思，他只是觉得很多经典的关系型数据库名字都叫“**SQL”,所以为了表示跟这些关系型数据库在定位上的截然不同，就是用了“NoSQL“一词。
  非关系型数据库提出另一种理念，例如，以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中，要对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。

• 关系型数据库与非关系型数据库的区别：

关系型数据库通过外键关联来建立表与表之间的关系，非关系型数据库通常指数据以对象的形式存储在数据库中，而对象之间的关系通过每个对象自身的属性来决定。

分类

• 基于列的数据库（column-oriented）

基于列的数据库会将每一列分开单独存放，当查找一个数量较小的列的时候其查找速度是很快的。基于列数据库是将数据映射到行号上面，在基于列的数据库中要想增加一列新的数据是很容易的，因为现有的那些列是不会受新增列的影响的。基于列的数据库的优势在于分析数据和对数据形成一个报告方面，例如对值求和、计算整条记录等。现在使用基于列的数据库存储数据的有Apache HBase，Facebook’s Cassandra，Hypertable和grandfather of wide-column stores，Google BigTable。
相关产品：Cassandra, HBase, Riak
典型应用：分布式的文件系统
数据模型：以列簇式存储，将同一列数据存在一起
优势：查找速度快，可扩展性强，更容易进行分布式扩展
劣势：功能相对局限

• 键值对存储（Key-Value Stores）

键值对的存储方式在NoSQL数据库中是最简单的一种，其结构就像其名字所示，是一个key-value的集合。如图五所示的那样。这种方式在NoSQL数据库类型中是最可扩展的一种类型，并且可以存储大量的数据。
键值对中存储的数据的类型是不受限制的，可以是一个字符串，也可以是一个数字，甚至是由一系列的键值对封装成的对象等。图六向我们展示了一个比较复杂的键值对结构。使用价值对存储的数据库有Redis，Voldemort，Riak和Amazon’s Dynamo。
相关产品： Tokyo Cabinet/Tyrant、Redis、Voldemort、Berkeley DB
典型应用： 内容缓存，主要用于处理大量数据的高访问负载。
数据模型： 一系列键值对
优势： 快速查询
劣势： 存储的数据缺少结构化

• 面向文档（Document-Oriented）数据库

面向文档数据库会将数据以文档的形式储存。每个文档都是自包含的数据单元，是一系列数据项的集合。每个数据项都有一个名称与对应的值，值既可以是简单的数据类型，如字符串、数字和日期等；也可以是复杂的类型，如有序列表和关联对象。数据存储的最小单位是文档，同一个表中存储的文档属性可以是不同的，数据可以使用XML、JSON或者JSONB等多种形式存储。
相关产品：MongoDB、CouchDB、RavenDB
有谁在使用：SAP （MongoDB）、Codecademy （MongoDB）、Foursquare （MongoDB）、NBC News （RavenDB）
适用的场景

1. 日志。企业环境下，每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式，所以我们可以使用它储存不同的信息。
2. 分析。鉴于它的弱模式结构，不改变模式下就可以储存不同的度量方法及添加新的度量。
   不适用场景
   在不同的文档上添加事务。Document-Oriented数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案。

• 图（Graph-Oriented）数据库

图数据库允许我们将数据以图的方式储存。实体会被作为顶点，而实体之间的关系则会被作为边。比如我们有三个实体，Steve Jobs、Apple和Next，则会有两个“Founded by”的边将Apple和Next连接到Steve Jobs。
相关产品：Neo4J、Infinite Graph、OrientDB
有谁在使用：Adobe （Neo4J）、Cisco （Neo4J）、T-Mobile （Neo4J）
适用的场景

1. 在一些关系性强的数据中
2. 推荐引擎。如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定
   不适用场景
   不适合的数据模型。图数据库的适用范围很小，因为很少有操作涉及到整个图。

特点

1、易扩展
NoSQL数据库种类繁多，但是一个共同的特点是都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。无形之间，在架构的层面上带来了可扩展的能力。

2、大数据量，高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache。NoSQL的Cache是记录级的，是一种细粒度的Cache,所以NoSQL在这个层面上来说性能就要高很多。
3、灵活的数据模型
NoSQL无须事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是—个噩梦。这点在大数据量的Web 2.0时代尤其明显。
4、高可用
NoSQL在不太影响性能的情况，就可以方便地实现高可用的架构。比如Cassandra、HBase模型，通过复制模型也能实现高可用。

框架体系

非关系型数据库(NoSQL)整体框架分为四层，由下至上分为数据持久层(data persistence)、整体分布层(data distribution model)、数据逻辑模型层(data logical model)、和接口层(interface)，层次之间相辅相成，协调工作。
1、数据持久层定义了数据的存储形式，主要包括基于内存、基于硬盘、内存和硬盘接口、订制可拔插四种形式。其特点如下：

2、整体分布层定义了数据是如何分布的，主要有三种形式：一是CAP支持，可用于水平扩展。二是多数据中心支持，可以保证在横跨多数据中心时也能够平稳运行。三是动态部署支持，可以在运行着的集群中动态地添加或删除节点。
3、数据逻辑模型层表述了数据的逻辑表现形式，与关系型数据库相比，非关系型数据库在逻辑表现形式上相当灵活，主要有四种形式：一是键值模型，这种模型在表现形式上比较单一，但却有很强的扩展性。二是列式模型，这种模型相比于键值模型能够支持较为复杂的数据，但扩展性相对较差。三是文档模型，这种模型对于复杂数据的支持和扩展性都有很大优势。四是图模型，这种模型的使用场景不多，通常是基于图数据结构的数据定制的。详细情况在上面的【分类】中已一一介绍。
4、接口层则是为上层应用提供方便的数据调用接口，主要有六大类接口：其一是常见的REST（Representational State Transfer），采用REST的产品有HBase和CouchDB等。其二是源自Facebook的RPC协议Thrift，支持Thrift的产品有HBase和Cassandra等。其三是用于大规模数据处理的Map/Reduce，其相关产品有HBase，CouchDB和MongoDB等。其四是Get/Put，采用Get/Put的产品有Voldemort等。其五是提供语言特定（Language Specific）的API，比如Java，在这方面做的不错是MongoDB。最后一个是提供SQL的子集，多种选择使得应用程序和数据库的交互更加方便。

适用场景

1、 CouchDB
所用语言： Erlang 特点：DB一致性，易于使用
最佳应用场景：适用于数据变化较少，执行预定义查询，进行数据统计的应用程序。适用于需要提供数据版本支持的应用程序。
例如： CRM、CMS系统。
2.Redis
所用语言：C/C++ 特点：运行异常快
最佳应用场景：适用于数据变化快且数据库大小可遇见（适合内存容量）的应用程序。
例如：股票价格、数据分析、实时数据搜集、实时通讯。
3. MongoDB
所用语言：C++ 特点：保留了SQL一些友好的特性（查询，索引）
最佳应用场景：适用于需要动态查询支持；需要使用索引而不是 map/reduce功能；需要对大数据库有性能要求；需要使用 CouchDB但因为数据改变太频繁而占满内存的应用程序。
例如：你本打算采用 MySQL或 PostgreSQL，但因为它们本身自带的预定义栏让你望而却步。
4. Membase
所用语言： Erlang和C 特点：兼容 Memcache，但同时兼具持久化和支持集群
最佳应用场景：适用于需要低延迟数据访问，高并发支持以及高可用性的应用程序
例如：低延迟数据访问比如以广告为目标的应用，高并发的 web 应用比如网络游戏（例如 Zynga）
（一）假如你的应用有以下需求：
复杂事物，如果你不能承受数据丢失的风险或者你想要一个简单的事务编程模型可以选择关系数据库和网格数据库。
例子：一个库存系统需要完整的ACID特性。如果我在买了一个东西后才被告知它已经售罄我会非常不快。不不想要补偿，我只要我买的东西。
扩展性，NoSQL或SQL皆可，目标产品要支持水平扩展、分区、在线增减硬件、负载均衡、自动分片、数据平衡和容错等特性。
追求高可用性，可用Bigtable类型的等支持最终一致性的数据库。
需要处理长期的快速读写，可以看看文档数据库，Key-value数据库或者内存数据库，还可以考虑SSD。
要实现社会化网络，第一选择应该是图数据库。其次像Riak这样支持关系的数据库也可以。一个支持简单SQL join操作的内存关系数据库能够处理数据量不大的情况。Redis’ set 和list 操作就是这样。
（二）假如你的应用有以下需求：
用于实时事务处理的物化视图，可以考虑VoltDB，非常适合于快速处理大量事务。
企业级支持及服务级协议 ，可以寻找市场上以此为卖点的产品，如Membase。
要记录连续的大量数据，又对一致性无太高要求，可以看看Bigtable类型数据库，因为它工作在分布式文件系统上，可以处理大规模的写入请求。
需要尽可能使用简单，请考虑PAAS方案，用这种方案你自己几乎不需要做什么。
如果你的产品要卖给企业客户请考虑关系数据库，因为他们习惯于关系数据库。
要动态构建对象间的关系，对象的属性能够动态加减，可以考虑图数据库，因为它不需要schema，可以在代码中随需建模。
要支持大影音文件，可以看看像S3这样的存储服务。NoSQL不适于存储BLOBS，尽管MongoDB也提供了文件服务。
（三）假如你的应用有以下需求：
要快速批量上传大量数据，得寻找支持这种场景的产品。但是大多数产品都不支持批量操作。
易于变化，要选择支持动态schema的文档数据库和 Key-value数据库。它支持可选域，不需要修改schema即可增加、减少域。
为了支持完整性约束，选择支持SQL DDL的数据库，可以在存储过程或者应用代码中实现。
深度连接用图数据库，它支持实体键间的快速定位。
为了让计算靠近数据，减少数据在网络中传送的开销，可以考虑存储过程。关系数据库，网个数据库，文档数据库和Key-value数据库都支持存储过程。

开源的NoSQL数据库软件介绍

目前，NoSQL数据库变得越来越流行，NoSQL数据库具有很好的可伸缩性与灵活性，非常适合于大数据存储与处理。相较于传统的关系型数据库，NoSQL数据库在性能上具有很大的优势。其中MongoDB是这些开源NoSQL数据库中最好的。常用的NoSQL数据库有以下几种：

1. MongoDB
   MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。它的特点是高性能、易部署、易使用，存储数据。
   
   主要功能特性有：
   *面向集合存储，易存储对象类型的数据。
   *模式自由。
   *支持动态查询。
   *支持完全索引，包含内部对象。
   *支持查询。
   *支持复制和故障恢复。
   *使用高效的二进制数据存储，包括大型对象（如视频等）。
   *自动处理碎片，以支持云计算层次的扩展性
   *支持RUBY，PYTHON，JAVA，C，C#，C++，PHP等多种语言。
   *文件存储格式为BSON（一种JSON的扩展）
   *可通过网络访问
   所谓“面向集合”（Collenction-Orented），意思是数据被分组存储在数据集中，被称为一个集合（Collenction)。每个 集合在数据库中都有一个唯一的标识名，并且可以包含无限数目的文档。集合的概念类似关系型数据库（RDBMS）里的表（table），不同的是它不需要定义任何模式（schema)。
   模式自由（schema-free)，意味着对于存储在mongodb数据库中的文件，我们不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。
   存储在集合中的文档，被存储为键-值对的形式。键用于唯一标识一个文档，为字符串类型，而值则可以是各中复杂的文件类型。我们称这种存储形式为BSON（Binary Serialized dOcument Format）。
   MongoDB服务端可运行在Linux、Windows或OS X平台，支持32位和64位应用，默认端口为27017。推荐运行在64位平台，因为MongoDB在32位模式运行时支持的最大文件尺寸为2GB。

2. Cassandra
   Cassandra是一套开源分布式NoSQL数据库系统。它最初由Facebook开发，用于储存收件箱等简单格式数据，集GoogleBigTable的数据模型与Amazon Dynamo的完全分布式的架构于一身。Facebook于2008将 Cassandra 开源。
   
   主要特性：
   *分布式
   *基于column的结构化
   *高伸展性
   Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra 的一个写操作，会被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能 是比较简单的事情，只管在群集里面添加节点即可。
   支持度虽不如文档存储MongoDB，但和其他数据库比较，有几个突出特点：
   模式灵活 ：使用Cassandra，像文档存储，你不必提前解决记录中的字段。你可以在系统运行时随意的添加或移除字段。这是一个惊人的效率提升，特别是在大型部署上。
   真正的可扩展性 ：Cassandra是纯粹意义上的水平扩展。为给集群添加更多容量，可以指向另一台电脑。不必重启任何进程，改变应用查询，或手动迁移任何数据。
   多数据中心识别 ：你可以调整你的节点布局来避免某一个数据中心起火，一个备用的数据中心将至少有每条记录的完全复制。

3. CouchDB
   
   这也是Apache软件基金会的一个项目，CouchDB是另一个面向文档的数据库，以JSON格式存储数据。它兼容于ACID，像MongoDB一样，CouchDB也可以用于存储网站的数据与内容，以及提供缓存等。可以通过JavaScript在CouchDB上运行MapReduce查询。此外，CouchDB还提供了一个非常方便的基于Web的管理控制台。它非常适合于Web应用。
   与现在流行的关系数据库服务器不同，CouchDB 是围绕一系列语义上自包含的文档而组织的。 CouchDB 中的文档是没有模式的（schema free），也就是说并不要求文档具有某种特定的结构。 CouchDB 的这种特性使得相对于传统的关系数据库而言，有自己的适用范围。一般来说，围绕文档来构建的应用都比较适合使用 CouchDB 作为其后台存储。
   CouchDB 强调其中所存储的文档，在语义上是自包含的。这种面向文档的设计思路，更贴近很多应用的问题域的真实情况。对于这类应用，使用 CouchDB 的文档来进行建模，会更加自然和简单。与此同时，CouchDB 也提供基于 MapReduce 编程模型的视图来对文档进行查询，可以提供类似于关系数据库中 SQL 语句的能力。

4. Hypertable
   Hypertable模仿的是Google的BigTable数据库系统。Hypertable的创建者将“成为高可用、PB规模的数据库开源标准”作为Hypertable的目标。换言之，Hypertable的设计目标是跨越多个廉价的服务器可靠地存储大量数据。Hypertable 是一个正在进行中的开源项目，以google的bigtable论文为基础指导，使用c++语言实现。
   目标:是为了解决大并发，大数据量的数据库需求。目前只支持最基本的查询功能
   缺点: ①不支持事物, 不支持关联查询.
   ②对单条查询的响应时间可能也不如传统数据库（数据量越大，对hypertable越有利）。
   优点: ①并发性: 可以处理大量并发请求，和管理大量数据。
   ②规模:可扩缩性好，扩容只需要增加集群中的机器就ok了。
   ③可用性: 任何节点失效，既不会造成系统瘫痪也不会丢失数 据。在集群节点足够的情况下，并发量和数据量对性能基本没有影响。

5. Redis
   
   这是个开源、高级的键值存储。由于在键中使用了hash、set、string、sorted set及list，因此Redis也称作数据结构服务器。redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类keyvalue存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Python，Ruby，Erlang，PHP客户端，使用很方便。
   Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务 器。Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。

6. Riak
   
   Riak 是一个去中心化的 key-value 存储服务器，提供一个灵活的 map/reduce 引擎，一个友好的 HTTP/JSON 查询接口。

7. Neo4j
   Neo4j是一个用Java实现、完全兼容ACID的图形数据库。Neo4j既可作为无需任何管理开销的内嵌数据库使用；也可以作为单独的服务器使用，在这种使用场景下，它提供了广泛使用的REST接口，能够方便地集成到基于PHP、.NET和JavaScript的环境里。
   Neo4j的典型数据特征：
   • 数据结构不是必须的，甚至可以完全没有，这可以简化模式变更和延迟数据迁移。
   • 可以方便建模常见的复杂领域数据集，如CMS里的访问控制可被建模成细粒度的访问控制表，类对象数据库的用例、TripleStores以及其他例子。
   • 典型使用的领域如语义网和RDF、LinkedData、GIS、基因分析、社交网络数据建模、深度推荐算法以及其他领域。

8. Hadoop HBase
   HBase是一款可伸缩、分布式的大数据存储。它可以用在数据的实时与随机访问的场景下。HBase拥有模块化与线性的可伸缩性，并且能够保证读写的严格一致性。HBase提供了一个Java API，可以实现轻松的客户端访问；提供了可配置且自动化的表分区功能；还有Bloom过滤器以及block缓存等特性。
   HBase 是Hadoop的一个子项目,HBase采用了Google BigTable的稀疏的,面向列的数据库实现方式的理论,建立在hadoop的hdfs上,一方面里用了hdfs的高可靠性和可伸缩行,另外一方面里用了BigTable的高效数据组织形式.可以说HBase为海量数据的real-time相应提供了很好的一个开源解决方案.

9. Couchbase
   Couchbase是CouchDB的派生，不过它已经成为了一款功能完善的数据库产品。它向文档数据库转移的趋势会让MongoDB感到压力。每个节点上它都是多线程的，这是个非常主要的可伸缩性优势，特别是当托管在自定义或是Bare-Metal硬件上时更是如此。
   Couchbase Server 是一个集群化的、基于文档的数据库系统，它使用一个缓存层来提供非常快的数据访问，将大部分数据都存储在 RAM 中。该系统使用多个节点和一个自动分散在整个集群上的缓存层。这实现了一种弹性，您可扩大和紧缩集群，以便利用更多 RAM 或磁盘 I/O 来帮助提升性能。
   Couchbase Server 中的所有数据最终会持久存储在磁盘中，但最初会通过缓存层执行写入和更新操作，这正是提供高性能的源泉，是我们通过处理 Hadoop 数据来获得实时信息和查询内容时可利用的优势。
   Couchbase Server 的基本形式是一个基本文档和基于键/值的存储。只有在知道文档 ID 时，才能检索集群提供的信息。在 Couchbase Server 2.0 中，可以将文档存储为 JSON 格式，然后使用视图系统在存储的 JSON 文档上创建一个视图。视图是在存储在数据库中的文档上执行的一个 MapReduce 组合。来自视图的输出是一个索引，它通过 MapReduce 函数来匹配您定义的结构。索引的存在提供了查询底层的文档数据的能力。

10. MemcacheDB
    memcachedb是 一个由新浪网的开发人员开放出来的开源项目，给memcached分布式缓存服务器添加了Berkeley DB的持久化存储机制和异步主辅复制机制，让memcached具备了事务恢复能力、持久化能力和分布式复制能力，非常适合于需要超高性能读写速度，但是 不需要严格事务约束，能够被持久化保存的应用场景，例如memcachedb被应用在新浪博客上面。

11. REVENDB
    RavenDB是一个在.NET下的文档型数据库，它具有高扩展性，支持MapReduce，提供RESTful的接口。同时它又支持ACID的事务。

12. Voldemort
    Voldemort是一个分布式键-值（Key-value）存储系统，是Amazon’s Dynamo的一个开源克隆。
    1.支持自动复制数据到多个服务器上。
    2.支持数据自动分割所以每个服务器只包含总数据的一个子集。
    3.提供服务器故障透明处理功能。
    4.支持可拨插的序化支持，以实现复杂的键-值存储，它能够很好的5.集成常用的序化框架如：Protocol Buffers、Thrift、Avro和Java Serialization。
    6.数据项都被标识版本能够在发生故障时尽量保持数据的完整性而不会影响系统的可用性。
    7.每个节点相互独立，互不影响。
    8.支持可插拔的数据放置策略。