高并发中的数据库设计

一、单机数据库

1、数据库的基本组成
(1)K-V存储
(2)事务引擎、关系代数和
(3)用户API

2、K-V存储
(1)本质来说,就是“映射”,按照key找打value
(2)所有数据存储的最基本和最底层的结构
(3)不文件系统找指定的数据的作用相同,也是根据指定的key查找到对应的数据
(4)映射的关键特性
是否支持范围查找?是否能够处理更新?读写性能指标?是否面向磁盘结构?并行指标?内存占用?
(5)按照key找到对应的数据
(6)二级索引:分级key-value-key-value等
(7)组合索引:两个key

3、事务
(1)事务的核心就是锁与并发
(2)查询加锁,保证数据不会被独占
(3)单个事务单元:建立索引、读取记录、写入记录、删除。。。
(4)一组事务单元

4、SQL引擎
(1)AST
抽象语法树,标记SQL的组成方式
(2)执行计划
告知执行器如何高效的利用K-V

二、分布式数据库

1、多机Key-Value存储
(1)可运维、高性能、可以比较容易地扩容
(2)核心数据结构还是hash和树,部分case针对多机做了一点点优化
(3)代表组件

mongoDB->mongos服务器
Hbase->region server + client jar包
DRDS(TDDL)->tddl规则引擎组件

2、路由
(1)规则引擎
有状态数据应按照什么规则进行写入和读取
(2)本质来说还是查找的过程
Hash:O(1)效率,不支持范围查询(按时间这样的查询条件就比较困难),不需要频繁调整数据分布
Tree:主要是B-Tree,O(logN)效率,支持范围查询,需要频繁分裂和合并

3、Hash
(1)Id%n最普通的hash
(2)如果id%3 -> id%4总会有80%的数据发生移动,最好情况下是倍分id%3 -> id%6,这时候会有50%的数据发生移动,数据移动本身过于复杂
(3)一致性hash:主要解决数据扩容和缩容

Def idmod=id%100
If(id>=0 and id<250) return db1;
Else if(id >= 250 and id < 500) return db2;
Else if(id >= 500 and id < 750) return db3;
Else return db4;

(4)虚拟节点

解决热点问题,只需要调整对应关系即可
解决n到n+1问题,规则可以规定只移动需要移动的数据
方案相对的复杂一些
一般推荐使用简单方案开始,使用n到2n方案扩容
只有需要的情况下,再考虑平滑的扩展到虚拟节点方案即可

4、B树
Hbase使用的切分方法
支持范围查询,对于大部分场景来说,引导列都是pk.userid一类的单值查询,用树相对复杂
需要频繁的进行切分和合并操作,region server的噩梦
固定节点情况下,跨度相对较大,查找效率可能会进一步降低

5、一致性问题C(顺序)A(安全)P
(1)无主机方案Dynamo/cassandra/Paxos:gossip
W+R>N,所有节点可写,不存在单点故障
读数据的最新版本,需要将所有可写节点的数据都读出来合并一次
(2)有主机方案(Raft)
Mysql MongoDB Oracle+firbreChannel
只有一个节点可写,切换时存在短暂leader election过程,会出现短暂不可写
数据一致性比较好控制,读最新数据只需要读主机就可以,一致性读性能较好

6、考虑问题
(1)有些机器负担写任务,因此读压力可能不均衡,因此必须有权重设置
(2)单个节点挂掉的时候,TCP超时会导致业务APP的线程花费更多的时间来处理单个请求,这样会降低APP的处理能力,导致雪崩
(3)因为突发情况,导致数据库请求数增加,数据库响应变慢,导致雪崩

三、数据库时间

1、单机优化原则
(1)二分查找效率》全表遍历,选择合适的索引
(2)内存读写》SSD读写》磁盘读写,将物理读(磁盘读)换成逻辑读(内存读)
(3)减少锁冲突,尽可能通过业务设计,将更新变成插入
(4)减少临时表使用,减少多维护排序

2、分布式系统优化原则
(1)减少跨机网络交互,尽可能带sharding key,分页优化
(2)减少数据读写热点,切分颗粒度尽可能细,用户颗粒度好于省份
(3)减少锁开销,尽可能规避分布式事务

3、原则
(1)尽一切可能利用单机资源:单机事务、单机join
(2)尽可能走内存,尽可能将一次要查询到数据物理的放在一起
(3)通过合理的数据冗余,减少走网络的次数
(4)合理并行提升响应时间
(5)读取数据瓶颈,可以通过加slave节点解决
(6)写入瓶颈,用规则sharding和扩容来解决

你可能感兴趣的:(数据库)