数据持久层

清疚 2024-03-31 18:03 38阅读 0赞

![ab7070aa2dcd46a98adba650ed7d51b7.png][]

**目录**

数据冷热分离的概念：

热数据

冷数据

冷热分离

什么情况下使用冷热分离：

Hbase：

什么是非关系型数据库，什么是关系型数据库：

nosql和关系型数据库比较？

优点：

缺点：

非关系型数据库的优势：

关系型数据库的优势：

es是干什么的：

什么是全文检索：

ES引入会有什么样的问题：

总结

优点：

缺点：

哪些场景下建议使用es：

redis是干什么的：

解决了哪些问题：

优点：

使用redis会带来哪些问题：

缺点：

哪些场景下建议使用redis：

分库分表的基本理念：

1、首先理解概念，什么时分库分表？

2、其次，为什么要分库分表？

解决了哪些问题：

会带来哪些问题：

1）跨节点连接查询问题

2）多数据源管理问题

哪些场景下会使用分库分表：

1.数据量过大，影响了运维操作

直接执行大表 DDL，为什么会导致主从延迟？

2. 把修改频繁的字段拆分出来

3. 把大字段拆分出去

4.增长比较快的

5 .降低不同库或者表的相互影响

缓存是干什么的：

本地缓存和服务器缓存的区别的是什么：

使用缓存会带来哪些问题：

缓存雪崩：

缓存雪崩的解决方法有以下几种

缓存击穿：

缓存击穿的解决方法有以下几种

缓存穿透：

缓存穿透的解决方法有以下几种

缓存预热：

缓存预热的实现方法有以下三种

kafka是干什么的：

Kafka的特性：

Kafka场景应用：

优点：

缺点：

--------------------

1.数据冷热分离的概念，解决了什么问题，简单了解一下Hbase，什么是非关系型数据库，什么是关系型数据库。

### 数据冷热分离的概念： ###

#### 热数据 ####

热数据指的是需要即时对用户进行分发的数据，即从数据源抓取之后经过数据处理，需要即时存储到可快速分发的存储介质供API或直接面向用户的系统使用。

热数据需要重点保障服务质量和稳定性，为了保证数据的时效性，在数据处理上也是优先级高的数据。

#### 冷数据 ####

冷数据指的是不需要即时发给用户的数据。

这些数不会原样分发给用户，它们需要经过长期的积累，使我们可以从中得到基于此更高层次的分析。

#### 冷热分离 ####

冷热分离指的是在处理数据时将数据库分为冷库和热库，冷库指用于存放走到了终态的数据（冷数据）的数据库，热库用于存放还需要修改的数据（热数据）的数据库。

#### 什么情况下使用冷热分离： ####

从冷热分离的定义我们可以知道当业务需求涉及到冷热数据，表数据量增长速度快或数据量较大时， 我们就该考虑是否使用冷热分离解决方案了。比如：

> 1）数据走到终态后，只有读没有写的需求。
> 
> 2）用户能够接受新旧数据分开实现业务，比如查询新旧数据的时候分开操作。

--------------------

### Hbase： ###

HBase是一种分布式、可扩展、支持海量数据存储的NoSQL数据库，是Apache的Hadoop项目的子项目，是一个适合于非结构化数据存储的数据库。

#### 什么是非关系型数据库，什么是关系型数据库： ####

1.  关系数据库：是建立在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据。

简单说来就是关系型数据库用了选择、投影、连接、并、交、差、除、增删查改等数学方法来实现对数据的存储和查询。可以用SQL语句方便的在一个表及其多个表之间做非常复杂的数据查询。安全性高。

2. 非关系型数据库：简称NOSQL，是基于键值对的对应关系，并且不需要经过SQL层的解析，所以性能非常高。但是不适合用在多表联合查询和一些较复杂的查询中。NoSQL用于超大规模数据的存储。

--------------------

### nosql和关系型数据库比较？ ###

#### 优点： ####

> 1）成本：nosql数据库简单易部署，基本都是开源软件，不需要像使用oracle那样花费大量成本购买使用，相比关系型数据库价格便宜。
> 
> 2）查询速度：nosql数据库将数据存储于缓存之中，关系型数据库将数据存储在硬盘中，自然查询速度远不及nosql数据库。
> 
> 3）存储数据的格式：nosql的存储格式是key,value形式、文档形式、图片形式等等，所以可以存储基础类型以及对象或者是集合等各种格式，而数据库则只支持基础类型（varchar等）。
> 
> 4）扩展性：关系型数据库有类似join这样的多表查询机制的限制导致扩展很艰难。

#### 缺点： ####

> 1）维护的工具和资料有限，因为nosql是属于新的技术，不能和关系型数据库10几年的技术同日而语。
> 
> 2）不提供对sql的支持，如果不支持sql这样的工业标准，将产生一定用户的学习和使用成本。
> 
> 3）不提供关系型数据库对事务的处理。

####  **非关系型数据库的优势：** ####

> 1. 性能NOSQL是基于键值对的，可以想象成表中的主键和值的对应关系，而且不需要经过SQL层的解析，所以性能非常高。
> 
> 2. 可扩展性同样也是因为基于键值对，数据之间没有耦合性，所以非常容易水平扩展。

#### 关系型数据库的优势： ####

> 1. 复杂查询可以用SQL语句方便的在一个表以及多个表之间做非常复杂的数据查询。
> 
> 2. 事务支持使得对于安全性能很高的数据访问要求得以实现。

--------------------

2,es是干什么的，解决了哪些问题，使用es会带来哪些问题，哪些场景下建议使用es。

### es是干什么的： ###

elasticsearch简写es，es是一个高扩展、开源的全文检索和分析引擎，它可以准实时地快速存储、搜索、分析海量的数据。

#### 什么是全文检索： ####

全文检索是指计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。全文搜索搜索引擎数据库中的数据。

#### ES引入会有什么样的问题： ####

> 1.字段类型无法修改、写入性能较低和高硬件资源消耗
> 
> 2.ES需要在创建字段前要预先建立Mapping，Mapping中包含每个字段的类型信息，ES需要根据Mapping为字段建立合适的索引。由于这个Mapping的存在，ES中的字段一但建立就不能再修改类型了。ES在数据结构灵活度上高于MySQL但远不如MongoDB
> 
> 3.不支持事务,JOIN
> 
> 4.吃硬件
> 
> ES的排序和聚合（Aggregation）操作会把几乎所有相关不相关的文档都加载到内存中，一个Query就可以很神奇地吃光所有内存，现在新的Lucene版本优化了基于硬盘的排序，但也仅当你使用SSD的情况下，才不会牺牲过多的搜索性能。其他的问题还包括，大量的增量写操作会导致大量的后台Merge，CPU和硬盘读写都会很容易达到瓶颈。ES确实在横向Scale方面做的很出色，但前提是有足够的预算买硬件。
> 
> 5.数据实时性
> 
> 每当有新增的数据时，就将其先写入到内存中，在内存和磁盘之间是文件系统缓存，当达到默认的时间（1秒钟）或者内存的数据达到一定量时，会触发一次刷新（Refresh），将内存中的数据生成到一个新的段上并缓存到文件缓存系统 上，稍后再被刷新到磁盘中并生成提交点。因此，从Index请求到对外可见能够被搜到，最少要1秒钟的数据延时。
> 
> 6.不支持数据的权限管理

#### 总结 ####

> ES香不香看你怎么用。有人用的很爽，有人用的很痛苦。用好了就少加班调索引，调sql。用不好就常加班调ES。

#### 优点： ####

>  *  1.高并发
>  *  2.容错能力比mg强。比如1主多从，主片挂了从片会自动顶上
>  *  3.满足大数据下实时读写需求，无需分库（不存在库的概念）。
>  *  4.易扩展。分片数据自动均衡
>  *  5.支持较复杂的条件查询，group by、排序都不是问题

#### 缺点： ####

>  *  1.不支持事务
>  *  2.读写有一定延时
>  *  3.无权限管理
>  *  4.吃硬件

#### 哪些场景下建议使用es： ####

一个线上商城系统，用户需要搜索商城上的商品。

在这里你可以用es存储所有的商品信息和库存信息，用户只需要输入”空调”就可以搜索到他需要搜索到的商品。

一个运行的系统需要收集日志，用这些日志来分析、挖掘从而获取系统业务未来的趋势。

你可以用logstash（elk中的一个产品，elasticsearch/logstash/kibana）收集、转换你的日志，并将他们存储到es中。一旦数据到达es中，就你可以在里面搜索、运行聚合函数等操作来挖掘任何你感兴趣的信息。

如果你有想基于大量数据（数百万甚至数十亿的数据）快速调查、分析并且要将分析结果可视化的需求。

你可以用es来存储你的数据，用kibana构建自定义的可视化图形、报表，为业务决策提供科学的数据依据。

直白点讲，es是一个企业级海量数据的搜索引擎，可以理解为是一个企业级的百度搜索，除了搜索之外，es还可以快速的实现聚合运算。

--------------------

3，redis是干什么的，解决了哪些问题，使用redis会带来哪些问题，哪些场景下建议使用redis。

### redis是干什么的： ###

Redis是一个高速缓存数据库，是一种key-value（键值对）形式的存储系统，非关系型数据库。

#### 解决了哪些问题： ####

#### 优点： ####

> 1.读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。
> 
> 2支持数据持久化，支持AOF和RDB两种持久化方式。
> 
> 3.支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。
> 
> 4.数据结构丰富
> 
> 5.支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

#### 使用redis会带来哪些问题： ####

#### 缺点： ####

> 1.数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
> 
> 2.Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
> 
> 3.主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
> 
> 4.Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费

#### 哪些场景下建议使用redis： ####

[https://blog.csdn.net/L170311/article/details/129029966?spm=1001.2014.3001.5502][https_blog.csdn.net_L170311_article_details_129029966_spm_1001.2014.3001.5502]

--------------------

4，分库分表的基本理念，解决了哪些问题，会带来哪些问题，哪些场景下会使用分库分表。

### 分库分表的基本理念： ###

#### 1、首先理解概念，什么时分库分表？ ####

**分表：将单表拆分成多张表，数据分散到不同表中。**

**分库：将单库拆分成多个库，数据分散到不同库中。**

#### 2、其次，为什么要分库分表？ ####

> 分库分表的主要目的是提升数据查询的效率、减轻数据库的压力等。
> 
> 可以通过缓存、读写分离、索引等方式提升数据查询效率，通过增加硬件资源，比如内存、CPU等减轻数据库的压力。但是日益剧增的数据，使以上的方式都不足以奏效时，分库分表便是一种解决方案，虽然该方案在使用的过程中会遇到不少难题，但好在有开源技术能够帮我们解决大部分难题。

#### 解决了哪些问题： ####

> 1）在数据库设计阶段的时候应该需要考虑垂直分库和垂直分表。
> 
> 2）因为数据量不太容易预估，不清楚数据是否会剧增。因此，不要马上考虑做水平切分，在有一定的数据量时应该优先考虑通过缓存、读写分离、索引等等方式尝试解决，如果以上方式不能够解决查询速度，再考虑去做水平分库和水平分表。

#### 会带来哪些问题： ####

#### 1）跨节点连接查询问题 ####

比如：

>  *  垂直分库中，两张需要关联的表分别在不同数据库中，无法通过join的方式连接。
>  *  水平分库中，一张表的数据存在于多个数据库中，此时分页查询存在问题，以及对数据进行排序或其他筛选存在很大难度。

#### 2）多数据源管理问题 ####

#### 哪些场景下会使用分库分表： ####

都在提分库分表，那么哪些情况应该考虑分库分表呢？这里总结了几个需要考虑分库分表的场景：

#### 1.数据量过大，影响了运维操作 ####

如果数据量比较大，其对数据库影响也会比较大，最常见的比如：影响备份、大表 DDL 导致主从长时间延迟等。下面仔细讲讲这两种情况：

备份：如果单张表或者单个实例数据量太大，那备份可能需要占用大量的 IO 和磁盘空间，并且持续时间还会比较久。曾经听说过有公司的单个实例的备份从凌晨持续到当天下午的情况，这种场景下，尽管在从库备份，如果开启了读写分离，对业务的影响也是比较大的。

DDL 导致主从长时间延迟：大表执行 DDL 不但会产生 MDL 写锁（MDL 的风险可以复习第 15 节），并且还会导致主从延迟。

#### 直接执行大表 DDL，为什么会导致主从延迟？ ####

原因是主库执行完 DDL 后，才会写入到 binlog 里，然后传输到从库执行，而又因为从库 SQL 线程是单线程的，因此，需要等到这条 DDL 在从库执行完成，其他事务才能继续执行，而从库执行 DDL 这段时间，主从都是延迟的。

#### 2. 把修改频繁的字段拆分出来 ####

比如电商业务场景的用户表，这张表可能包含了用户唯一标识 ID，用户名，昵称，联系方式，性别，出生日期，注册时间，积分等等。这些字段中，其实也只有积分会变更的比较频繁，因此可以把积分字段独立出来，然后加上用户唯一标识 ID。这样，用户表的更新次数就大大降低了。

#### 3. 把大字段拆分出去 ####

比如电商业务的商品表，表里可能包含了商品的价格，生产日期，产地，供应商，商品详情和使用说明等。我们会发现商品详情和使用说明的字段特别大，可能字段类型需要配置成 text 或 blob，类似的字段占用的磁盘空间也是比较大。维护起来会比较麻烦，因此这种情况下，建议把这类大字段水平拆分出来。

#### 4.增长比较快的 ####

还是拿电商业务举例，比如订单表，如果预估未来增长速度会比较快，那么可以考虑提前对订单表进行分库分表。防止单表增长过快。

#### 5 .降低不同库或者表的相互影响 ####

电商业务会涉及多个模块，比如会员，订单，库存等。比如搞了一个活动，扫码送会员积分，如果会员相关的表和订单相关的表在一个库中，那么很可能会员的活动会影响到订单业务。因此可以考虑将这些模块对应的表拆分到不同的库中。避免不同业务表或者库的相互影响。

--------------------

5，缓存是干什么的，可以用作缓存的中间件有哪些，本地缓存和服务器缓存的区别的是什么，使用缓存会带来哪些问题。

#### 缓存是干什么的： ####

**首先我们要知道缓存其实就是一个临时的存储器。**

可以用作缓存的中间件有哪些：

缓存有 ：**cookie、session、application、cache、redis**

#### 本地缓存和服务器缓存的区别的是什么： ####

1.分布式缓存：常用redis,memcached

> 分布式缓存用于集群环境下多节点使用同一份缓存的情况，从而减少数据库查询
> 
> 分布式缓存有网络IO，因此吞吐率与缓存的数据大小有较大关系
> 
> 分布式缓存网络IO导致的时间消耗不可忽略（非常重要）

2.本地缓存：EHCache,JbossCache,Map(ConcurrentHashMap)等

> 本地缓存非常高效，从分布式缓存取一次数据消耗的时间可以从本地缓存取几千几万甚至百万次。
> 
> 本地缓存在集群环境下存在不同节点数据不一致问题，因此使用时需要考虑缓存的时效性，以及缓存数据对不一致的敏感程度

3.缓存时效性选择

> 实际情况下不同场景对同一数据的时效性有差异，比如商品的库存，商品页面展示是否可以购买时可以有短暂的缓存，但提交订单时必须是实时的数据。
> 
> 不同的业务数据对时效性的要求不一样，比如商品属性时效性要求较低，商品价格和库存对时效性要求较高

4.本地缓存+分布式缓存构建高性能网站

> 使用本地缓存做一级缓存，减少分布式缓存的访问量（网络IO带宽消耗及网络时间消耗）
> 
> 使用分布式缓存做二级缓存，减少集群环境下访问数据库的次数

#### 使用缓存会带来哪些问题： ####

[Redis 缓存常见问题 ：缓存雪崩，缓存击穿，缓存穿透，缓存预热][Redis _]

#### 缓存雪崩： ####

缓存雪崩指的是在短时间内，有大量缓存的键同时过期，由于缓存过期，导致此时所有的请求就直接查询数据库，而数据库很难抵挡这样巨大的压力，严重情况下就会导致数据库被大流量打死，直接宕机。

#### 缓存雪崩的解决方法有以下几种 ####

> 1.随机化过期时间，为了避免缓存同时过期，在设置缓存时在原有时间上添加随机时间，使失效时间分散开来
> 
> 2.加锁排队，加锁排队可以起到缓冲的作用，防止大量请求同时操作数据库，但是也正因为如此也减少了吞吐量，导致响应时间变慢，用户体验变差。
> 
> 3.设置二级缓存，即加入一个本地缓存作为备案，当Redis缓存失效后就暂时使用本地缓存进行代替，避免直接访问数据库。
> 
> 4.设置热点数据永不过期，有更新操作时直接更新缓存即可

#### 缓存击穿： ####

缓存击穿与缓存雪崩很像，不过一个是针对大量缓存一个是针对热点缓存。

缓存击穿即当某个热点缓存突然失效，而正好对其有着大量的请求，此时这些请求就会直接向数据库进行查询，导致数据库面临巨大的压力

#### 缓存击穿的解决方法有以下几种 ####

> 1.设置热点数据永不过期，有更新操作时直接更新缓存即可
> 
> 2.加锁排队，通过加锁来减少同一时间的访问量，缓解压力

#### 缓存穿透： ####

缓存穿透是指查询的数据在缓存中和数据库中都不存在，(由于主键通常都是从1开始自增，此时大量查询负数或者特别大的数据就会导致缓存穿透)。

处于容错考虑，由于这些数据在数据库中不存在，所以不会将结果保存到缓存中。而又因为缓存中没有这些数据，所以每次请求都会绕过缓存，直接向数据库查询，这就是缓存穿透

#### 缓存穿透的解决方法有以下几种 ####

> 1.参数校验，对于那些不合法的请求就直接返回空结果，不进行查询
> 
> 2.布隆过滤器，可以根据布隆过滤器来判断数据在不在数据库，虽然布隆过滤器查询存在不一定准确，但是如果布隆过滤器中查不到，则一定说明不存在，就不会进入数据库查询
> 
> 3.缓存空结果，将每次查询的结果进行缓存，即使查询不到的也缓存一个空结果，当有非法请求时就直接返回空结果

#### 缓存预热： ####

与上面三种不同，缓存预热并不是一个需要解决的问题，而是一种优化的策略，通过这种策略能够更快的响应用户的查询。

缓存预热指的是在启动系统的时候，提前将查询的结果预存到缓存中，这样用户查询时就可以直接从缓存中读取，减少了用户的等待时间

#### 缓存预热的实现方法有以下三种 ####

> 1.把需要缓存的函数写入到系统的构造函数中，这样系统就会在启动的时候自动的加载数据并缓存数据
> 
> 2.把需要缓存的函数挂载到前端页面或者后端的接口上，手动触发缓存预热
> 
> 3.设置定时任务，定时自动进行缓存预热

6，kafka是干什么的，可以使用kafka做哪些工作，kakfa和其他消息队列中间件对别的优势劣势。

#### kafka是干什么的： ####

Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。

#### Kafka的特性： ####

> **高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒**
> 
> **可扩展性：kafka集群支持热扩展**
> 
> **持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失**
> 
> **容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）**
> 
> **高并发：支持数千个客户端同时读写**

可以使用kafka做哪些工作：

#### Kafka场景应用： ####

> 1.日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。
> 
> 2.消息系统：解耦和生产者和消费者、缓存消息等。
> 
> 3.用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
> 
> 4.运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
> 
> 5.流式处理：比如spark streaming和storm
> 
> 6.事件源
> 
> kakfa和其他消息队列中间件对别的优势劣势：

#### 优点： ####

>  *  性能卓越，单机写入TPS约在百万条/秒，最大的优点，就是吞吐量高。
>  *  时效性：ms级
>  *  可用性：非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
>  *  消费者采用Pull方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;
>  *  有优秀的第三方Kafka Web管理界面Kafka-Manager；
>  *  在日志领域比较成熟，被多家公司和多个开源项目使用；
>  *  功能支持：功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用

#### 缺点： ####

>  *  Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长
>  *  使用短轮询方式，实时性取决于轮询间隔时间；
>  *  消费失败不支持重试；
>  *  支持消息顺序，但是一台代理宕机后，就会产生消息乱序；
>  *  社区更新较慢；

--------------------

![636f4672534b4a9d93f415d0d9869b16.jpeg][]

[ab7070aa2dcd46a98adba650ed7d51b7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/d6e0aef4ce2f422ca5359e3a1b8ac23b.png
[https_blog.csdn.net_L170311_article_details_129029966_spm_1001.2014.3001.5502]: https://blog.csdn.net/L170311/article/details/129029966?spm=1001.2014.3001.5502
[Redis _]: https://blog.csdn.net/qq_35423154/article/details/108576009
[636f4672534b4a9d93f415d0d9869b16.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/393dd72e7f17473cab211dc68adae651.jpeg