Spring Boot业务系统如何实现海量数据高效实时搜索 _Spring

1.概述我们都知道随着业务系统的发展和使用，数据库存储的业务数据量会越来越大，逐渐成为了业务系统的瓶颈。在阿里巴巴开发手册中也建议：单表行数超过500万行或者单表容量超过2GB才推荐进行分库分表，如果预计三年后数据量根本达不到这个级别，请不要在创建表时就分库分表。数据库最终都是存储在磁盘上，随着数据量变大，会导致数据操作变得缓慢，无论是计算还是IO，但是话又说回来，单表数据量大就一定要进行分库分表操作吗？答案是否定的，因为分库分表本身是一个“很重”的操作，这里就不卖关子了，直接来看看分库分表带来的以下问题和挑战：

重构适配系统本身我们的业务系统不可能一开始开发上线的时候就会分库分表，都是随着系统使用和时间推移数据量日益膨胀才考虑的，进行分库分表我们业务服务项目代码需要从单一数据库表适配成多库多表，这是一次极其繁重的重构任务，还涉及到数据迁移、备份、扩容等操作问题，该任务上线链路之长、风险之大不言而喻，这也是很多小公司即使数据量上来了也不会马上分库分表的原因吧。
事务问题目前数据库只能够实现本地事务，也就是在同一个数据库中，可以允许一组操作要么全都正确执行，要么都不执行，从而确保数据库的一致性。单从分区角度出发，实际上仍然是一张表，一个库中，它不会存在事务一致性的问题，但是会使得事务变得非常复杂。而分库分表会涉及到分布式事务，目前数据库并不支持跨库事务，所以在这一块需要解决分布式事务可能带来的不一致性
分页、排序、聚合函数问题分页需要按照执行的字段进行排序，当排序字段就是分片字段的时候，通过分片规则就比较容易定位到指定的分片；当排序字段并非分片字段的时候，就需要在不同分区、分表中进行排序并且返回，然后再将不同分区、分表中返回的结果集进行汇总和再次排序，最终得到返回结果。取得页数越多，性能受影响也就越大。因为在分区、分表的时候都已经限定了分片字段，而其他字段是跟着分片的字段被分到不同的区域或者表中，这样各个分区、分表中的数据可能是随机的，为了排序的准确性，需要将所有分区、分表节点的前的数据都排好序做合并，最后进行整体排序，这样的操作是非常耗费CPU和内存资源的，所以在分区、分表的情况下、分页数越大，系统的性能也会越差。同样、在使用聚合函数，如Max、Min、Sum、Count进行计算的时候，也会像排序那样在每个分区、分表执行相应的函数，然后再将各个分区、分表的结果集进行汇总和再次计算，最终将结果返回。
全局主键避免重复单表主键id自增能够保证id不重复，但是分库分表之后，多张表就不能保证主键id不重复了，这时候就要使用分布式id算法进行生成。
数据迁移、扩容问题随着数据持续增加分表后还需要进行动态新增表时，这个时候就要考虑数据迁移以及扩容问题。一般做法是先读出历史数据，然后按照指定的分表规则再将数据写入各个分表中。这本身就是繁杂之事。

当然以上问题并不是说分库分表是一个不可取的方案，现在分库分表方案在很多公司系统都有应用的，这里想表达的是需要根据个人公司业务系统数据特点，综合评估做权衡来选择解决数据量大的实施方案。

项目推荐：基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba企业级系统架构底层框架封装，解决业务开发时常见的非功能性需求，防止重复造轮子，方便业务快速开发和企业技术栈框架统一管理。引入组件化的思想实现高内聚低耦合并且高度可配置化，做到可插拔。严格控制包依赖和统一版本管理，做到最少化依赖。注重代码规范和注释，非常适合个人学习和企业使用
Github地址：https://github.com/plasticene/plasticene-boot-starter-parent
Gitee地址：https://gitee.com/plasticene3/plasticene-boot-starter-parent
微信公众号：Shepherd进阶笔记
交流探讨qun：Shepherd_126

2.业务数据量大的解决方案2.1 数据归档来分析一个美团业务场景：我们日常每天点外卖，平时会去查看一年前的订单，看看一年前吃了什么吗？答案是几乎不会，或者说这种查询的请求量比较小，出现这种请求大概是有人问你很早之前点的那家外卖好吃，但是你不喜欢记不得了，你帮她查找一下的场景吧~~ 。由此可见，我们可以根据这一特点进行数据历史归档，即数据做冷、热区分存储。当然这个区分时限要根据自身系统数据特点来指定时限是一年还是半年....这样就能保证我们高频查询的热数据量不大了。