Redis从入门到精通——初识NoSQL
初识NoSQL
一、什么是NoSQL
NoSQL 不仅仅是 SQL，它是 Not Only SQL 的缩写，也是众多非关系数据库的统称。NoSQL 和关系数据库一样，也是用来存储数据的仓库。
为什么需要使用 NoSQL？
随着互联网的高速发展，数据量、访问量呈爆发式增长，人们对网络的需求逐渐多样化。比如，通过 QQ、微信、微博等进行聊天讨论，刷朋友圈，点赞，互评；又如，通过各大视频网站、音乐网站看视频、看直播、听音乐等，这么多数据都是需要存储的。然而，传统的关系型数据库面对这些海量数据的存储，以及实现高访问量、高并发读/写，就会显得力不从心，尤其是面对超大规模、高并发、高吞吐量的大型动态网站的时候，就会暴露出很多难以克服的问题，影响用户体验。为了满足对海量用户的高速存储需求，实现高并发、高吞吐量，NoSQL 应运而生。NoSQL 解决了传统关系型数据库不能解决的问题。
1.1 NoSQL 的出现解决了高并发读/写问题
Web2.0 动态网站需要根据用户的个性化信息来实时生成动态页面和提供动态信息，而无法使用动态页面的静态技术，因此数据库的并发负载就会非常高。比如，微博、朋友圈的实时更新，就会出现每秒上万次的读/写需求。关系型数据库在面对每秒上万次的SQL查询操作时还能应对自如，但是面对每秒上万次的 SQL 写操作时就难以胜任了。普通的 BBS 系统网站也存在高并发读/写的需求，比如，实时统计在线人数、记录热门帖子的浏览次数等，当面对这些需求时，传统的关系型数据库就会出现大量问题。
1.2 NoSQL 的出现解决了海量数据的高效率存储和访问问题
面对实时产生的大量数据量的存储与查询，关系型数据库是难以应付的，会显得效率非常低；而利用 NoSQL 的高效存储与查询能力，就能解决这个问题。
1.3 NoSQL 的出现实现了高可用及高可扩展性
在基于 Web 的架构中，关系型数据库难以进行横向扩展。当一个网站系统的用户量和访问量与日俱增的时候，数据库没有办法像 Web 服务器那样通过添加更多的硬件来搭建负载均衡的服务器。对于很多提供 24 小时不间断服务的网站来说，对数据库系统的维护升级和扩展是非常折磨人的一件事，往往需要停机维护和数据迁移。
NoSQL 的出现解决了大规模数据集中和数据种类不同所带来的各种问题，尤其是大数据实现的困难。其特点为：
- 容易扩展，方便使用，数据之间没有关系。
- 数据模型非常灵活，无须提前为要存储的数据建立字段类型，随时可以存储自定义的数据格式。
- 适合大数据量、高性能的存储。
- 具有高并发读/写、高可用性。
二、NoSQL 与传统关系型数据库的比较
我们通过以下几个方面比较 NoSQL 与传统关系型数据库。
2.1 使用成本
NoSQL：NoSQL 使用简单，易搭建，大部分是开源软件，比较廉价，任何人都可以使用。
关系型数据库：相对于 NoSQL，关系型数据库通常需要安装部署，开源的比较少，使用成本比较昂贵。尤其是 Oracle 数据库，需要花费大量资金购买，使用成本比较高。
2.2 存储形式
NoSQL：NoSQL 具有丰富的存储形式，如 key-value（键值对）形式、图结构形式、文档形式、列簇形式等，因此它可以存储各种类型的数据。
关系型数据库：关系型数据库是采用关系型数据模型来组织的，它是行列表结构，通过行与列的二元形式表示出来，数据之间有很强的关联性。它采用二维表结构的形式对数据进行持久存储。
2.3 查询速度
NoSQL：NoSQL 将数据存储在系统的缓存中，不需要经过 SQL 层的解析，因此查询效率很高。
关系型数据库：关系型数据库将数据存储在系统的硬盘中，在查询的时候需要经过 SQL 层的解析，然后读入内存，实现查询，因此查询效率较低。
2.4 扩展性
NoSQL：NoSQL 去掉了传统关系型数据库表与字段之间的关系，实现了真正意义上的扩展。它采用键值对的形式存储数据，消除了数据之间的耦合性，因此易扩展。
关系型数据库：由于关系型数据库采用关系型数据模型来存储数据，数据与数据之间的关联性较强，存在耦合性，因此不易于扩展。尤其是存在多表连接（join）查询机制的限制，是的扩展很难实现。
2.5 是否支持 ACID 特性
ACID 特性是指数据库事务的执行要素，包括原子性、一致性、隔离性、持久性。
NoSQL：NoSQL 一般不支持 ACID 特性，它实现最终一致性。
关系型数据库：关系型数据库支持 ACID 特性，具有严格的数据一致性。
2.6 是否支持 SQL 语句
NoSQL：SQL 语句在 NoSQL 中是不被支持的，NoSQL 没有声明性查询语句，且没有预定义的模式。
关系型数据库：关系型数据库支持 SQL 语句，也支持复杂的查询。SQL 是结构化查询语言、数据操纵语言、数据定义语言。
NoSQL 与传统数据库是互补的关系，对方的劣势就是自己的优势，反之亦然。
三、在什么应用场景下使用 NoSQL
-
- 对于大数据量、高并发的存储系统及相关应用。
- 对于一些数据模型比较简单相关应用
- 对数据一致性要求不是很高的业务场景
- 对于给定 key 来映射一些复杂值的环境
- 对一些大型系统的日志信息的存储
- 存储用户信息，如大型电商系统的购物车、会话等。
- 对于多数据源的数据存储
- 对易变化、热点高频信息、关键字等信息的存储
四、NoSQL的 4 种数据模型
4.1 键值对数据模型
键值对数据模型就是采用键值对形式将数据存储在一张哈希表中的一类数据库，这张哈希表具有一个特定的键和一个特定数据的指针。键值对存储中的值可是任意类型的值，如数字、字符串，也可以是封装在对象中的新的键值对。
当采用该类数据库存储数据时，需要定义数据结构（半结构化）才能进行存储。
比如：Redis、Memcached、Voldemort、Berkeley DB 等
4.2 列数据模型
列数据模型就是将数据按照列簇形式来存储的一类数据库，通常用于存储分布式系统的海量数据。它也有键，这些键指向多个列，由数据库的列簇来统一安排。
当采用该类数据库存储数据时，需要定义数据结构（半结构化）才能进行存储。
比如：HBase、Cassandra、Riak 等
4.3 文档数据模型
文档数据模型以文档形式进行存储，它是键值对数据模型的升级版，是版本化的文档。它可以使用模式来指定某个文档结构，通常采用特定格式来存储半结构化的文档，最常使用的存储是XML、JSON。每个文档都是自包含的数据单元，是一系列数据项的集合。
当采用该类数据库存储数据时，不需要定义数据结构（非结构化）就可以存储。
比如：MongoDB、CouchDB、RavenDB 等
4.4 图数据模型
图数据模型采用图结构形式存储数据，它是最复杂的 NoSQL ，常被用于存储一些社交网络的社交关系，适用于存储高度互联的数据。它由多个节点和多条边组成，节点表示实体，边表示两个实体之间的关系。
主要用于存储图片信息的一类数据库。
比如：Neo4j、InfoGrid、Infinite Graph 等
其中，键值对数据模型、列数据模型、文档数据模型统称为聚合模型，它们有一个共同特点：可以把一组相互关联的对象看作一个整体单元来操作，通常把这个单元成为一个聚合。
五、各类 NoSQL 数据库的比较
| 分类 | 典型代表 | 数据模型 | 优点 | 缺点 | 适用场景 | 不适用场景 |
| 键值对存储数据库 |
Reids Memcached Voldemort Berkeley DB |
一系列 key 指向 value 的键值对，通常采用哈希表来实现 |
（1）查询速度快 （2）保存速度快 （3）兼具临时性和永久性 |
（1）数据无结构，通常只被当做字符串或二进制数据 （2）当进行临时性保存时，数据有可能丢失 |
（1）做高速缓存，实现大数据量的存储与访问 （2）缓存日志，做日志缓存系统 （3）存储用户信息，如购物车、会话等 |
（1）不适用于通过值来查询的业务 （2）不适用于需要存储数据之间关系的业务 （3）需要对事务提供支持，在遇到故障时事务不可以回滚 |
| 面向列存储数据库 |
HBase Cassandra Riak |
采用列簇形式存储，将同一列数据存放在一起 |
（1）查询速度快 （2）擅长以列为单位读入数据 （3）可扩展性强，尤其是分布式扩展 |
功能相对局限 |
（1）做分布式文件系统 （2）存储日志信息 |
不适用于需要实现 ACID 相关事务的业务 |
| 面向文档数据库 |
MongoDB CouchDB RavenDB |
采用文档形式存储，也可以看作一系列键值对，它的每个数据项都有对应的名称和值 |
（1）无须定义表结构，表结构可变 （2）对数据结构要求不严格 （3）可以使用复杂的查询条件 |
（1）查询性能不高 （2）缺乏统一的查询元 |
（1）Web 应用，与 key-value 类似，value是结构化的，不同的是数据库可以了解 value 的内容 （2）存储日志信息，做相关业务的分析 |
在存储文档数据时，需要在不同的文档上添加事务时不适用 |
| 面向图形数据库 |
Neo4j InfoGrid Infinite Graph |
采用图结构形式存储，实体是一个节点，节点之间的关系是边 | 具有很多图结构算法的支持，如最短路径算法、最小生成树算法等 |
（1）为了得到结果，需要对整个图形进行计算 （2）不利于做分布式应用 （3）适用范围有限 |
（1）应用于大型社交 （2）做相关推荐系统 （3）面对一些关系型强的数据 |
不适用于存储非图结构的数据 |
