(19)国家知识产权局 (12)发明 专利申请 (10)申请公布号 (43)申请公布日 (21)申请 号 202210506961.4 (22)申请日 2022.05.11 (71)申请人 浪潮软件股份有限公司 地址 271000 山东省泰安市东 岳大街527号 浪潮科技园 (72)发明人 李宁　王柏华　赵绍祥　陈兆亮　 (74)专利代理 机构 济南信达专利事务所有限公 司 37100 专利代理师 郗艳荣 (51)Int.Cl. G06F 16/2455(2019.01) G06F 16/22(2019.01) (54)发明名称 分库分表路由方法及系统 (57)摘要 本发明特别涉及一种分库分表路由方法及 系统。 该分库分表路由方法及系统， 从多维度定 义分库分表规则， 使用Elasticsearch搜索引擎 提供高性能的读写支撑， 使用Redis本地缓存系 统缓存路由结果缓解Elasticsear ch搜索引擎的 存储压力， 实现高并发下的数据库读写及查询要 求 。该 分 库 分 表 路 由 方 法 及 系 统 ， 使 用 Elasticsearch搜索引擎持久化路由信息， 通过 Redis本地缓存系统进行缓存， 解决了单次分库 分表的局限性问题， 在应用程序中能够将逻辑表 的查询请求路由分发到具体的分表中， 即保证了 查询的透明性， 又能支持高并发下的数据库请 求。 权利要求书1页 说明书4页 附图1页 CN 114817331 A 2022.07.29 CN 114817331 A 1.一种分库分表路由方法， 其特征在于： 从多维度定义分库分表规则， 使用 Elasticsearch搜索引擎提供高性能的读写支撑， 使用Redis本地缓存系统缓存路由结果 缓 解Elasticsearc h搜索引擎的存 储压力， 实现高并发下的数据库读写及查询要求； 包括以下步骤： 步骤S1、 部署Elasticsearc h搜索引擎和Redis本地缓存系统； 步骤S2、 业 务系统根据自身业 务需求预估数据量， 规划路由规则构成维度； 步骤S3、 在业务系统分表配置中扩展路由规则， 得到多维度路由ID， 利用Redis本地缓 存系统对多维度路由ID进行缓存， 同时将多维度路由ID持久化到Elasticsearch搜索引擎 中， 为业务系统亿 级数量提供高并发读写支持。 2.根据权利要求1所述的分库分表路由方法， 其特征在于： 采用Mysql数据库或HBase数 据库替代Elasticsearc h搜索引擎， 实现多维度路由ID的持久化。 3.根据权利要求1所述的分库分表路由方法， 其特征在于： 所述步骤S2中， 为避免固定 分表导致的存储上限， 根据业务数据属性， 将数据从多个维度进 行分库分表， 包括但不限于 时间、 区域和平均分表三个维度。 4.根据权利要求1所述的分库分表路由方法， 其特征在于： 当业务系统对相关逻辑表发 出读写请求时， 先查询Elasticsearch搜索引擎中是否有当前业务主键的路由信息， 如果 有， 则使用存储的路由到具体的分表中读取或写入 数据； 如果Elasticsearch搜索引擎中没 有索引信息， 则根据路由规则生成主键对应的路由ID， 持久化到Elasticsearch搜索引擎索 引成功后， 再进行 具体分表的读写操作。 5.根据权利要求1所述的分库分表路由系统， 其特征在于： 业务系统发起逻辑表读写请 求后， 先查询Redis本地缓存系统中是否有对应的主键路 由信息， 如果有， 则进行具体分表 的读写操作； 如果没有， 则先根据路由规则生成对应的路由ID， 再持久化到Elasticsearch 搜索引擎中， 同时缓存到Redis本地缓存系统中， 再进行 具体分表的读写操作。 6.一种分库分表路由系统， 其特征在于： 包括业务系统、 Elasticsearch搜索引擎和 Redis本地缓存系统； 所述业务系统负责根据自身业务需求预估数据量， 规划路由规则构成维度， 在业务系 统分表配置中扩展路由规则， 得到多维度路由ID； 所述Elasticsearc h搜索引擎负责实现多维度路由ID的持久化； 所述Redis本地缓存系统负责实现多维度路由ID的缓存； 所述Elasticsearch搜索引擎和Redis本地缓存系统为业务系统亿级数量提供高并发 读写支持。 7.根据权利要求6所述的分库分表路由系统， 其特征在于： 所述路由规则构 成维度包括 但不限于时间维度、 区域维度和平均分表维度。 8.根据权利要求6所述的分库分表路由系统， 其特征在于： 采用Mysql数据库或HBase数 据库替代Elasticsearc h搜索引擎， 实现多维度路由ID的持久化。权　利　要　求　书 1/1 页 2 CN 114817331 A 2分库分表路由方 法及系统 技术领域 [0001]本发明涉及数据治理技 术领域， 特别涉及一种分库分表路由方法及系统。 背景技术 [0002]随着业务系统运行年限的增加， 将产生越来越多的业务数据。 随着单表中的数据 量越来越大， 数据库查询QPS(Query  Per Second， 每秒查询率)越来越高， 相应的， 对数据库 的读写所需要的时间也越来越多， 这将导致数据库的读写性能成为业务发展的瓶颈。 传统 解决方案使用分库/表分担单个数据库/表的压力。 [0003]传统分库/表方案是通过预估数据量， 将原来的一个库/表拆分成固定的n个， 定义 根据业务编号路由的规则。 新业务入库时， 根据路由规则分发到具体的分库分表中。 但随着 后续业务量继续增长， 采用该方式很快还会导致数据库重新到达性能瓶颈， 此时如果要将 原有数据分发到2 n个， 需要对原 来各库/表的数据都重新分发。 分发过程需要对 数据库造成 极大的读写压力， 且重新分发期间将导 致分库/表数据无法提供服 务。 [0004]为了在应用程序中将逻辑表的查询请求路由分发到具体的分表中， 保证查询的透 明性， 本发明提出了一种分库分表路由方法及系统。 发明内容 [0005]本发明为了弥补现有技术的缺陷， 提供了一种简单高效的分库分表 路由方法及系 统。 [0006]本发明是通过如下技 术方案实现的： [0007]一种分库分表路由方法， 其特征在于： 从多维度定义分库分表规则， 使用 Elasticsearch搜索引擎提供高性能的读写支撑， 使用Redis本地缓存系统缓存路由结果 缓 解Elasticsearc h搜索引擎的存 储压力， 实现高并发下的数据库读写及查询要求； [0008]包括以下步骤： [0009]步骤S1、 部署Elasticsearc h搜索引擎和Redis本地缓存系统； [0010]步骤S2、 业 务系统根据自身业 务需求预估数据量， 规划路由规则构成维度； [0011]步骤S3、 在业务系统分表配置中扩展路由规则， 得到多维度路由ID， 利用Redis本 地缓存系统对多维度路由ID进行缓存， 同时将多维度路由ID持久化到Elasticsearch搜索 引擎中， 为 业务系统亿 级数量提供高并发读写支持。 [0012]本发明分库分表路 由方法， 采用Mysql数据库或HBase数据库替代Elasticsearch 搜索引擎， 实现多维度路由ID的持久化。 [0013]所述步骤S2中， 为避免固定分表导致的存储上限， 根据业务数据属性， 将数据从多 个维度进行分库分表， 包括但不限于时间、 区域和平均分表三个维度。 [0014]当业务系统对相关逻辑表发出读写请求时， 先查询 Elasticsearch搜索引擎中是 否有当前业务主键的路由信息， 如果有， 则使用存储的路由到具体的分表中读取或写入数 据； 如果Elasticsearch搜索引擎中没有索引信息， 则根据路由规则生成主键对应的路由说　明　书 1/4 页 3 CN 114817331 A 3