现有业务系统，由于数据存储数据过大，导致数据备份，数据故障恢复时间过大(13月在4T左右的数据量)。现该系统需要升级支持另外的公司，需要支持业务数据量是之前业务的10-20倍。原有的数据库量就太大了，现考虑分库，使用横切的方式建立多库，将数据均匀的分布到多个库中，让单库的容量降低。
业务考虑点:
需要支持动态扩容(不能通过数据迁移的方式，成本太高)由于之前的单字段>4k,且都是明文，需要采用压缩加脱敏的方式将数据存储。需要支持原有业务也切换到该新的方案中，需要考虑历史数据如何处理。
技术调研点
原有业务的主要查询条件都是存储在单表，纵表的方式(字段和值存储在行中，主键为订单号)系统有自动进程，需要能够根据队列就能查询到所有的订单。现有后台系统中有复杂sql，多次对查询表进行inner join进行数据查询压缩算法有jdk自带的zip等，需要技术调研加密算法需要采用对称加密算法原有系统有数据库连接模块用于处理相关业务
技术调研:
分库采用sharding-jdbc,sharding-jdbc是开源项目，目前支持分库，分表，读写分离，数据加密，动态扩容等功能，和我们的业务契合，且我们的业务系统都是java，只需引入对应的sharding-jar就可以进行开发了，效率快。
官网摘得的架构图，提供内核、功能、生态3层的可插拔插件设计，扩展性高
sharding-jdbc中支持的分片算法
• 标准分片算法
用于处理使用单一键作为分片键的 =、IN、BETWEEN AND、>、<、>=、<= 进行分片的场景。
• 复合分片算法
用于处理使用多键作为分片键进行分片的场景，包含多个分片键的逻辑较复杂，需要应用开发者自行处
理其中的复杂度。
• Hint 分片算法
用于处理使用 Hint 行分片的场景
支持sql情况
兼容全部常用的路由至单数据节点的 SQL,路由至多数据节点的 SQL 由于场景复杂，分为稳定支持、实验性支持和不支持这三种情况。文档支持:全面支持 DML、DDL、DCL、TCL 和常用 DAL。支持分页、去重、排序、分组、聚合、表关联等复杂查询。
,且如果队列和查询关联会涉及复杂子查询，可能会导致分片查询错误。在原有数据业务基础上动态扩容：自定义分片算法，例如通过分片主键解析到时间，先根据时间决定走第一次分片的算法，还是直接返回对应的db.压缩，加密 . 支持事务：基本都是单订单进行操作，所以只会存在本地事务，支持。
基于2，3的问题可能产生业务不能满足的要求，考虑将查询表和队列表单独迁移到一个search库中，通过kafka等消息队列，在写分片库的时候同时同步给search库，这样search库就能根据各种条件查询到数据且能定位到具体的订单，在根据订单在分片库上查询具体数据，看起来是一个可行的方案。这样要求kafka在同步数据时不能丢失等一系列分布式问题。
注意点:
- sharding在子查询中的表是不能自动识别为分片表的。如select f.name from test f left join (select id,name from test_item) g on f.id=g.id where f.name='test' group by f.id，虽然test_item做了分片表，但是依旧不能自动取模如果涉及表中有子查询关联，会导致不能自动将test_item 转换为对应的分片表，导致错误。如:select f.name from test f left join (select id,name from test_item where id = 555L) g on f.id=g.id where f.id=555L group by f.id
