1. 介绍 增强版的JDBC驱动，兼容JDBC和各种ORM框架
-
数据分片、读写分离。通过Sharding-JDBC，应用可以透明使用jdbc访问已经分库分表、读写分离的多个数据源。
而不用关心数据源的数量以及数据如何分布。 -
分片规则：分片键和分片算法
-
主键生成策略为 SNOWFLAKE
-
流程分析
通过日志分析，Sharding-JDBC在拿到用户要执行的sql之后干了哪些事儿：
（1）解析sql，获取片键值，在本例中是order_id
（2）Sharding-JDBC通过规则配置 t_order_$->{order_id % 2 + 1}，知道了当order_id为偶数时，应该往 t_order_1表插数据，为奇数时，往t_order_2插数据。
（3）于是Sharding-JDBC根据order_id的值改写sql语句，改写后的SQL语句是真实所要执行的SQL语句。
（4）执行改写后的真实sql语句 （5）将所有真正执行sql的结果进行汇总合并，返回。
2. 执行原理
- 基本概念
-
逻辑表：水平拆分数据表的总称
-
真实表：物理表
-
数据节点：数据分片的最小物理单元。数据源名和数据表组成。
-
绑定表：分片规则一致的主表和子表。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。
-
广播表：所有分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。
适用于数据量不大但需要与海量数据的表进行关联查询的场景。字典表。 -
分片键：用于分片的数据库字段。
-
分片算法：
-
分片策略：分片键+分片算法。 尾数取模、哈希、范围、标签、时间等。
-
自增主键生成策略：通过在客户端生成自增主键替换以数据库原生自增主键的方式，做到分布式主键无重复。
- 解析sql：
-
sql解析
-
查询优化
-
sql路由：针对逻辑表的数据操作映射到对数据节点操作的过程。
-
直接路由
-
标准路由
-
笛卡尔路由
-
全库名路由
-
-
sql改写：工程师面向逻辑表书写的SQL，并不能够直接在真实的数据库中执行，SQL改写用于将逻辑SQL改写为在真实数据 库中可以正确执行的SQL。
-
sql执行：sharding-jdbc采用一套自动化的执行引擎，负责将路由和改写完成之后的真实SQL安全高效地发送到底层数据源执行。
-
执行引擎的目标是自动化的平和资源控制和执行效率：
-
内存限制模式：
-
连接限制模式
-
-
-
结果归并：遍历、排序、分组、分页和聚合：
-
流式归并：每一次从数据库结果集中获取到的数据，都能够通过游标逐条获取的方式返回正确的单条数据，它与数据库原生的返回结果集的方式最为契合。
-
内存归并
-
装饰者归并：对所有的结果集归并进行统一的功能增强
-
3. 水平分表
- spring.shardingsphere.sharding.tables.t_order.table-strategy.inline.sharding-column = order_id
- spring.shardingsphere.sharding.tables.t_order.table-strategy.inline.algorithm-expression = t_order_$->{order_id % 2 + 1}
4. 水平分库
- 分库策略，以user_id为分片键，分片策略为user_id % 2 + 1，user_id为偶数操作m1数据源，否则操作m2。
- spring.shardingsphere.sharding.tables.t_order.database-strategy.inline.sharding-column = user_id
- spring.shardingsphere.sharding.tables.t_order.database-strategy.inline.algorithm-expression = m$->{user_id % 2 + 1}
5. 垂直分库
6. 公共表
可以将这类表在每个数据库都保存一份，所有更新操作都同时发送到所有分库执行。
- 创建数据库：
7. 读写分离：sharding-jdbc 读写分离则是根据SQL语义的分析，将读操作和写操作分别路由至主库与从库。
-
它提供透明化读写分离，让使用方尽量像使用一个数据库一样使用主从数据库集群。
-
提供一主多从的读写分离配置，可独立使用，也可配合分库分表使用，同一线程且同一数据库连接内，如有写入操作，以后的读操作均从主库中读取，用于保证数据一致性。
-
不提供主从数据库的数据同步功能，需要采用其他机制支持。
8. 总结：
-
分库分表是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分成若干数据表组成，
使得单一数据库、单一数据表的数据量变小，从而达到提升数据库性能的目的。 -
最佳实践：
-
系统在设计之初，就该对业务数据的耦合松紧进行考量，从而进行垂直分库、垂直分表，是数据库架构清晰明了。
-
如果缓存使用过之后，数据库的访问量还是非常大，可以考虑数据库读、写分离原则。
-
若当前数据库压力依然很大，且业务数据持续增长无法估量，最后可以考虑水平分库、分表，单表拆分数据在1000万以内。
网友评论