phalapi-进阶篇6(解决大量数据存储数据库分表分库拓展)
前言
时隔半个月随着PHP7的推出为PHP打了一瓶兴奋剂,在性能提升了一倍的情况下我们会逐渐发现,瓶颈会集中在数据库操作,那我们的内容就接着数据库读写分离,来聊聊分表分库应该怎么玩,应为PhalApi的分表分库并不是非常方便,笔者在这里提供了一个分表分库数据库集群的拓展,详细文档请见博客基于PhalApi的DB集群拓展 V0.1bate 大家可以自行在开源中国扩展Git地址中找到Cluster进行下载使用.
先在这里感谢phalapi框架创始人@dogstar,为我们提供了这样一个优秀的开源框架.
附上:
开源中国Git地址:http://git.oschina.net/dogstar/PhalApi/tree/release
开源中国扩展Git地址:http://git.oschina.net/dogstar/PhalApi-Library
1. 场景
在实际工作中,我信奉一句话一切抛开业务的架构设计都是耍流氓所以我们从场景进行开篇
1.1 单条数据多查多写多改
这里做的例子,大家都在玩游戏把,玩游戏里面是不是有角色,角色是不是有装备,经验,物品以及等等,而且他会有一个特别的要求就是实时(因为我角色打了一个怪物获得了100xp我们不可能告诉他你等6个小时缓存时间结束了再来看,必须是实时的),当然我们可以使用缓存来解决这个问题我们下节会说道这个问题
那么在这种场景下,一个用户对于角色的操作非常频繁而且唯一我们就很好采用分表分库的操作了,相对于单表操作他会把所有的操作分散到各各数据库去操作,这样对于单个数据库总执行sql语句量就会有个指数级的下降,以及数据量也会均衡分配到每个数据库,但是当我们进行这类单条数据操作的时候根本不会对性能有任何的影响,因为只是通过算法得出了这条记录存在于那个库那张表而已,
1.2 日志记录分析
就已上面的例子我们继续讲,如果有一天你的领导过来提了个需求,我需要一个数据分析系统来统计用户每天什么时间段最活跃.用户平均没人充值了多少钱啊,多少等级下用户冲钱最多啊,如果遇到这种问题你们会怎么办?三分钟思考
我们先来看看我们会遇到什么样子的问题,数据量大积累当1000w+之后数据库执行sql基本没法看,大量的写入数据对数据库压力大
我们再来看看分表分库怎么解决这个问题,1000w+数据库的情况下 比如你是4表4库一共16张表,那每张表的数量就是1000w/16=62w也就是每张表只需要存储62w的数据就ok了,当写入数据的时候会根据ID的顺序均衡写入4库执行sql的压力也就分布到了4个数据库,唯一的问题就是在执行where条件的时候可能需要对前置表进行遍历,而前置表的数据量就是1000w,当然前置表里面只存放ID和where条件的字段
2. 实现思路
就笔者在工作中接触到了很多案例的分表分库使用了根据城市,或者是其他的特性进行分表分库规则,这样一定会出现用户分布不均匀导致的莫一个库表压力巨大,我这里使用了均等分分割
大家先看一组图就会明白了
- 当我们进行插入的时候的操作如下:
插入前置表获取主键,通过id得出应该存入几库几表在相应的地方写入数据
- 当我们进行单条读取操作的时候操作如下:
通过id获取应该在几库几表在相应的地方获取数据
- 当我们使用where查询的时候操作如下:
如果where条件在前置表存在从前置表通过where获取结果集ID,通过ID分组到库和表,然后进行查询在拼接结果集统一返回
3. 优缺点
- 优点:
很好的避开了数据库存放数据过多效率底下的瓶颈
在单条记录操作性能指数及提升
数据量大的情况下where条件查询性能提高基本
能对亿级的数据进行处理而且效率较高
不需要考虑分表分库规则数据均等分布
- 缺点
where查询字段必须预先添加到,前置表不然就必须遍历数据库数量 * 表数量才能得到想要的结果
where查询就算有前置表的情况下最坏的情况也需要遍历数据库数量 * 表数量才能得到想要的结果
对一些特定查询天生不足比如排序
4. 总结
在本小节的最好简单提及一下,基于PhalApi的DB集群拓展 V0.1bate功能展示比较局限童鞋们可以根据自己的业务需求来觉得是否使用,笔者也会在后期继续更新维护完善为一个比较方便的集群拓展.
注:笔者能力有限有说的不对的地方希望大家能够指出,也希望多多交流!