架构- 数据库的优化

Posted 2020-11-16 yingchen

1、增加了数据库等连接池后，架构发生了变化，进行了一定的性能提升

 

主从读写分离：

大部分系统时读多，写少，读写的数据量可能会有几个数量级

 

刷朋友圈的肯定比发朋友圈的多太多了。

所以这时候的优化要考虑到主从读写分离

 

主从就要涉及到主从的数据复制过程：

1、主从复制， mysql的主从复制全部依赖于binlog ， mysql的所有变化以二进制的形式存在磁盘上的二进制日志文件中，

binlog从主库传输到了从库上，一般这个过程时异步的，主库操作不等待binlog同步完成

 

从库连接到主节点，会创建一个io线程， 请求binlog的信息，并写入relay_log中，然后在从库进行回放，最终从库一致性

 

可以进行一主多从多配置，最多挂3-5个从库，因为从库多了，主库需要log dump线程来处理复制的请求，对主库资源消耗大

，主库的网络带宽也是限制

 

问题点：主从延迟问题，解决办法：

1、尽量不去从库查询数据，可以进行数据的冗余。

2、使用缓存，写入库的同时在缓存中进行记录     缓存的方案比较适用于新增数据

3、查询走主库（明确查询的量不是很大）

4、运维增强保证对主从延迟的一些监控和报警

 

缓存，如果是更新数据的操作，可能会导致库里和数据库不一致的问题

 

如何访问数据库：

数据库中间件，来解决数据库的访问问题

 

 

业务继续扩张，单表的数据量太大了

数据量大了：占用磁盘空间，恢复和备份时间长，索引也占用很大的空间，查询也会很慢

分库分表， 对数据库进行垂直拆分和水平拆分

依照策略将数据尽量平均地分配到多个数据库节点或者多个表中

 

垂直拆分： 分库，专库专用，好处：

1、业务影响解耦，单独存储对应的业务

2、垂直拆分一般是按照业务来进行拆分的

当单个库数据量也很大的情况下，分表 - 水平拆分：

水平拆分表，按照某些字段来进行拆分

1、某个字段的hash值进行拆分

2、根据时间长度来进行拆分 - 数据不平均，表需要按时提前建好

3、查询的时候比较难确定是哪个库哪个表，数据库中间件来解决问题

 

假如是用user_id来进行水平区分，那之后的查询必须带user_id才能确定表地址并进行查询

如果不带user_id怎么办？难道全部都查一遍吗？ 思路：可以引入几个简单的映射表，比如user_id和哪几个字段的

映射关系

 

分库分表后的id的全局唯一：

Twitter. Snowflake 算法，生成唯一id 

 

Nosql的区分：

Redis ，base，MongoDB

传统的数据库都是机械磁盘， 对于磁盘的访问有两种方式： 一种是随机IO，一种是顺序IO, 随机IO需要

话费时间去做昂贵的磁盘寻道， 读写效率要比顺序IO 小两到三个数量级，所以尽量减少随机IO

LSM树， 牺牲了一定的读性能换取了写入数据的高性能，