1.1 NoSql概述

什么是NoSQL

在现代的计算系统上每天网络上都会产生庞大的数据量。这些数据有很大一部分是由关系数据库管理系统（RDBMS）来处理。 1970年 E.F.Codd’s提出的关系模型的论文 “A relational model of data for large shared data banks”，这使得数据建模和应用程序编程更加简单

NoSQL(NoSQL = Not Only SQL )，意即”不仅仅是SQL”

为什么要使用NoSQL

传统关系型数据库面对海量数据的存储，以及实现高访问量、高并发读/写，显得力不从心；尤其是当面对超大规模、高并发、高吞吐量的大型动态网站的时候，就会暴露出很多难以克服的问题，影响用户体验。为了满足对海量数据的高速存储需求，实现高并发、高吞吐量，NoSQL 应运而生

NoSQL 的出现可以解决传统关系型数据库所不能解决的问题

1) ：NoSQL 解决了高并发读/写问题

Web 2.0 动态网站需要根据用户的个性化信息来实时生成动态页面和提供动态信息，而无法使用动态页面的静态化技术，因此数据库的并发负载就会非常高。比如，微博、朋友圈的实时更新，就会出现每秒上万次的读/写需求。关系型数据库在面对每秒上万次的 SQL 查询操作时还能应对自如，但是在面对每秒上万次的 SQL 写操作时就难以胜任了。

普通的 BBS 系统网站也存在高并发读/写的需求，比如，实时统计在线人数、记录热门帖子的浏览次数等，当面对这些需求时，传统的关系型数据库就会出现大量问题。

2) NoSQL 解决了海量数据的高效率存储和访问问题

面对实时产生的大数据量的存储与查询，关系型数据库是难以应付的，会显得效率非常低；而利用 NoSQL 的高效存储与查询能力，就能解决这个问题。

3) NoSQL 实现了高可用性及高可扩展性

在基于 Web 的架构中，关系型数据库难以进行横向扩展。

当一个网站系统的用户量和访问量与日俱增的时候，数据库没有办法像 Web 服务器或应用服务器那样通过添加更多的硬件来搭建负载均衡的服务器。对于很多提供 24 小时不间断服务的网站来说，对数据库系统的维护升级和扩展是非常折磨人的一件事，往往需要停机维护和数据迁移。

NoSQL 数据库有什么特点

NoSQL 数据库具有如下特点

• 容易扩展，方便使用，数据之间没有关系
• 数据模型非常灵活，无须提前为要存储的数据建立字段类型，随时可以存储自定义的数据格式
• 适合大数据量、高性能的存储
• 具有高并发读/写、高可用性

在什么应用场景下使用 NoSQL

NoSQL 数据库的应用场景比较广泛

• 对于大数据量、高并发的存储系统及相关应用
• 对于一些数据模型比较简单的相关应用
• 对数据一致性要求不是很高的业务场景
• 对于给定 key 来映射一些复杂值的环境
• 对一些大型系统的日志信息的存储
• 存储用户信息，如大型电商系统的购物车、会话等
• 对于多数据源的数据存储
• 对易变化、热点高频信息、关键字等信息的存储

NoSQL四大分类

键值(Key-Value)

键值数据库就像在传统语言中使用的哈希表。可以通过key来添加、查询或者删除数据，鉴于使用主键访问，所以会获得不错的性能及扩展性。

产品

Riak、Redis、Memcached、Amazon’s Dynamo、Project Voldemort

适用场景

储存用户信息，比如会话、配置文件、参数、购物车等等。这些信息一般都和ID(键)挂钩，这种情景下键值数据库是个很好的选择。

不适用场景

1.取代通过键查询，而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径

2.需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据

3.事务的支持。在Key-Value数据库中故障产生时不可以进行回滚

列存储

列存储数据库将数据储存在列族(column family)中，一个列族存储经常被一起查询的相关数据。举个例子，如果我们有一个Person类，我们通常会一起查询他们的姓名和年龄而不是薪资。这种情况下，姓名和年龄就会被放入一个列族中，而薪资则在另一个列族中。

产品

Cassandra、HBase

适用场景

• 日志。可以将数据储存在不同的列中，每个应用程序可以将信息写入自己的列族中

• 博客平台。储存每个信息到不同的列族中。举例：标签储存在一个，类别在一个，文章则在另一个

不适用场景

• 如果需要ACID事务。Vassandra就不支持事务

• 原型设计。如果分析Cassandra的数据结构，就会发现结构是基于期望的数据查询方式而定。在模型设计之初，根本不可能去预测它的查询方式，而一旦查询方式改变，就必须重新设计列族

文档型

面向文档数据库会将数据以文档的形式储存。每个文档都是自包含的数据单元，是一系列数据项的集合。每个数据项都有一个名称与对应的值，值既可以是简单的数据类型，如字符串、数字和日期等;也可以是复杂的类型，如有序列表和关联对象。数据存储的最小单位是文档，同一个表中存储的文档属性可以是不同的，数据可以使用XML、JSON或者JSONB等多种形式存储

产品

MongoDB、CouchDB、RavenDB

适用场景

• 日志。企业环境下，每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式，所以可以使用它储存不同的信息

• 分析。鉴于它的弱模式结构，不改变模式下就可以储存不同的度量方法及添加新的度量

不适用场景

在不同的文档上添加事务。Document-Oriented数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案·

图形(Graph)

图数据库允许将数据以图的方式储存。实体会被作为顶点，而实体之间的关系则会被作为边。比如我们有三个实体，Steve Jobs、Apple和Next，则会有两个“Founded by”的边将Apple和Next连接到Steve Jobs

产品：

Neo4J、Infinite Graph、OrientDB

适用场景

1.在一些关系性强的数据中

2.推荐引擎。如果将数据以图的形式表现，那么将会非常有益于推荐的制定

不适用场景

不适合的数据模型。图数据库的适用范围很小，因为很少有操作涉及到整个图

NoSQL数据库对比