非关系型数据库（NoSQL）综述
简介以及与关系型数据库的对比
1、简介：
非关系型数据库也叫Nosql数据库，全称是not only sql。
2009年初，Johan Oskarsson举办了一场关于开源分布式数据库的讨论，Eric Evans在这次讨论中提出了NoSQL一词，用于指代那些非关系型的，分布式的，且一般不保证遵循ACID原则的数据存储系统。Eric Evans使用NoSQL这个词，并不是因为字面上的“没有SQL”的意思，他只是觉得很多经典的关系型数据库名字都叫“**SQL”,所以为了表示跟这些关系型数据库在定位上的截然不同，就是用了“NoSQL“一词。
非关系型数据库提出另一种理念，例如，以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中，要对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。
2、关系型数据库与非关系型数据库的区别：
关系型数据库通过外键关联来建立表与表之间的关系，非关系型数据库通常指数据以对象的形式存储在数据库中，而对象之间的关系通过每个对象自身的属性来决定。
分类
1、 基于列的数据库（column-oriented）
基于列的数据库会将每一列分开单独存放，当查找一个数量较小的列的时候其查找速度是很快的。基于列数据库是将数据映射到行号上面，在基于列的数据库中要想增加一列新的数据是很容易的，因为现有的那些列是不会受新增列的影响的。基于列的数据库的优势在于分析数据和对数据形成一个报告方面，例如对值求和、计算整条记录等。现在使用基于列的数据库存储数据的有Apache HBase，Facebook’s Cassandra，Hypertable和grandfather of wide-column stores，Google BigTable。
相关产品：Cassandra, HBase, Riak
典型应用：分布式的文件系统
数据模型：以列簇式存储，将同一列数据存在一起
优势：查找速度快，可扩展性强，更容易进行分布式扩展
劣势：功能相对局限
2、 键值对存储（Key-Value Stores）
键值对的存储方式在NoSQL数据库中是最简单的一种，其结构就像其名字所示，是一个key-value的集合。如图五所示的那样。这种方式在NoSQL数据库类型中是最可扩展的一种类型，并且可以存储大量的数据。
键值对中存储的数据的类型是不受限制的，可以是一个字符串，也可以是一个数字，甚至是由一系列的键值对封装成的对象等。图六向我们展示了一个比较复杂的键值对结构。使用价值对存储的数据库有Redis，Voldemort，Riak和Amazon’s Dynamo。
相关产品： Tokyo Cabinet/Tyrant、Redis、Voldemort、Berkeley DB
典型应用： 内容缓存，主要用于处理大量数据的高访问负载。
数据模型： 一系列键值对
优势： 快速查询
劣势： 存储的数据缺少结构化
3、 面向文档（Document-Oriented）数据库
面向文档数据库会将数据以文档的形式储存。每个文档都是自包含的数据单元，是一系列数据项的集合。每个数据项都有一个名称与对应的值，值既可以是简单的数据类型，如字符串、数字和日期等；也可以是复杂的类型，如有序列表和关联对象。数据存储的最小单位是文档，同一个表中存储的文档属性可以是不同的，数据可以使用XML、JSON或者JSONB等多种形式存储。
相关产品：MongoDB、CouchDB、RavenDB
有谁在使用：SAP （MongoDB）、Codecademy （MongoDB）、Foursquare （MongoDB）、NBC News （RavenDB）
适用的场景
- 日志。企业环境下，每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式，所以我们可以使用它储存不同的信息。
- 分析。鉴于它的弱模式结构，不改变模式下就可以储存不同的度量方法及添加新的度量。
不适用场景
在不同的文档上添加事务。Document-Oriented数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案。
4、 图（Graph-Oriented）数据库
图数据库允许我们将数据以图的方式储存。实体会被作为顶点，而实体之间的关系则会被作为边。比如我们有三个实体，Steve Jobs、Apple和Next，则会有两个“Founded by”的边将Apple和Next连接到Steve Jobs。
相关产品：Neo4J、Infinite Graph、OrientDB
有谁在使用：Adobe （Neo4J）、Cisco （Neo4J）、T-Mobile （Neo4J）
适用的场景
- 在一些关系性强的数据中
- 推荐引擎。如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定
不适用场景
不适合的数据模型。图数据库的适用范围很小，因为很少有操作涉及到整个图。
特点
1、易扩展
NoSQL数据库种类繁多，但是一个共同的特点是都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。无形之间，在架构的层面上带来了可扩展的能力。
2、大数据量，高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。- -般MySQL使用Query Cache。NoSQL的Cache是记录级的，是一种细粒度的Cache,所以NoSQL在这个层面上来说性能就要高很多。
3、灵活的数据模型
NoSQL无须事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是—个噩梦。这点在大数据量的Web 2.0时代尤其明显。
4、高可用
NoSQL在不太影响性能的情况，就可以方便地实现高可用的架构。比如Cassandra、HBase模型，通过复制模型也能实现高可用。
NoSQL框架体系
非关系型数据库(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的子集，多种选择使得应用程序和数据库的交互更加方便。
适用场景
- CouchDB
所用语言： Erlang 特点：DB一致性，易于使用
最佳应用场景：适用于数据变化较少，执行预定义查询，进行数据统计的应用程序。适用于需要提供数据版本支持的应用程序。
例如： CRM、CMS系统。
2.Redis
所用语言：C/C++ 特点：运行异常快
最佳应用场景：适用于数据变化快且数据库大小可遇见（适合内存容量）的应用程序。
例如：股票价格、数据分析、实时数据搜集、实时通讯。 - MongoDB
所用语言：C++ 特点：保留了SQL一些友好的特性（查询，索引）
最佳应用场景：适用于需要动态查询支持；需要使用索引而不是 map/reduce功能；需要对大数据库有性能要求；需要使用 CouchDB但因为数据改变太频繁而占满内存的应用程序。
例如：你本打算采用 MySQL或 PostgreSQL，但因为它们本身自带的预定义栏让你望而却步。 - 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数据库都支持存储过程。
支付宝扫一扫
微信扫一扫
