山东大学软件学院2022-2023 NOSQL考试知识点整理

1.各种 aaS

云计算四层分——IaaS、PaaS、SaaS、DaaS - 云计算技术 - 深信服社区 (sangfor.com.cn)

2.传统ACID

深入学习MySQL事务：ACID特性的实现原理 - 编程迷思 - 博客园 (cnblogs.com)

数据库ACID四大特性到底为了啥，一文带你看通透__陈哈哈的博客-CSDN博客_acid四大特性

原子性：undolog ——在SQL执行前先于数据持久化到磁盘

持久性：都要过磁盘IO【巨大开销】——引入BufferPool机制

隔离性：上个厕所的功夫，搞懂MySQL事务隔离级别__陈哈哈的博客-CSDN博客

​ 隔离级别越高开销越大，同时并发程度下降。

一致性是事务追求的最终目标：前面提到的原子性、持久性和隔离性，都是为了保证数据库状态的一致性。

支持事务就意味着ACID

3.why NoSQL?

关系型数据库瓶颈：

​ 在上面可以看到，传统数据库为了保证其ACID特性，他的开销是相当大的，几乎所有操作都要到磁盘I/O当中，因此在高并发条件下，磁盘I/O就很容易导致性能瓶颈。【最终表现是在高并发条件下读写慢，即使有各类缓冲池存在，（设计初衷不同，对内存的优化不够好）】

【CAP理论，如果保证高一致性，那么高扩展性和可用性就不可能同时达成】

​ 此外，在基于web的结构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。

对网站来说，关系型数据库的很多特性不再需要了：

​ 事务一致性——允许放弃一部分一致性来换取高可用

​ 关系型数据库在对事物一致性的维护中有很大的开销，而现在很多web2.0系统对事物的读写一致性都不高

​ 比如读写实时性：

​ 对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比如发一条消息之后，过几秒乃至十几秒之后才看到这条动态是完全可以接受的

​ 对海量数据的高效率存储和访问的需求

​ 类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到 了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登 录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。

或者说，多表联查或大表查询带来的开销不可接受【结构化数据】

​ 在关系型数据库中，导致性能欠佳的最主要原因是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。关系型数据库中的表都是存储一个格式化的数据结构，每个元组字段的组成都是一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段。这样的结构可以便于标语表之间进行链接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。

​ Eg.不会局限于固定的结构，可以减少一些时间和空间的开销——KV键值对数据库【不用多表联查】

​ 【固定结构带来的是可以复杂查询，但开销上升，拓展性变差】

总结：

1.对数据库高并发读写的需求——大量磁盘I/O__也可以引出分布式，有新的硬件如CPU等，变相跳开了瓶颈

2.对海量数据的高效率存储和访问的需求——大表，多表查询，结构化数据——OLAP分析型业务，大数据下的查询

3.对数据库的高可扩展性和高可用性的需求——分布式

4.半结构化/非结构化数据存储——大数据下模式和数据的关系，模式难以先确定，甚至要反推模式来处理其他领域问题

NoSQL缺点：

​ 非关系型数据库由于很少的约束，他也不能够提供像SQL所提供的where这种对于字段属性值情况的查询。并且难以体现设计的完整性。他只适合存储一些较为简单的数据，对于需要进行较复杂查询的数据，SQL数据库显的更为合适。

​ 非关系型数据库的实质：非关系型数据库产品是传统关系型数据库的功能阉割版本，通过减少用不到或很少用的功能，来大幅度提高产品性能。具体应用需要权衡。

why NOSQL种类多？

​ 大数据环境下不可能存在一种数据库可以满足所有需求，NoSQL是一类数据库的统称

关系型数据库与非关系型数据库的区别

​ 关系型数据库的最大特点就是事务的一致性：传统的关系型数据库读写操作都是事务的，具有ACID的特点，这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中，如典型的银行系统。

​ 但是，在网页应用中，尤其是SNS应用中，一致性却不是显得那么重要，用户A看到的内容和用户B看到同一用户C内容更新不一致是可以容忍的，或者说，两个人看到同一好友的数据更新的时间差那么几秒是可以容忍的，因此，关系型数据库的最大特点在这里已经无用武之地，起码不是那么重要了。

​ 相反地，关系型数据库为了维护一致性所付出的巨大代价就是其读写性能比较差，而像微博、facebook这类SNS的应用，对并发读写能力要求极高，关系型数据库已经无法应付【在读方面，传统上为了克服关系型数据库缺陷，提高性能，都是增加一级memcache来静态化网页，而在SNS中，变化太快，memcache已经无能为力了】，因此，必须用新的一种数据结构存储来代替关系数据库。

​ 关系数据库的另一个特点就是其具有固定的表结构，因此，其扩展性极差，而在SNS中，系统的升级，功能的增加，往往意味着数据结构巨大变动，这一点关系型数据库也难以应付，需要新的结构化数据存储。

​ 于是，非关系型数据库应运而生，由于不可能用一种数据结构化存储应付所有的新的需求，因此，非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合。 必须强调的是，数据的持久存储，尤其是海量数据的持久存储，还是需要一种关系数据库。

SQL为什么并发读写慢？反之其他两个为什么快？

1.ACID的开销2.传统的全部要过硬盘3.结构性数据4.单点？分布式？

关系型数据库分布式（如MySQL）？

1.由于关系数据库支持事务，切分可能引入分布式事务，但分布式事务对系统资源消耗大，性能也并不高

2.跨节点的join和排序操作：尽管能在数据库端解决(Oracle DBlink,MySQL Federated)，但可能耗费大量的网络资源。通常推荐在应用层进行数据的整合，这需要应用层做很多额外的工作，也加重了应用服务器的负担

4.一致性理论模型

CAP理论

CAP理论：一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个

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

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

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

事实上在设计分布式系统时都会考虑到bug、硬件、网络等各种原因造成的故障，所以即使部分节点或者网络出现故障，也要求整个系统还是要继续使用的

【分区可用性不可以舍弃，则只能在可用性和一致性中做取舍】

CAP取舍

CA: 优先保证一致性和可用性，放弃分区容错。 这也意味着放弃系统的扩展性，系统不再是分布式的，有违设计的初衷。【非分布式系统】【关系型数据库】
**CP: 优先保证一致性和分区容错性，放弃可用性。**在数据一致性要求比较高的场合(如:Zookeeper，Hbase) 是比较常见的做法，一旦发生网络故障或者消息丢失，就会牺牲用户体验，等恢复之后用户才逐渐能访问。【分布式数据库】
**AP: 优先保证可用性和分区容错性，放弃一致性。**放弃一致性不是说一致性就不保证了，而是逐渐的变得一致【保证最终一致性】【BASE模型】

​ 分析时会发现不少数据库宣称同时高可用和强一致，这时要看错误恢复，如HBase，他某个region错误后，会暂停服务并作redo，放弃了可用，则为CP，但这时别的region依然在服务，所以是降低了可用性，不是完全不可用。

一致性强弱

强一致性（即时一致性）：假如A先写入了一个值到存储系统，存储系统保证后续A，B，C的读取操作都将返回最新值；单副本数据容易保证强一致性，多副本数据需要使用分布式事务协议。

弱一致性：假如A先写入了一个值到存储系统，存储系统不能保证后续A，B，C的读取操作能读取到最新值

​ 不一致性窗口：从A写入到后续操作A，B，C读取到最新值这一段时间

​ 窗口的大小依赖于以下的几个因素：交互延迟，系统的负载，以及复制技术中replica的个数（这个可以理解为master/salve模式中，salve的个数）

最终一致性是弱一致性的一种特例

其他最终一致性种类PPT2 20页左右

什么是数据库的一致性？一致性弱意味着什么？NoSQL 的弱一致性又为什么是可以被接受的？ - 知乎 (zhihu.com)

raft协议保证写强一致，读顺序一致

BASE模型

BA—基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用【可能出现如响应时间，功能上的损失】

S—软状态/柔性事务：指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

【即存在不一致性窗口】

E—最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性

在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟，系统负载和数据复制方案设计等因素【即不一致性窗口大小，当然也和分布式事务协议有关】

NWR模型——一致性

N: 复制的节点数量，即副本数

R: 成功读操作的最小节点数

W: 成功写操作的最小节点数

只需W + R > N，就可以保证强一致性，因为读取数据的节点和被同步写入的节点是有重叠的

Eg. TIDB中使用Raft协议，两阶段提交保证写强一致，而不是全部强一致，他读是顺序一致

​ 根据CAP理论，一致性、可用性和分区容错 性最多只能满足两个，因此需要在一致性和可用性之间做一平衡。
​ 如果要高的一致性，那么就配置N=W，R=1,这个时候可用性特别是写操作的性能就会大大降低。
​ 如果想要高的可用性，那么此时就需要放松一致性的要求，此时可以配置W=1，这样使得写操作延迟最低，同时通过异步的机制更新剩余的N-W个节点。

两阶段提交协议——分布式事务

​ 可以保证分布式事务中，要么所有参与的进程都提交事务成功，要么都取消事务，这样做可以在分布式环境中保持ACID中A(原子性)

​ 在两阶段提交协议中，包含了两种角色：参与者就是实际处理事务的机器，协调者就是其中一台单独的处理分布式事务的机器。

​ 两个阶段：

​ 投票阶段：在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程
在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
​ 提交阶段：协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务

【Raft协议中使用选举来产生leader,协调者】

例子：PPT2 38页

优点：实现简单

缺点：

**同步阻塞问题：**执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
**单点故障：**由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）【可以重选举，但依然有阻塞开销】

**数据不一致：**commit请求提交时，部分节点挂掉会导致数据不一致。【日志可以解决】

**二阶段无法解决的问题：**协调者commit发出后宕机，接收者也宕机，则事务出现不确定。

分布式多系统实例—京东购物PPT2 44

5.数据复制

复制是将数据同步在多个服务器的过程

复制至少需要两个节点，一个是主节点，负责处理客户端请求，其余的都是从节点，负责复制主节点上的数据

常见有一主一从，一主多从

主节点记录在其上的所有操作oplog，从节点定期轮询主节点获取这些操作，然后对自己的数据副本执行这些操作，从而保证从节点的数据与主节点一致

优点：

安全性，高可用，灾难恢复，无需停机维护，分布式读取数据

6.文档数据库（以MongoDB为例）

文档是数据库中的主要概念

可存放并获取文档，其格式可以是**XML、JSON、**BSON等
数据库中的文档彼此相似，但结构不必完全相同，不像关系型数据库那样，表格中每行数据的模式都要相同【模式相似但可以不同】
向文档中新增属性时，既无需预先定义，也不用修改已有文档内容

文档数据库特性：

文档数据库介绍_miaoyibosysu的博客-CSDN博客_文档数据库

场景

1）应用在应用服务器的日志记录。
2）主要用来存储一些监控数据，No schema 对开发人员来说，真的很方便，增加字段不用改表结构，而且学习成本极低。
3）使用MongoDB做了O2O快递应用，·将送快递骑手、快递商家的信息（包含位置信息）存储在 MongoDB，然后通过 MongoDB 的地理位置查询，这样很方便的实现了查找附近的商家、骑手等功能，使得快递骑手能就近接单。

ALL：大型电商（如商品介绍页），博客网站(比如Twitter)，内容管理系统(WordPress和Windows注册表)，分析平台【主要出于海量，结构不完全相同的数据】

优点：

1.所有内容都在一个数据库当中，而不是信息分散在多个链接数据库中。因此，与SQL数据库相比可以获得更好的性能，只要不使用关系型流程。

2.不像每个信息都有一个字段的传统数据库，即使没有任何内容，文档存储数据库也更加灵活。实际上，不需要文档有一致性，您就可以存储大量数据，基本上没有问题。如果要保证多文档间的一致性，不建议用文档数据库。

3.同样，由于文档存储更灵活，因此集成新数据根本不是问题。与必须将任何新类型的信息添加到所有数据集的关系数据库相比，文档存储数据库只需要添加到几个数据集即可。【指字段】

4.可以在不造成任何停机的情况下修改模式，或者由于您将来可能不知道用户需求

5.文档存储还有助于数据分析，因为公司可以轻松存储众多信息供日后使用。

缺点：

不支持多文档事务，业务中存在大量复杂的事务逻辑操作不要用【但MongoDB也开始支持了】
【？】查询持续变化的聚合结构，虽然文档数据库对模式不施加任何限制，但是如果要即时查询这些持续可变的实体，那么所用的查询命令也要不断变化，所以就需要以最低级别的粒度来保存聚合，这实际上就等于要统一数据格式。

【或许是指变化太剧烈？感觉是说不通的，变化了命令肯定就要改，或许是查询不变的部分？】

MongoDB：

文档型，分布式【高并发】，CP型

类JSON格式，文档内数据结构是kv，value既可以是简单的数据类型，如字符串、数字和日期等
也可以是复杂的类型，如有序列表和关联对象

最小单位是文档，同一个集合中存储的文档属性可以是不同的，每个文档都是自包含的数据单元，是一系列数据项的集合

场景：

网站数据：Mongo 非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性
缓存：由于性能很高，Mongo 也适合作为信息基础设施的缓存层，在系统重启之后，由Mongo 搭建的持久化缓存层可以避免下层的数据源过载
满足海量存储需求和访问||大尺寸、低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵【有开销浪费，而且Mongo有WiredTiger 存储引擎，高性能，高压缩】，在此之前，很多时候程序员往往会选择传统的文件进行存储

高伸缩性的场景【如上面的网站数据】
Mongo 非常适合由数十或数百台服务器组成的数据库，Mongo 的路线图中已经包含对MapReduce 引擎的内置支持
用于对象及JSON 数据的存储
Mongo 的BSON 数据格式非常适合文档化格式的存储及查询

不适合场景：

高度事务（如银行），传统的商业智能应用（数据仓库），一定要SQL的复杂查询

优点：PPT3 21 22

More: MongoDB存储引擎wiredtiger默认高压缩、高性能。省磁盘，能在大数据量下比MySQL多存很多。

缺点：PPT3 23

数据模型：

特殊集合——固定集合

​ 很像环形队列，如果空间不足，最早的文档就会被删除，为新的文档腾出空间，适用于任何想要自动淘汰过期属性的场景，比如日志文件，聊天记录，通话信息记录等只需保留最近某段时间内的应用场景

嵌入式文档 PPT116

引用式文档PPT117

​ 这东西的性能不太好，涉及到了一点多文档事务

RDB转换MongoDB

数据类型：

只记特别的，详细见PPT3 29

Object—内嵌文档 Object ID—文档ID

Binary Data—二进制数据

Code—js代码

Regular Expression—正则表达式

分片

​ 分片是指将数据拆分,将其分散存在不同机器上的过程.有时也叫分区.将数据分散在不同的机器上,不需要功能强大的大型计算机就可以存储更多的数据,处理更大的负载.
使用几乎所有数据库软件都能进行手动分片,应用需要维护与若干不同数据库服务器的连接,每个连接还是完全独立的.应用程序管理不同服务器上的不同数据,存储查村都需要在正确的服务器上进行.这种方法可以很好的工作,但是也 难以维护,比如向集群添加节点或从集群删除节点都很困难,调整数据分布和负载模式也不轻松.

​ MongoDB支持自动分片,可以摆脱手动分片的管理.集群自动切分数据,做负载均衡.

​ MongoDB中分片是拆大集合。

MongoDB 分片 | 菜鸟教程 (runoob.com)

MongoDB分片详解 - 一个大西瓜咚咚咚 - 博客园 (cnblogs.com)

实例：

可以看到都是混合数据源，各取所长很重要。

用电信息采集案例PPT3 179 缓存策略【安全，加快Mongo写入】，Mongo高并发读写，负载均衡

人社大数据平台PPT3 188 Oracle+HBase+Mongo【+并行计算+数据同步平台】

​ 注意其中档案袋结构，需求拓展，很好用Mongo，辅助智能助理，主要用于查询等具体操作。

文档及评论PPT3 194 点赞表，评论表等都不用了——>一个集合搞定

​ 查询流程PPT3 196 不用多表联查，不需要同时执行大量SQL

CouchDB：

文档型，分布式【高并发】，AP型

「文档数据库之争」MongoDB和CouchDB的比较 - 腾讯云开发者社区-腾讯云 (tencent.com)

数据模型：

​ 不需要范式，直接存储JSON就可以，CouchDB默认会生成 _id，_rev 两个键

​ 数据库直接包含文档，没有集合概念

个人理解/总结

​ 文档类数据库适合像聊天记录一样，掐头去尾一些必要用户信息外，中间有大量重复性结构的存储，相比SQL去掉了多表联查，数据也放在一起，开销更小，开发也更方便。

​ 也适合相似但不完全一样的海量数据存储，他在大数据下查询比SQL快得多

​ 但复杂事务就不要用了 ，因为不支持事务（只支持文档级别事务），手动保证一致性性价比太低了。

7.列族数据库（以Hbase为例）

和行式比较

大量降低I/O:【有利于海量查询】只读指定列，可以少很多数据

高压缩—省硬盘

应用上

行式：更有利于传统的OLTP业务，即增删改查

列式：更有利于OLAP业务，列式数据库在并行查询处理和压缩上更有优势。而且数据是以列为单元存储，完全不用考虑数据建模或者说建模更简单了。要查询计算哪些列上的数据，直接读取列就行。非常适合于在数据仓库领域发挥作用，比如数据分析、海量存储和商业智能;涉及不经常更新的数据【改就要用Rowkey去重组数据，这个性能并不算好】。

HBase：

列族型，分布式【高并发】，CP型

文件存储系统HDFS，数据处理方式MapReduce， 协同服务Zookeeper

HBase仅能通过主键(row key)和主键的range来检索数据，仅支持单行事务(可通过Hive支持来实现多表连接等复杂操作)

主要用来存储非结构化和半结构化的松散数据【列可以灵活增加】

Hbase表特点：大，面向列，稀疏【可以为null不占空间】

Hbase结构：

Hadoop实现的是一个分布式文件系统

Hadoop生态系统中的各层系统
HBase位于结构化存储层
HDFS为HBase提供了高可靠性的底层存储支持
MapReduce为HBase提供了高性能的计算能力
Zookeeper为HBase提供了稳定服务和失败恢复机制

成功场景案例PPT4 16

主要是极大的表，大读写，少或无修改，要分析

Hbase和传统关系数据库对比

	HBase	传统关系数据库
数据类型	只有简单的字符串类型，所有类型都由用户自己处理，只保存字符串	关系数据库有丰富的类型选择和存储方式
数据操作	只有很简单的插入、查询、删除、清空等，表和表之间是分离的，没有复杂的表和表之间的关系，所以也不能也没有必要实现表和表之间的关联等操作	有各种各样的函数、连接操作
存储模式	基于列存储的，每个列族都有几个文件保存，不同列族的文件是分离的	基于表格结构和行模式保存的
数据维护	HBase的更新正确来说应该不叫更新，而且一个主键或者列对应的新的版本，而它旧有的版本仍然会保留，所以它实际上是插入了新的数据【基于插入时间戳】	替换修改
可伸缩性	能够轻易的增加或者减少（在硬件错误的时候）硬件数量，而且对错误的兼容性比较高	需要增加中间层才能实现类似的功能，而且效果往往不够理想

数据模型：

（最后一行是t3）

列名字的格式是“ < family >:< label >”：如上图anchor所示，如果列族中有多个列，会和上面一样存储，头一格< 列族名 >：< 列名 >，第二格才是具体内容

**列族（Column Family）：表在水平方向有一个或者多个列族组成，一个列族中可以由任意多个列组成，即列族支持动态扩展，**无需预先定义列的数量以及类型，所有列均以二进制格式存储，用户需要自行进行类型转换

【表由列族组成，列族下可能由多个列，定义时先列族名，列名可有可无，多列才需要列名】

行键（Row Key）：HBase表的主键，表中的记录按照行键排序。行键用来检索记录的主键

【根据RowKey查询时，如果不指定timeStamp，会返回每个列的最新值，实际上更新也是插入新值来完成的】

时间戳（Timestamp）：每次数据操作对应的时间戳，可看作是数据的版本号，不同版本通过时间戳来进行索引

NULL值实际上不会被存储，物理视图见PPT4 25

查询限制：PPT4 56 57

由于只能用RowKey和时间戳去查，rowkey的设计是至关重要的，设计不好会让功能做不出来，容易造成数据热点等

不同表通常需要不同的rowkey策略

RowKey设计

• 在Hbase中，使用单调增加的rowkey值是不推荐的

  因为rowkey字典序，这种设计优化了scan操作，可以将相关的行以及会被一起读取的行存取在临近位置，便于scan

  但正因为这样，单调递增的rowkey会导致

• Reverse反转：因为RowKey尾部随机性不错，这样的话可以把数据分布在各个节点上。这样是优化Get，牺牲Scan，因为相关数据被分散了；反转手段是多样的，可以把尾部数据拿到前面来，也可以使用减法等

  时间戳反转：需要查询最近一段时间的场景还是很多的，但时间戳前半段基本一样，很容易造成数据热点，反转则会好不少

  实际生产中可以用 Long.Max_Value - timestamp 追加到 key 的末尾，比如 [key] [reverse_timestamp]

  【PS.这感觉像是出于原则才这么做，减这一下可能还是会造成数据热点，递增变递减而已，关键处应该是前置key】

• Salt加盐：Salt是将每一个Rowkey加一个前缀，前缀使用一些随机字符，使得数据分散在多个不同的Region，达到Region负载均衡的目标，把数据分布在不同region中，增加写吞吐量，牺牲读性能

• **散列：改进加盐。**使用确定性Hash加盐，前缀可以被算出来，从而直接拿到Rowkey来get，提高读性能，同时也让负载分散到整个集群。

• 尽量减少行键和列族的大小：当具体的值在系统间传输时，它的rowkey，列名，时间戳也会一起传输，如果rowkey和列名很大，将会占用大量的存储空间；冗长的属性名虽然可读性好，但是更短的属性名存储在HBase中会更好

Cassandra：PPT4 101-105

列族型，分布式【高并发】，AP型

在混合模式可以将超级列添加到5维

和Hbase比较

	Cassandra	Hbase
架构	无主控架构，去中心化	主控( master based)架构，HDFS
可用性	无主控，不停机	主控下线，会导致一段时间不可用；跟随机器下线后也需要时间恢复
一致性	弱一致性	强一致性
写性能	较高	同时写入日志和缓存【保证一致性】，写较慢
读性能【一致】	由于要比较不同服务器版本，较低	一台服务器即可【强一致性】，读较快
应用区别	看链接第五部分	看链接第五部分
数据模型	看下面部分	看下面部分

[Cassandra与HBase：双胞胎还是外表相似的陌生人？ - 知乎 (zhihu.com)](https://zhuanlan.zhihu.com/p/341426602#:~:text=Cassandra vs. HBase –回顾. Cassandra是一种用于数据存储和管理的“自给自足”技术，而HBase则不是。.,后者旨在用作HDFS随机数据输入%2F输出的工具，这就是为什么将其所有数据存储在此处的原因。. 此外，HBase使用Zookeeper作为服务器状态管理器，并使用“大师”来知道所有元数据在哪里（以避免在包含元数据的主服务器出现故障时立即出现群集故障）。. 因此，HBase复杂的相互依存系统更加难以配置，保护和维护。. Cassandra擅长写入，而HBase擅长密集读取。. Cassandra的弱点是数据一致性，而HBase的痛苦是数据可用性，尽管两者都试图减轻这些问题的不利后果。.)

数据模型：

逻辑上是KeySpace-ColumnFamily-Key-Columns【数据模型含义和HBase是不一样的，考到看上面链接】

有超级列

Cassandra 数据模型_w3cschool

MapReduce：PPT4 107-146

MapReduce是一种编程模型，用于大规模数据集（大于1TB）的并行运算。

当前的软件实现是指定一个Map（映射）函数，用来把一组键值对映射成一组新的键值对，指定并发的Reduce（归约）函数，用来保证所有映射的键值对中的每一个共享相同的键组。

HBase二级索引：PPT4 147

8.键值对数据库（以Redis为例）

键值数据库将数据存储为键值对集合，其中键作为唯一标识符

键和值都可以是从简单对象到复杂复合对象的任何内容

键值数据库是高度可分区的，并且允许以其他类型的数据库无法实现的规模进行水平扩展【可水平拓展程度很高】

优缺点，适用情景

KV数据库只能通过键值查询，意味着value是不可查的

没有事务，不能关联两个或两个以上的键来关联数据

某些KV数据库中，故障不能回滚

**适用于：**频繁读写，数据模型简单，内容缓存

Redis：

KV型，分布式【高并发】，CP型，内存式

支持的数据类型包括string、list、set、zset(有序集合)和hash

支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且操作都是原子性的，支持各种不同方式的排序

【操作丰富且原子】

有主控，Redis支持主从同步

数据模型

Key为String类型

value类型丰富，支持string,list,hash,set,zset

只能通过Key对value查询

【KV结构是简单的，灵活的同时也把更多设计任务交给了用户，怎么把数据存入由用户自己负责】

注：

• Redis的String可以是字符串，整数，浮点数，但都存储为String

• 所有容器包含的都是String

• set实际上是用散列表来存Key，散列表保证Key不重复，只有Key！！！没有Key对应的Value

• hash存的是键值对

• zset存的也是键值对，但有序集合的键被称为成员（member），值则被称为分值（score），分值必须为浮点数

  zset是Redis里面唯一一个既可以根据成员访问元素（这一点和散列一样），又可以根据分值以及分值的排列顺序来访问元素的结构

  【键值对，同时支持有序访问】

• 需要存的是KV时，请考虑hash或zset，存一系列值时，请考虑set和list，只有一个值时，使用string

分区：PPT5 41-43

Redis总的来说还是得分区来达成分布式的，好坏见PPT

数据恢复

其实这个部分应该是很重要的，redis作为内存式数据库，这是他快的根源，一旦断电没备份是灾难式的，不知道为啥没讲

下文分别介绍了RDB、AOF、混合持久化，主要思路都是备份文件，但中间会有各种取舍

[【Redis技术探索】「底层架构原理」探索分析服务数据同步持久化机制_洛神灬殇的博客-CSDN博客](https://blog.csdn.net/l569590478/article/details/128332826#:~:text=通常情况下redis的数据全部存储在内存中，数据库一旦故障发生重启数据会全部丢失 ，,持久化功能在于能够有效地避免因进程退出造成的数据丢失问题 ， 在下次重启时利用之前持久化的文件即可实现数据恢复。)

文章投票实例：PPT 50-62

它是不需要事务的，存文章信息的格式为 article: 文章ID ——hash，hash里存各种键值对信息【这意味着文章间信息联系弱，因为没有跨文章的事务】

文章间的联系通过另外两个key来解决

time和score——zset

在zset中，以文章ID为key，time和score的值为value

同时需要已投票用户集合，可以用used——hash，文章ID为key，value是一个由用户ID组成的set【也可以看PPT中一样】

Redis是内存式的，需要节约内存

可行的方案比如，限定投票时间，过期就淘汰掉相关的已投票用户表，或者评选到期后，可以把分数不够的分数和时间集合都不要了，具体看内存情况

ZINTERSTORE命令表明，Redis还是支持在set、zset、hash中key上的相关运算的，如果只是Key间有联系，Redis还是可以进行筛选部分值。

DynamoDB：

KV型，分布式【高并发】，AP型，完全托管（来自亚马逊）

DynamoDB与Redis的异同_Tor1surphY的博客-CSDN博客_dynamodb和redis

数据模型：PPT5 68 69

Redis是单纯的key-value键值对存储。
**DynamoDB虽然也是以key-value形式存储数据的，但是也引入了传统关系型数据库(RDBMS)中的表的概念有了表就有主键的概念，**DynamoDB中的分区键和排序键以及二级索引可以应对很多不同场景下的需求。
所以DynamoDB更像是处于NoSQL和RDBMS之间的一种数据库。

Redis由于其性能更多的被用于做缓存。
DynamoDB则更接近于RDBMS的应用场景，比如数据存储，增删查改等。
不难理解的是，在一款大型线上游戏的服务端，应该是客户端 — 服务端 — 缓存(Redis) — DynamoDB这样的层级结构。

9.图数据库（以Neo4j为例）

why图数据库？

关系数据库的不足

随着离散数据的增加，数据集的宏观结构会越发复杂和不规整，关系模型将造成大量表连接、稀疏行和非空检查逻辑，
关系世界中连通性的增强将转换为连接操作的增加，会阻碍性能，使得数据库难以响应变化的业务需求

面对一项联系，可能需要不断用SQL执行连接表，递归查询代价比较高

其他NoSQL的不足

Key-value、文档和列存储数据库存储的都是无关联的值/文档/列，很难用于关联数据
对于上述数据库而言，一种添加联系的策略是在某个聚合数据(Aggregate)中嵌入另一个聚合数据标识符，即添加外键，这将导致代价剧增【如引用文档，这样做的代价是比较大的】，即使构建了联系，那反向查询也会成为问题

图数据库优势

拥抱联系，在查找各类拓展关系时，速度优势巨大

Neo4j：

图型，分布式【高并发】，CP型

• Neo4j 中两个最基本的概念是节点和边

  节点表示实体，边则表示实体之间的关系

  节点和边都可以有自己的属性

• Neo4j 提供了在对象图上进行查找和遍历的功能：深度搜索，广度搜索【遍历可以限制深度】

完整的ACID，支持事务

高可用，高伸缩

数据模型：

Neo4j数据记录在节点和联系中

• 节点和联系都拥有属性（Properties）

• 节点通过联系关联起来

• 联系一定是有方向的，可以单向可以双向

• 节点经常被用于表示实体，可以有多个属性；最简单的节点也要有一个属性

• 每个关系包含“开始节点”或“从节点”和“到节点”或“结束节点”

  【因此通过关系可以找到很多关联的数据，比如节点集合，关系集合以及他们的属性集合】

• 属性（Properties）是键值对

  键名是字符串
  属性值是要么是原始值，要么是原始值类型的一个数组，原始值就是常见的bool，char等等PPT6 29

• 联系有类型（Type），节点有标签（label），用于区分某一类

路径/遍历

路径由至少一个节点，通过各种关系连接组成，经常是作为一个查询或者遍历的结果

• 遍历的路径：通常用关系的类型和方向来表示
• 遍历的顺序：常见的遍历顺序有深度优先和广度优先两种【可以指定深度】
• 遍历的唯一性：可以指定在整个遍历中是否允许经过重复的节点、关系或路径
• 遍历过程的决策器：用来在遍历过程中判断是否继续进行遍历，以及选择遍历过程的返回结果
• 起始节点：遍历过程的起点
  

  

索引

数据转换

• RDB to Neo4j:同张表的给相同的label或type，这要看实体集还是联系集，如果没有联系集的话可以根据平常使用情况进行构造，

  其他就没啥了，其他按照属性填入就可以了

• Key-value DB to Neo4j：KV数据库的联系就更弱了，**首先考虑KV间的联系，再具体考虑value和key，value和value间的关系，**但好的设计不应该让这种情况出现，这个转换本身就比较诡异

• Document DB to Neo4j：和传统数据库相比下多了个数据库实例，【在传统数据库下是模式，其实不太用得到】，每一级呈现包含关系，最后考虑引用文档/集合的联系

  【但感觉和关系型一样转换也是可以的】

案例PPT6 46 社交网络

10.回到PPT1

数据库汇总

MongoDB【满足海量存储需求和访问】【文档型】

HBase（Hadoop）【列簇】列和RDBS转换用sqoop【关系型和HDFS转换】

Redis【kv+内存式】【高读写】

Neo4j【图】

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

很重要的，Mongo可以直接存文件，有二进制数据这个类型【图片等】

HBase也可以，但对每个值的大小是有实际限制的【不是文件很难撑爆这个限制】

Neo4j不能存文件

Redis也不能，也不好，一个内存式的不应该存

案例汇总

新浪—Redis+MySQL

从微博来看的话，新浪用的MySQL好像不是完美的选择，用Mongo或许不错；

使用MySQL应该是构建年代比较早，而且有一定的事务需求，使用Redis是为了缓冲，应对高并发场景

视觉中国—MongoDB

文章类，Mongo很擅长

优酷—在线评论MongoDB 运营数据分析Hadoop/Hase

挺好的，显然的选择

京东—Redis

这里说Redis应该还是在大并发上，比如说秒杀级别业务，这类业务是典型的读多写少的应用场景，下单和支付才是写请求。所以这个时候，缓存潇洒的出场。

写操作肯定还是有高度的事务属性，最后下单和支付肯定是要用传统关系型的

但前期浏览显然不用，都是读，这时候放在Redis就很好了

携程—HBase，Redis

HBase显然的数据分析需求，Redis用于缓冲？旅游网站有点意义不明，不过商业环境下一般都有

总结

如果感觉事务性比较强，特别是多表事务，不能接受先重做一个再做另一个中间的时间窗口的，用传统ACID

感觉分析型，用列族

感觉联系很多的，图数据库很好，比如朋友圈，本人—朋友ID—根据朋友ID逐一找出文章ID的列表—找到文章—排序，，即完成一项功能需要根据查询结果再查的，可以用图，但他不能存文件，这个就比较尴尬了，要存图片什么的就不要用这个了

redis啥时候用？多半是个RDB做缓冲，纯的redis几乎没有持久化手段，不太好

Mongo？我更愿意这么理解，在业务不确定，且没啥对强一致性要求的，可以用Mongo，好处在于随便存，可以存文件！

最后，某种数据库嗯用也不是不行，但效果可能不太好就是了，也不一定，比如大数据量存储，列族和Mongo感觉都不错

案例汇总

新浪—Redis+MySQL

从微博来看的话，新浪用的MySQL好像不是完美的选择，用Mongo或许不错；

使用MySQL应该是构建年代比较早，而且有一定的事务需求，使用Redis是为了缓冲，应对高并发场景

视觉中国—MongoDB

文章类，Mongo很擅长

优酷—在线评论MongoDB 运营数据分析Hadoop/Hase

挺好的，显然的选择

京东—Redis

这里说Redis应该还是在大并发上，比如说秒杀级别业务，这类业务是典型的读多写少的应用场景，下单和支付才是写请求。所以这个时候，缓存潇洒的出场。

写操作肯定还是有高度的事务属性，最后下单和支付肯定是要用传统关系型的

但前期浏览显然不用，都是读，这时候放在Redis就很好了

携程—HBase，Redis

HBase显然的数据分析需求，Redis用于缓冲？旅游网站有点意义不明，不过商业环境下一般都有

总结

如果感觉事务性比较强，特别是多表事务，不能接受先重做一个再做另一个中间的时间窗口的，用传统ACID

感觉分析型，用列族

感觉联系很多的，图数据库很好，比如朋友圈，本人—朋友ID—根据朋友ID逐一找出文章ID的列表—找到文章—排序，，即完成一项功能需要根据查询结果再查的，可以用图，但他不能存文件，这个就比较尴尬了，要存图片什么的就不要用这个了

redis啥时候用？多半是个RDB做缓冲，纯的redis几乎没有持久化手段，不太好

Mongo？我更愿意这么理解，在业务不确定，且没啥对强一致性要求的，可以用Mongo，好处在于随便存，可以存文件！

最后，某种数据库嗯用也不是不行，但效果可能不太好就是了，也不一定，比如大数据量存储，列族和Mongo感觉都不错

原文地址：https://blog.csdn.net/loser_creeper/article/details/129131981