架构- 数据库的优化

一、增长了数据库等链接池后，架构发生了变化，进行了必定的性能提高

 

主从读写分离：

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

 

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

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

 

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

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

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

 

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

 

能够进行一主多从多配置，最多挂3-5个从库，由于从库多了，主库须要log dump线程来处理复制的请求，对主库资源消耗大

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

 

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

一、尽可能不去从库查询数据，能够进行数据的冗余。

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

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

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

 

缓存，若是是更新数据的操做，可能会致使库里和数据库不一致的问题

 

如何访问数据库：

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

 

 

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

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

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

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

 

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

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

二、垂直拆分通常是按照业务来进行拆分的

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

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

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

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

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

 

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

若是不带user_id怎么办？难道所有都查一遍吗？ 思路：能够引入几个简单的映射表，好比user_id和哪几个字段的

映射关系

 

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

Twitter. Snowflake 算法，生成惟一id 

 

Nosql的区分：

Redis ，base，MongoDB

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

话费时间去作昂贵的磁盘寻道， 读写效率要比顺序IO 小两到三个数量级，因此尽可能减小随机IO

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