架构- 数据库的优化

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树, 牺牲了一定的读性能换取了写入数据的高性能,
相关文章
相关标签/搜索