水平拆分策略有很多方案，最重要的一点是选好ShardingKey，也就是按照哪一列进行拆分，怎么分取决于我们访问数据的方式 。
比如我们可以根据时间范围分片，根据创建时间分配到不同的表中 。也可以根据哈希分表，哈希分片可以较为均匀将数据分散在数据库中 。我们现在将订单库拆分为4个库编号为[0,3]，每个库4张表编号为[0,3]，根据分布式id%编号落库，当然也有其他分片方案，这取决于你们公司业务数据特点 。
3.如何实时同步数据到elasticsearch支持海量查询我一开始就强调了分库分表带来的问题，可见今天的重点肯定不是采用分库分表来解决数据量大的问题的，所以我接下来来讲讲我司的解决方案：数据归档+读写分离+同步异构数据源
数据归档可以有效降低数据库数据量，读写分离可以降低单数据库的读写压力，异构数据源es满足日常查询性能要求 。
数据归档的操作步骤前面说过了，至于数据库读写分离实现方案等后续有时间再分析一波，今天主要讲讲如何高效实时同步elasticsearch满足查询要求 。直接看架构图：
文章插图
图片
数据同步elasticsearch大概有两种：
1.针对代码中进行数据库的增删改操作时，同时进行elasticsearch的增删改操作 。这种方式代码侵入性强，耦合度高，实时性高，改造起来比较痛苦，因为你不能错过任何一个增删改的地方同步操作es，否则就会出现数据不一致问题 。
2.利用监听mysql binlog同步，实时性强，对于应用无任何侵入性，且性能更好，不会造成资源浪费 。正好阿里巴巴开源的canal就是干这个的，完美解决问题 。通过上面的架构图知道可以通过canal client拿到canal server对binlog的解析直接同步到es，但是这种方式处理比较慢，等于我们是一条一条的去同步，很多情况下es的索引表是一张大宽表，是来自MySQL几张表join的信息，这要求我们同步的时候还要根据主键通过join sql语句查出数据再同步，自然就更慢了 。所以要使用消息队列kafka进行数据削峰填谷，批量操作是保证实时性的关键 。
4.总结以上全部就是我们对海量数据实时搜索的解决方案浅析，各有利弊 。我们可以根据自身的业务数据情况选择合适的方案即可，切勿动不动就来分库分表，显得有点不知深浅 。
本文转载自微信公众号「Shepherd进阶笔记」
【Spring Boot业务系统如何实现海量数据高效实时搜索】
推荐阅读
- SpringBoot的Cacheable缓存注解
- Spring为什么建议构造器注入
- 下一代Java微服务：从Spring Boot到Quarkus的迁移指南
- 传统机器学习算法在实际业务中的使用场景
- Spring Boot项目业务代码中使用@Transactional事务失效踩坑点总结
- Springboot+Redisson封装分布式锁Starter
- SpringBoot项目中异步调用接口方式知多少？
- Spring Data JPA 和 MyBatis 谁更强？
- 外贸业务员工作内容英文版 外贸业务员工作内容
- Springboot默认的错误页是如何工作及工作原理你肯定不知道？