阿里云教程 ：https://www.aliyun.com/jiaocheng/774911.html
摘要：关系型数据库在大于一定数据量的情况下性能会急剧下降。在面对互联网海量数据的情况时,所有数据都存于一张表,显然很容易会达到数据表可承受的数据量阈值。单纯分表虽然可以解决数据量过大导致检索变慢的问题,但无法解决高并发情况下访问同一个库,导致数据库响应变慢的问题。所以通常水平拆分都至少要采用分库的方式,以一并解决大数据量&;高并发的问题。但分表也有不可替代的......
最近入手一个项目，数据量：每15分钟产生4-5万条记录要求记录保留一个月。平均每天产生384万条数据记录，每个月数据记录已经过亿。如此大的数据量，明显超过了MySQL单表的承载能力，如果不提前规划好，那么随着数据量的积累，访问数据库将越来越慢。
本项目的主要特征就是大数据量，高并发还涉及不到，但是为了一次性解决问题，还是将高并发的需求一并纳入进来。
如何应对？
方法一、分库分表
分库分表用于应对当前互联网常见的两个场景:大数据量 &; 高并发。通常分为:垂直拆分 &; 水平拆分。 垂直拆分是根据业务将一个库(表)拆分为多个库(表)。如:将经常和不经常访问的字段拆分至不同的库(表)中,与业务关系密切。 水平拆分是根据分片算法将一个库(表)拆分为多个库(表)。
方法二、Sharding-JDBC 使用现有的框架
Sharding-JDBC是当当应用框架ddframe中,从关系型数据库模块dd-rdb中分离出来的数据库水平分片框架,是继dubbox、elastic-job之后ddframe开源的第三个项目。
Sharding-JDBC直接分装jdbc协议,可理解为增强版的JDBC驱动,旧代码迁移成本几乎为零,定位为轻量级java框架,使用客户端直连数据库,以jar包形式提供服务,无proxy层。
主要包括以下特点:
可适用于任何基于java的ORM框架,如:JPA、Hibernate、Mybatis、Spring JDBC Template,或直接使用JDBC
可基于任何第三方的数据库连接池,如:DBCP、C3P0、Durid等
理论上可支持任意实现JDBC规范的数据库。目前仅支持mysql
分片策略灵活,可支持等号、between、in等多维度分片,也可支持多分片键。
SQL解析功能完善,支持聚合、分组、排序、limit、or等查询,并支持Binding Table以及笛卡尔积表查询。
性能高,单库查询QPS为原生JDBC的99.8%,双库查询QPS比单库增加94%。
架构
核心概念
LogicTable:数据分片的逻辑表,对于水平拆分的数据库(表)来说,是同一类表的总称。如:订单数据根据主键尾数拆分为10张表,分表是t order0到t order 9,他们的逻辑表名为t_order。
ActualTable:分片数据中真实存在的物理表。
DataNode:数据分片的最小单元,由数据源名称和数据表组成。如:ds 1.t order_0。
DynamicTable:逻辑表和物理表不一定需要在配置规则中静态配置。如,按照日期分片的场景,物理表的名称随着时间的推移会产生变化。
BindingTable:指在任何场景下分片规则均一致的主表和子表。例:订单表和订单项表,均按照订单ID分片,则此两张表互为BindingTable关系。BindingTable关系的多表关联查询不会出现笛卡尔积关联,查询效率将大大提升。
ShardingColumn:分片字段用于将数据库(表)水平拆分的字段。
ShardingAlgorithm:分片算法。
SQL Hint:对于分片字段非SQL决定,而由其他外置条件决定的场景,可使用SQL Hint灵活的注入分片字段。
数据源分布规则配置
逻辑表&;物理表映射
TableRule orderTableRule =TableRule.builder("order").actualTables(Arrays.asList("t_order_0", "t_order_1")).dataSourceRule(dataSourceRule).build();
分片策略配置
Sharding-jdbc认为对于分片策略有两种维度:
数据源分片策略(DatabaseShardingStrategy) 数据被分配的目标数据源。
表分片策略(TableShardingStrategy) 数据被分配的目标表,该目标表在该数据对应的目标数据源内。
DatabaseShardingStrategy databaseShardingStrategy = new DatabaseShardingStrategy("user_id", new ModuloDatabaseShardingAlgorithm());
TableShardingStrategy tableShardingStrategy = new TableShardingStrategy("order_id", new ModuloTableShardingAlgorithm());
ShardingRule shardingRule = ShardingRule.builder()
.dataSourceRule(dataSourceRule)
.tableRules(Arrays.asList(orderTableRule, orderItemTableRule))
.databaseShardingStrategy(databaseShardingStrategy)
.tableShardingStrategy(tableShardingStrategy)
.build();
ShardingDataSource
DataSource shardingDataSource = ShardingDataSourceFactory.createDataSource(shardingRule);
JDBC规范重写
针对DataSource、Connection、Statement、PreparedStatement和ResultSet五个核心接口封装。
DataSource:ShardingDataSource
Connetion:ShardingConnection ShardingConnection是一种逻辑上的分布式数据库链接,成员变量ShardingContext,即数据源运行的上下文信息。
ShardingContext包括:ShardingRule:分片规则;ExecutorEngine:执行引擎,通过多线程的方式并行执行SQL。
Statement:ShardingStatement
PreparedStatement:ShardingPreparedStatement
ResultSet:ShardingResultSet
SQL解析
常见的SQL解析主要有:fdb/jsqlparser、Druid;sharding-jdbc 1.5.0.M1将SQL解析引擎从Druid换成了自研的解析引擎。 Sharding-jdbc支持join、aggregation、order by、group by、limit、or;目前不支持union、部分子查询、函数内分片等不太应在分片场景中出现的SQL解析。
SQL解析引擎在sharding-jdbc-core模块下com.dangdang.ddframe.rdb.sharding.parsing包下,包含两个组件:
项目参考博客：
https://blog.csdn.net/l1028386804/article/details/79368021
https://blog.csdn.net/u012394095/article/details/81705382