了解NoSQL

时间 2019-11-19

标签了解 nosql 栏目 NoSQL 繁體版

原文原文链接

近期老是提到NoSQL这个词汇。起初仅仅知道，应该是一种数据库而已，仅仅是这样的数据库眼下符合当前互联网的需求，应用比較普遍。逐渐发现，当前的各个公司在招聘信息中会有掌握NoSQL的优先等要求。因而，抱着好奇的心理，来查了一些资料，并进行了整理，来分享给你们！

如下的内容来源于百度百科

NoSQL，泛指非关系型的数据库。

随着互联网web2.0站点的兴起，传统的关系数据库在应付web2.0站点，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很是多难以克服的问题。而非关系型的数据库则由于其自己的特色获得了很是迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤为是大数据应用难题。web

虽然NoSQL流行语火起来才短短一年的时间，但是不能否认，现在已经開始了第二代运动。虽然早期的堆栈代码仅仅能算是一种实验，然而现在的系统已经更加的成熟、稳定。只是现在也面临着一个严酷的事实：技术愈来愈成熟——以致于原来很是好的NoSQL数据存储不得不进行重写。也有少数人以为这就是所谓的2.0版本号。这里列出一些比較知名的工具。可以为大数据创建高速、可扩展的存储库。

基本含义

NoSQL(NoSQL = Not Only SQL )，意即“不不过 SQL ”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势愈加高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一律念无疑是一种全新的思惟的注入。

NNoSQL数据库的四大分类

键值( Key-Value )存储数据库

这一类数据库主要会使用到一个 哈希表。 这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来讲的优点在于简单、易部署。

但是假设DBA仅仅对部分值进行查询或更新的时候。Key/value就显得效率低下了。^[3] 举好比：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.面试

列存储数据库。

这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特色是指向了多个列。这些列是由列家族来安排的。如：Cassandra, HBase, Riak.

文档型数据库

文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相相似。

该类型的数据模型是版本号化的文档。半结构化的文档以特定的格式存储，比方JSON。文档型数据库可以看做是键值数据库的升级版，赞成之间嵌套键值。算法

而且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。sql

图形(Graph)数据库

图形结构的数据库同其它行列以及刚性结构的SQL数据库不一样，它是使用灵活的图形模型。并且能够扩展到多个server上。

NoSQL数据库没有标准的查询语言(SQL)，所以进行数据库查询需要制定数据模型。不少NoSQL数据库都有REST式的数据接口或者查询API。数据库

^[2] 如：Neo4J, InfoGrid, Infinite Graph.缓存

所以，咱们总结NoSQL数据库在下面的这几种状况下比較适用：一、数据模型比較简单；二、需要灵活性更强的IT系统；三、对数据库性能要求较高。四、不需要高度的数据一致性。五、对于给定key，比較easy映射复杂值的环境。

3NoSQL数据库的四大分类表格分析

分类	Examples举例	典型应用场景	数据模型	长处	缺点
键值（key-value）	Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB	内容缓存，主要用于处理大量数据的高訪问负载，也用于一些日志系统等等。	Key 指向 Value 的键值对，通常用hash table来实现	查找速度快	数据无结构化，一般仅仅被看成字符串或者二进制数据
列存储数据库	Cassandra, HBase, Riak	分布式的文件系统	以列簇式存储，将同一列数据存在一块儿	查找速度快。可扩展性强。更easy进行分布式扩展	功能相对局限
文档型数据库	CouchDB, MongoDb	Web应用（与Key-Value相似，Value是结构化的，不一样的是数据库能够了解Value的内容）	Key-Value相应的键值对，Value为结构化数据	数据结构要求不严格。表结构可变，不需要像关系型数据库同样需要预先定义表结构	查询性能不高。而且缺少统一的查询语法。
图形(Graph)数据库	Neo4J, InfoGrid, Infinite Graph	社交网络，推荐系统等。专一于构建关系图谱安全	图结构	利用图结构相关算法。比方最短路径寻址，N度关系查找等	很是多时候需要对整个图作计算才干得出需要的信息，而且这样的结构不太好作分布式的集群方案。 ^[3] 网络

4

对于NoSQL并无一个明白的范围和定义，但是他们都广泛存在如下一些共同特征：

不需要提早定义模式：不需要共同特征事先定义数据模式，提早定义表结构。数据中的每条记录均可能有不一样的属性和格式。

当插入数据时，并不需要预先定义它们的模式。数据结构
无共享架构：相对于将所有数据存储的存储区域网络中的全共享架构。NoSQL每每将数据划分后存储在各个本地server上。因为从本地磁盘读取数据的性能每每好于经过网络传输读取数据的性能，从而提升了系统的性能。
弹性可扩展：可以在系统执行的时候，动态添加或者删除结点。不需要停机维护。数据可以本身主动迁移。
分区：相对于将数据存放于同一个节点，NoSQL数据库需要将数据进行分区。将记录分散在多个节点上面。并且一般分区的同一时候还要作复制。这样既提升了并行性能，又能保证没有单点失效的问题。
异步复制：和RAID存储系统不一样的是。NoSQL中的复制，每每是基于日志的异步复制。

这样。数据就可以尽快地写入一个节点，而不会被网络传输引发拖延。缺点是并不老是能保证一致性，这种方式在出现问题的时候。可能会丢失少许的数据。架构
BASE：相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。

BASE是终于一致性和软事务。

NoSQL数据库并无一个统一的架构，两种NoSQL数据库之间的不一样，甚至远远超过两种关系型数据库的不一样。

可以说，NoSQL各有所长。成功的NoSQL一定特别适用于某些场合或者某些应用，在这些场合中会远远赛过关系型数据库和其它的NoSQL。

NoSQL数据库的四大分类

键值(Key-Value)存储数据库
这一类数据库主要会使用到一个哈希表。这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来讲的优点在于简单、易部署。但是假设DBA仅仅对部分值进行查询或更新的时候，Key/value就显得效率低下了。

[3] 举好比：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
列存储数据库。
这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在。但是它们的特色是指向了多个列。这些列是由列家族来安排的。

如：Cassandra, HBase, Riak.
文档型数据库
文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相相似。该类型的数据模型是版本号化的文档。半结构化的文档以特定的格式存储，比方JSON。文档型数据库可以看做是键值数据库的升级版。赞成之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。

图形(Graph)数据库
图形结构的数据库同其它行列以及刚性结构的SQL数据库不一样，它是使用灵活的图形模型，并且能够扩展到多个server上。

NoSQL数据库没有标准的查询语言(SQL)，所以进行数据库查询需要制定数据模型。不少NoSQL数据库都有REST式的数据接口或者查询API。

[2] 如：Neo4J, InfoGrid, Infinite Graph.
所以，咱们总结NoSQL数据库在下面的这几种状况下比較适用：一、数据模型比較简单；二、需要灵活性更强的IT系统。三、对数据库性能要求较高；四、不需要高度的数据一致性；五、对于给定key，比較easy映射复杂值的环境。

3NoSQL数据库的四大分类表格分析

分类 Examples举例典型应用场景数据模型长处缺点
键值（key-value）[3] Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB 内容缓存，主要用于处理大量数据的高訪问负载，也用于一些日志系统等等。[3] Key 指向 Value 的键值对。通常用hash table来实现[3] 查找速度快数据无结构化，一般仅仅被看成字符串或者二进制数据[3]
列存储数据库[3] Cassandra, HBase, Riak 分布式的文件系统以列簇式存储。将同一列数据存在一块儿查找速度快，可扩展性强。更easy进行分布式扩展功能相对局限
文档型数据库[3] CouchDB, MongoDb Web应用（与Key-Value相似，Value是结构化的，不一样的是数据库能够了解Value的内容） Key-Value相应的键值对，Value为结构化数据数据结构要求不严格。表结构可变。不需要像关系型数据库同样需要预先定义表结构查询性能不高，而且缺少统一的查询语法。
图形(Graph)数据库[3] Neo4J, InfoGrid, Infinite Graph 社交网络。推荐系统等。

专一于构建关系图谱图结构利用图结构相关算法。比方最短路径寻址，N度关系查找等很是多时候需要对整个图作计算才干得出需要的信息，而且这样的结构不太好作分布式的集群方案。[3]
4共同特征

对于NoSQL并无一个明白的范围和定义。但是他们都广泛存在如下一些共同特征：
不需要提早定义模式：不需要事先定义数据模式，提早定义表结构。

数据中的每条记录均可能有不一样的属性和格式。当插入数据时。并不需要预先定义它们的模式。

无共享架构：相对于将所有数据存储的存储区域网络中的全共享架构。NoSQL每每将数据划分后存储在各个本地server上。

因为从本地磁盘读取数据的性能每每好于经过网络传输读取数据的性能，从而提升了系统的性能。
弹性可扩展：可以在系统执行的时候。动态添加或者删除结点。不需要停机维护，数据可以本身主动迁移。

分区：相对于将数据存放于同一个节点，NoSQL数据库需要将数据进行分区，将记录分散在多个节点上面。并且一般分区的同一时候还要作复制。这样既提升了并行性能。又能保证没有单点失效的问题。

异步复制：和RAID存储系统不一样的是，NoSQL中的复制，每每是基于日志的异步复制。

这样，数据就可以尽快地写入一个节点。而不会被网络传输引发拖延。缺点是并不老是能保证一致性。这种方式在出现问题的时候。可能会丢失少许的数据。
BASE：相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。BASE是终于一致性和软事务。
NoSQL数据库并无一个统一的架构，两种NoSQL数据库之间的不一样，甚至远远超过两种关系型数据库的不一样。可以说，NoSQL各有所长。成功的NoSQL一定特别适用于某些场合或者某些应用，在这些场合中会远远赛过关系型数据库和其它的NoSQL。
5适用场景

NoSQL数据库在下面的这几种状况下比較适用：一、数据模型比較简单；二、需要灵活性更强的IT系统；三、对数据库性能要求较高。四、不需要高度的数据一致性。五、对于给定key。比較easy映射复杂值的环境。
6发展示状

计算机体系结构在数据存储方面要求具有庞大的水平扩展性。而NoSQL致力于改变这一现状。Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。
NoSQL项目的名字上看不出什么一样之处，但是，它们一般在某些方面一样：它们可以处理超大量的数据。
这场革命仍然需要等待。的确，NoSQL对大型企业来讲还不是主流，但是，一两年以后很是可能就会变个样子。在NoSQL运动的最新一次聚会中，来自世界各地的150人挤满了CBS Interactive的一间会议室。

分享他们如何推翻缓慢而昂贵的关系数据库的暴政的经验。如何使用更有效和更廉价的方法来管理数据。

“关系型数据库给你强加了太多东西。它们要你强行改动对象数据。以知足RDBMS （relational database management system。关系型数据库管理系统）的需要，”在NoSQL拥护者们看来，基于NoSQL的替代方案“仅仅是给你所需要的”。
水平扩展性(horizontal scalability)指能够链接多个软硬件的特性,这样能够将多个server从逻辑上当作一个实体。
7挑战

虽然大多数NoSQL数据存储系统都已被部署于实际应用中，但概括其研究现状，还有不少挑战性问题。
已有key-value数据库产品大可能是面向特定应用自治构建的，缺少通用性；
已有产品支持的功能有限（不支持事务特性），致使其应用具备必定的局限性；
已有一些研究成果和改进的NoSQL数据存储系统，但它们都是针对不一样应用需求而提出的对应解决方式，如支持组内事务特性、弹性事务等，很是少从全局考虑系统的通用性。也没有造成系列化的研究成果；
缺少相似关系数据库所具备的强有力的理论(如armstrong公理系统)、技术（如成熟的基于启示式的优化策略、两段封锁协议等）、标准规范（如SQL语言）的支持。
眼下，HBase数据库时安全特性最无缺的NoSQL数据库产品之中的一个，而其它的NoSQL数据库多数没有提供内建的安全机制，但随着NoSQL的发展，愈来愈多的人開始意识到安全的重要。部分NoSQL产品逐渐開始提供一些安全方面的支持。
随着云计算、互联网等技术的发展，大数据普遍存在，同一时候也呈现出了不少云环境下的新型应用，如社交网络网、移动服务、协做编辑等。这些新型应用对海量数据管理或称云数据管理系统也提出了新的需求。如事务的支持、系统的弹性等。同一时候云计算时代海量数据管理系统的设计目标为可扩展性、弹性、容错性、自管理性和“强一致性”。

眼下，已有系统经过支持可任意增减节点来知足可扩展性；经过副本策略保证系统的容错性。基于监測的状态消息协调实现系统的自管理性。“弹性”的目标是知足Pay-per-use 模型，以提升系统资源的利用率。该特性是已有典型NoSQL数据库系统所不无缺的，但倒是云系统应具备的典型特色；“强一致性”主要是新应用的需求。

NoSQL数据库在下面的这几种状况下比較适用：一、数据模型比較简单。二、需要灵活性更强的IT系统；三、对数据库性能要求较高；四、不需要高度的数据一致性；五、对于给定key。比較easy映射复杂值的环境。

6发展示状

计算机体系结构在数据存储方面要求具有庞大的水平扩展性，而NoSQL致力于改变这一现状。

Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。

NoSQL项目的名字上看不出什么一样之处。但是，它们一般在某些方面一样：它们可以处理超大量的数据。

这场革命仍然需要等待。

的确，NoSQL对大型企业来讲还不是主流，但是，一两年以后很是可能就会变个样子。在NoSQL运动的最新一次聚会中。来自世界各地的150人挤满了CBS Interactive的一间会议室。

分享他们如何推翻缓慢而昂贵的关系数据库的暴政的经验，如何使用更有效和更廉价的方法来管理数据。

“ 关系型数据库给你强加了太多东西。

它们要你强行改动对象数据。以知足RDBMS （relational database management system。关系型数据库管理系统）的需要。”在NoSQL拥护者们看来。基于NoSQL的替代方案“仅仅是给你所需要的”。

水平扩展性(horizontal scalability)指能够链接多个软硬件的特性,这样能够将多个server从逻辑上当作一个实体。

7挑战

虽然大多数NoSQL数据存储系统都已被部署于实际应用中。但概括其研究现状，还有不少挑战性问题。

已有key-value数据库产品大可能是面向特定应用自治构建的。缺少通用性。
已有产品支持的功能有限（不支持事务特性），致使其应用具备必定的局限性；
已有一些研究成果和改进的NoSQL数据存储系统，但它们都是针对不一样应用需求而提出的对应解决方式，如支持组内事务特性、弹性事务等，很是少从全局考虑系统的通用性。也没有造成系列化的研究成果；
缺少相似关系数据库所具备的强有力的理论(如armstrong公理系统)、技术（如成熟的基于启示式的优化策略、两段封锁协议等）、标准规范（如SQL语言）的支持。
眼下，HBase数据库时安全特性最无缺的NoSQL数据库产品之中的一个，而其它的NoSQL数据库多数没有提供内建的安全机制，但随着NoSQL的发展，愈来愈多的人開始意识到安全的重要，部分NoSQL产品逐渐開始提供一些安全方面的支持。

随着云计算、互联网等技术的发展。大数据普遍存在，同一时候也呈现出了不少云环境下的新型应用，如社交网络网、移动服务、协做编辑等。这些新型应用对海量数据管理或称云数据管理系统也提出了新的需求，如事务的支持、系统的弹性等。同一时候云计算时代海量数据管理系统的设计目标为可扩展性、弹性、容错性、自管理性和“强一致性”。眼下，已有系统经过支持可任意增减节点来知足可扩展性；经过副本策略保证系统的容错性。基于监測的状态消息协调实现系统的自管理性。“弹性”的目标是知足Pay-per-use 模型。以提升系统资源的利用率。该特性是已有典型NoSQL数据库系统所不无缺的，但倒是云系统应具备的典型特色。“强一致性”主要是新应用的需求。

如下的内容借鉴：http://www.infoq.com/cn/news/2011/01/nosql-why/

NOSQL的优点

易扩展

NoSQL数据库种类繁多，但是一个共同的特色都是去掉关系数据库的关系型特性。数据之间无关系，这样就很easy扩展。

也无形之间。在架构的层面上带来了可扩展的能力。

大数据量，高性能

NoSQL数据库都具备很是高的读写性能，尤为在大数据量下。相同表现优秀。这得益于它的无关系性，数据库的结构简单。

通常MySQL使用Query Cache。每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用。Cache性能不高。而NoSQL的Cache是记录级的。是一种细粒度的Cache，因此NoSQL在这个层面上来讲就要性能高很是多了。

灵活的数据模型

NoSQL无需事先为要存储的数据创建字段，随时可以存储本身定义的数据格式。而在关系数据库里，增删字段是一件很麻烦的事情。假设是很大数据量的表。添加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤为明显。

高可用

NoSQL在不太影响性能的状况，就可以方便的实现高可用的架构。比方Cassandra，HBase模型，经过复制模型也能实现高可用。

总结

NoSQL数据库的出现。弥补了关系数据（比方MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。

MySQL和NoSQL都有各自的特色和使用的应用场景，二者的紧密结合将会给web2.0的数据库发展带来新的思路。

让关系数据库关注在关系上。NoSQL关注在存储上。

传统关系数据库的瓶颈

传统的关系数据库具备不错的性能。高稳定型，久经历史考验，而且使用简单，功能强大。同一时候也积累了大量的成功案例。

在互联网领域，MySQL成为了绝对靠前的王者，绝不夸张的说，MySQL为互联网的发展作出了卓越的贡献。

在90年代，一个站点的訪问量通常都不大，用单个数据库全然可以轻松应付。在那个时候，不少其它的都是静态网页，动态交互类型的站点很少。

到了近期10年。站点開始高速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。

在初期。论坛的流量事实上也不大。假设你接触网络比較早。你可能还记得那个时候还有文本型存储的论坛程序，可以想象通常的论坛的流量有多大。

Memcached+MySQL

后来。随着訪问量的上升。差点儿大部分使用MySQL架构的站点在数据库上都開始出现了性能问题，web程序再也不只专一在功能上。同一时候也在追求性能。

程序猿们開始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。開始比較流行的是经过文件缓存来缓解数据库压力。但是当訪问量继续增大的时候，多台web机器经过文件缓存不能共享。大量的小文件缓存也带了了比較高的IO压力。在这个时候，Memcached就天然的成为一个很时尚的技术产品。

Memcached做为一个独立的分布式的缓存server，为多个webserver提供了一个共享的高性能缓存服务。在Memcachedserver上，又发展了依据hash算法来进行多台Memcached缓存服务的扩展，而后又出现了一致性hash来解决添加或下降缓存server致使又一次hash带来的大量缓存失效的弊端。当时，假设你去面试，你说你有Memcached经验，确定会加分的。

Mysql主从读写分离

由于数据库的写入压力添加。Memcached仅仅能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分站点開始使用主从复制技术来达到读写分离。以提升读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的站点标配了。

分表分库

随着web2.0的继续快速发展。在Memcached的快速缓存，MySQL的主从复制，读写分离的基础之上。这时MySQL主库的写压力開始出现瓶颈。而数据量的持续猛增，由于MyISAM使用表锁。在高并发下会出现严重的锁问题。大量的高并发MySQL应用開始使用InnoDB引擎取代MyISAM。

同一时候。開始流行使用分表分库来缓解写压力和数据增加的扩展问题。这个时候。分表分库成了一个热门技术。是面试的热门问题也是业界讨论的热门技术问题。

也就在这个时候，MySQL推出了还不太稳定的表分区。这也给技术实力通常的公司带来了但愿。

尽管MySQL推出了MySQL Cluster集群，但是由于在互联网差点儿没有成功案例，性能也不能知足互联网的要求，仅仅是在高可靠性上提供了很大的保证。

MySQL的扩展性瓶颈

在互联网，大部分的MySQL都应该是IO密集型的，其实，假设你的MySQL是个CPU密集型的话，那么很是可能你的MySQL设计得有性能问题，需要优化了。大数据量高并发环境下的MySQL应用开发愈来愈复杂，也愈来愈具备技术挑战性。分表分库的规则把握都是需要经验的。

尽管有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发人员的复杂性，但是避免不了整个架构的复杂性。分库分表的子库到必定阶段又面临扩展问题。还有就是需求的变动，可能又需要一种新的分库方式。

MySQL数据库也经常存储一些大文本字段。致使数据库表很的大。在作数据库恢复的时候就致使很的慢。不easy高速恢复数据库。比方1000万4KB大小的文本就接近40GB的大小，假设能把这些数据从MySQL省去，MySQL将变得很的小。

关系数据库很是强大。但是它并不能很是好的应付所有的应用场景。

MySQL的扩展性差（需要复杂的技术来实现）。大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发者面临的问题。

以上的就是我总结的有关NoSQL的内容，从以上的内容可以看出，NoSQL一定会引发一次数据库的潮流