前言

自己整理的NoSQL非关系数据库的复习资料
主要来自智库和老师ppt，图片为PPT截图，侵删
NoSQL2020-2021期末考试题回忆
https://blog.csdn.net/lwt1597532486/article/details/111999489
from 韬

---

概念

NOSQL与关系型

关系数据库的不足：大量数据的写入处理；表结构变更及建立索引；字段不固定的应用；对简单查询需要快速返回结果的处理
NoSQL数据库的优势：易于数据的分散；提升性能和增大规模；模式自由；扩展性好

CAP

可用性： 一直可以正常的做读写操作。简单而言就是客户端一直可以正常访问并得到系统的正常响应。用户角度来看就是不会出现系统操作失败或者访问超时等问题

一致性：在分布式系统完成某写操作后任何读操作，都应该获取到该写操作写入的那个最新的值。相当于要求分布式系统中的各节点时时刻刻保持数据的一致性

分区容错性：指的分布式系统中的某个节点或者网络分区出现了故障的时候，整个系统仍然能对外提供满足一致性和可用性的服务，也就是说部分故障不影响整体使用

选择CA，放弃P - > 关系型数据库
选择CP，放弃A - > 分布式数据库
选择AP，放弃C - > 保证最终一致性，如BASE

BASE

Basically Availble --基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用
响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒
功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

Soft-state --软状态/柔性事务

软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

Eventual Consistency --最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性
最终一致性是一种特殊的弱一致性：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问都能够获取到最新的值
在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟，系统负载和数据复制方案设计等因素

NWR 模型

根据 CAP 理论，一致性，可用性和分区容错性最多只能满足两个，因此需要在一致性
和可用性之间做一平衡 NWR 模型是 Amazon 分布式存储引擎 Dynamo 中使用的技术，将
CAP 的选择权交给了用户，让用户自己选择 CAP 中的哪两个。
NWR 模型中：（下文中备份也可以理解为节点）
 N = N 个备份，即复制的节点数量
 R = 至少读取 R 个备份（成功读操作的最小节点数）
 W = 要写入至少 W 份才认为成功（成功写操作的最小节点数）
 只需要 W+R > N，就可以保证强一致性
在分布式系统中，一般都要有容错性，所以一般 N>3
W+R > N， 所以 R > N-W 所以读取的份数一定要比总备份数减去确保写成功的节点 的差值要大。根据抽屉原理（是吧？），这个时候的读操作，肯定会读到一个最新的写 操作。
优化写性能(AP)（写多读少） 配置 W=1，N=R 这样，写完一个副本就成功，其他的副 本异步复制即可；而 R=N，那么读取数据的时候需要读全部节点的数据，（这个时候可 能会出现数据冲突，需要用户自行判断冲突数据）。
优化读性能(CP)（读多写少） 配置 W=N，R=1 这时，写完所有的副本才算成功，而读 的时候只需读一个副本即可（只能保证读任意节点都一致，不能保证是最新，此时可能 还没有写成功？）。
应用：如使用 NoSQL 做 cache 等业务的时候（只要写好了就可以读）？
平衡读写性能(AC) 当数据不多，单台能搞定，且不需要容错和扩展性的时候，可以配 置 N=1（只有一份数据），根据公式 W+R>N，则 W=1，R=1。这种情况就简化为单机问 题了。

两阶段提交协议

优点：实现简单
缺点：同步阻塞问题
执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
单点故障
由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
数据不一致
在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象
二阶段无法解决的问题
协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交

NewSQL 数据库

含义
NewSQL 是对各种新的可扩展/高性能数据库的简称
 具有 NoSQL 对海量数据的存储管理能力
 保持了传统数据库支持 ACID 和 SQL 等特性
特点
 支持关系数据模型
 使用 SQL 作为其主要接口
举例——VoltDB
云数据库
定义：云数据库是指被优化或部署到一个虚拟计算环境中的数据库

Hbase面向列的数据库

理论

HBase 的主要功能组件

 库函数：链接到每个客户端
 一个 HMaster 主服务器
 许多个 HRegion 服务器
一个 HBase 中存储了许多表。每个表都是一个 HRegion 集合，每个 HRegion 包含了位于某个域区间内的所有数据。
具体存储形式请参考闫中敏老师的 ppt

HDFS

组成：一个 HDFS 集群是由一个 NameNode 和若干个 DataNode 组成
 NameNode 作为主服务器，管理文件系统的命名空间和客户端对文件的访问操作
 DataNode 管理存储的数据
HDFS

实例

手机数据

需求：有一张数据表，其中包含手机号码字段

1. 查询一段时间内固定号码的所有数据
2. 查询一段时间内所有数据
   分析：HBase要想查询快速，只能从rowKey上下手rowKey=phoneNum+时间 可以实现目标1，但是目标2很难实现rowKey=时间+phoneNum 可以实现目标2，但是目标1很难实现，且数据量越来越大可能导致热点问题
   解决思路1：牺牲空间换时间，写数据时同时写入两张表，内容一样，只是一张表rowKey=phoneNum+时间，另一张表rowKey=时间+phoneNum
   解决思路2：牺牲部分空间部分时间，两张表，一张全量表，rowKey=phoneNum+时间，另一张索引表只存rowKey=时间+phoneNum，目标1通过scan全量表就可以实现，目标2先scan索引表然后批量get全量表。

滴滴

场景：订单查询
这份数据使用过滴滴产品的用户都接触过，就是App上的历史订单
近期订单的查询会落在Redis，超过一定时间范围，或者当Redis不可用时，查询会落在HBase上

设计技巧

热点

反转



加盐

WordCount和天气

Redis键值对数据库

概念

Redis 是一个 key-value 数据库， 具有极高的并发读写性能，通过 key 迅速查找到 value，但只能通过 key 查询。key-value 很像是我们 java 中学过的map 结构，以“键值对”存储数据，每一个键（key）都会对应一个唯一的值（value）， 类似哈希表，可以通过 key 来添加、查询、删除，这样的数据结构性能极高， 扩展性亦良好。 支持的数据类型包括 string、list、set、zset(有序集合)和 hash 。支持 push/pop、add/remove、集合并交差等丰富的操作，而且操作都是原子性的，支持各种不同方式的排序

Redis 使用实例

1. 适用场景 数据高并发的读写 海量数据的读写 对扩展性要求高的数据
2. 不适用场景 需要事务支持(关系型数据库) 基于 sql 结构化查询储存，关系复
   杂
3. 仔细读懂简单的文章投票网站的后端这个例子，注意其中为了实现功能恰好使用的数据结构。加深理解。为什么使用 set，为什么使用 zset？

应用示例

Redis HyperLogLog

文章投票排序

如何使用Redis来构建一个简单的文章投票网站的后端

MongoDB文档

概念

主要特点

面向集合存储，易存储对象类型的数据
模式自由
支持动态查询
支持完全索引，包含内部对象
支持查询
支持复制和故障恢复
使用高效的二进制数据存储，包括大型对象（如视频）
自动处理碎片，以支持云计算层次的扩展性
支持RUBY，PYTHON，JAVA，C++，PHP，C#等多种语言
文件存储格式为BSON（一种JSON的扩展）
可通过网络访问

适用场景

网站数据

o 非常适合实时的插入，更新与查询
o 具备网站实时数据存储所需的复制及高度伸缩性

缓存

o 适合作为信息基础设施的缓存层
o 避免过载：在系统重启之后，由 Mongo 搭建的持久化缓存层可以避免下
层的数据源过载

大尺寸、低价值的数据

o 传统的关系型数据库存储某些数据代价可能会比较昂贵（在此之前，很多
时候程序员往往会选择传统的文件进行存储）

高伸缩性的场景

o 非常适合由数十或数百台服务器组成的数据库
o Mongo 的路线图中已经包含对 MapReduce 引擎的内置支持（什么是路线
图？）
o 内置对 MapReduce 引擎的支持

用于对象及 JSON 数据的存储

o Mongo 的 BSON 数据格式非常适合文档化格式的存储及查询

不适用的场景

高度事务性的系统

如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的
应用程序

传统的商业智能应用

o 针对特定问题的 BI 数据库会产生高度优化的查询方式
o 数据仓库可能是更合适的选择

需要 SQL

应用案例

数据采集服务首先对原始数据进行本地缓存，然后再将文件上传至MongoDB私有云，而没有把原始数据直接以键值对形式写入MongoDB私有云
一方面可以有效的保证原始数据的安全性，在很大程度上避免因网络中断，机房断电等异常造成的数据丢失
另一方面，缓存后的文件写入MongoDB，与键值对写入MongoDB相比，前者速度快的多，能更好适应高速采集数据流的大数据处理
利用多台服务器以MongoDB为基础构建了原始采集数据的云存储架构
通过复制集的应用，利用多台机器之间的异步复制达到故障转移和冗余。每三个Mongo服务构成一组复制集，彼此相互进行“心跳”检测，实现数据的高可用性

Neo4j图数据库

概念

相关

1. 定义：Neo4j 使用图相关的概念来描述数据模型，把数据保存为图中的节点以及节点之间的关系
2. 两个基本概念——节点和边：节点表示实体，边表示实体之间的关系；节点和边都可以有自己的属性；不同实体通过各种不同的关系关联起来，形成复杂的对象图
3. 查找和遍历主要使用深度优先搜索和广度优先搜索两种方式

特点

1. 完整的 ACID 支持
2. 高可用性
3. 轻易扩展到上亿级别的节点和关系
4. 通过遍历工具高速检索数据

遍历

转换

实例

Hello World

歌曲信息管理

状态图

用户角色

总结

NoSQL非关系数据库并不难，认真看看老师PPT，注意PPT的示例和各种数据库的画法，背一下相关概念就好。不考代码或某种数据库的实际操作（实验里检查了）。

NoSQL2020-2021期末考试题回忆
https://blog.csdn.net/lwt1597532486/article/details/111999489
选课推荐选闫老师，讲的仔细（虽然没听），并且ppt全面。听说我们实验太多了，就把NoSQL实验推到考完试（都放假一周了）后交，感激…