xx数据库表数据扛爆炸机制[下]
背景说明
这是针对有能力,有时间,有耐心可以打磨的应用架构
情况说明
分表+分区表已经无法支撑我们的业务了，随着应用数据的增多，这时候必须要大刀破斧的进行升级。
技术类型特征总结
- 共享异构数据源
数据收集（二八定律）
业务维度分析
数据场景
首先,我们必须要明确我们的业务场景才有谈论的前提.任何照搬带来永远都是埋雷.尔后，就是对数据在实际使用情况及场景的分析，比如是读写均衡，还是读多写少，具体问题具体分析.
数据存活时间
把这个指标提出来的最重要一点就是,页面停留时间越长，我们数据就越有价值。同时，我们对这一块的工作就越要重视，同时也要做到为它不断续租
数据敏感度
这个指标大白话就是一个更新数据的动作,其他地方都要感知到的间隔时长的容忍度.有些场景，确实是零容忍，必须要实时刷新，类似这种的，我们在异构数据的管道选择时,必须要慎重
技术维度分析
中间件成本
中间件成本选择层面,第一考虑是社区维护性是否良好.因为很多情况下有些坑在社区可以找到答案，省时省力。毕竟我们是商用系统。第二个就是业务适配，是否可以满足各个业务场景。第三个考虑则是团队选择方向，必须要让大家都快速上手。
代码三大特性分析
1.代码扩展性
技术方案
概要说明
技术方案为啥直接选共享异构数据源呢?其实,对应背景说明来说的,由于我们已经对数据库能做的事情已经收获不到显著提升,只能基于分而治之的前提。来突破单一瓶颈限制。而目前我们异构数据共享的方案，其实就是对流量做了依次流转的方式，简易说下的话。实际上，需要我们对代码和架构进行调整
共享异构数据源
redis+db(读多写少)
说明
通过一段时间内一次数据采集后，短时间内持续访问。该方案可以很好的保护数据库，极大减低不必要session开销，同时可以提高系统响应速度.
应对场景---短时高频量小高敏感
数据量不大,短时间内访问频率高的场景，比如工单系统内主工单核心明细数据,大屏系统首页统计数据等等，皆属于短时高频量小特征
缺点
- 数据一致性问题
数据一致性问题,对于代码编写有一定的考验，必要要考虑瞬时高并发问题。否则会出现前后数据不一致类似脑裂问题，造成业务人员对于数据一致性困惑问题。
- 锁问题，
锁问题，其实也是对代码编写的考验，有些同学编写代码依赖jvm的sync关键字锁，重复加锁。导致死锁问题
mongodb+db(读写均衡)
说明
该方案是应对复合数据,简易搜索场景.无论我们在后台管理系统还是前台应用系统,说到底都是需要大量频繁的联表查询,同时联表的主表都是大表，而且主表变动次数频率很低，搜索词也相对稳定。这时候我们通过定时任务将列表联表数据导入到mongo中。后续查询皆走mongo
应对场景---无搜索,列表查询，低敏感
利用了mongdb的灵活性,我们可以将表的结构性数据，进行拆分，只对列表查询中需要的数据进行简化，多表直接变成一张大表，同时业务有所变动时，我们也无需担心。直接重构，维护性和扩展性是大大提升。并且由于列表查询的特点，数据库是必须要将其全部push到内存页中，如果还排序，那么就会直接变成磁盘查询。但是用mondo就不会了，毕竟我们只要我们要的内容。而且传统sql的功能，mongo都是支持的，无痛丝滑过渡
缺点
- 不支持复杂查询--平替rdms部分功能
对于很多需要类搜索场景,mongdb确实无法做到，同时传统db也是无法做到。对于聚合数据，由于本身数据就是聚合数据，对于聚合查询来说，很多情况都是无法支持，如果是全库全表直接同步，又失去其特点，回到原点
ES+db(高频聚合读/搜索)
说明
ES本身就是处理搜索场景,对于我们这种业务列表查询居多的查询来说,是比较优质的方案。同时也对我们习惯了sql查询的人来说，是一种全新的查询模式.同时也是对mongodb方案的一种更强力的补充,二者没有强弱之分，只有适合之选的不同。
应对场景--- 搜索,复杂列表查询
该方案不仅仅是在复杂列表查询,聚合查询下应用,同时也是在大数据量下有优越表现.
缺点
- 使用成本高
对于习惯sql查询的人，需要转换想法才行，入门有一定的门槛。即使是原生也没有那么容易，同时聚合查询也不容易。
实战操作
redis+db
mongodb+db
es+db
求文推荐
觉得文章对你有帮助，记得点赞收藏关注，一键三连
