document/current/cn/features/sharding/concept/index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>核心概念 on ShardingSphere</title>
    <link>https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/</link>
    <description>Recent content in 核心概念 on ShardingSphere</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    
	<atom:link href="https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>SQL</title>
      <link>https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/sql/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/sql/</guid>
      <description>逻辑表 水平拆分的数据库（表）的相同逻辑和数据结构表的总称。例：订单数据根据主键尾数拆分为 10 张表，分别是 t_order_0 到 t_order_9，他们的逻辑表名为 t_order。
真实表 在分片的数据库中真实存在的物理表。即上个示例中的 t_order_0 到 t_order_9。
数据节点 数据分片的最小单元。由数据源名称和数据表组成，例：ds_0.t_order_0。
绑定表 指分片规则一致的主表和子表。例如：t_order 表和 t_order_item 表，均按照 order_id 分片，则此两张表互为绑定表关系。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。举例说明，如果 SQL 为：
SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11); 在不配置绑定表关系时，假设分片键 order_id 将数值 10 路由至第 0 片，将数值 11 路由至第 1 片，那么路由后的 SQL 应该为 4 条，它们呈现为笛卡尔积：
SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11); SELECT i.</description>
    </item>
    
    <item>
      <title>分片</title>
      <link>https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/sharding/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/sharding/</guid>
      <description>分片键 用于分片的数据库字段，是将数据库（表）水平拆分的关键字段。例：将订单表中的订单主键的尾数取模分片，则订单主键为分片字段。 SQL 中如果无分片字段，将执行全路由，性能较差。 除了对单分片字段的支持，Apache ShardingSphere 也支持根据多个字段进行分片。
分片算法 通过分片算法将数据分片，支持通过 =、&amp;gt;=、&amp;lt;=、&amp;gt;、&amp;lt;、BETWEEN 和 IN 分片。 分片算法需要应用方开发者自行实现，可实现的灵活度非常高。
目前提供4种分片算法。 由于分片算法和业务实现紧密相关，因此并未提供内置分片算法，而是通过分片策略将各种场景提炼出来，提供更高层级的抽象，并提供接口让应用开发者自行实现分片算法。
 标准分片算法  对应 StandardShardingAlgorithm，用于处理使用单一键作为分片键的 =、IN、BETWEEN AND、&amp;gt;、&amp;lt;、&amp;gt;=、&amp;lt;=进行分片的场景。需要配合 StandardShardingStrategy 使用。
 复合分片算法  对应 ComplexKeysShardingAlgorithm，用于处理使用多键作为分片键进行分片的场景，包含多个分片键的逻辑较复杂，需要应用开发者自行处理其中的复杂度。需要配合 ComplexShardingStrategy 使用。
 Hint分片算法  对应 HintShardingAlgorithm，用于处理使用 Hint 行分片的场景。需要配合 HintShardingStrategy 使用。
分片策略 包含分片键和分片算法，由于分片算法的独立性，将其独立抽离。真正可用于分片操作的是分片键 + 分片算法，也就是分片策略。目前提供 5 种分片策略。
 标准分片策略  对应 StandardShardingStrategy。提供对 SQL 语句中的 =, &amp;gt;, &amp;lt;, &amp;gt;=, &amp;lt;=, IN 和 BETWEEN AND 的分片操作支持。 StandardShardingStrategy 只支持单分片键，提供 PreciseShardingAlgorithm 和 RangeShardingAlgorithm 两个分片算法。 PreciseShardingAlgorithm 是必选的，用于处理 = 和 IN 的分片。 RangeShardingAlgorithm 是可选的，用于处理 BETWEEN AND, &amp;gt;, &amp;lt;, &amp;gt;=, &amp;lt;=分片，如果不配置 RangeShardingAlgorithm，SQL 中的 BETWEEN AND 将按照全库路由处理。</description>
    </item>
    
    <item>
      <title>配置</title>
      <link>https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/configuration/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/configuration/</guid>
      <description>分片规则 分片规则配置的总入口。包含数据源配置、表配置、绑定表配置以及读写分离配置等。
数据源配置 真实数据源列表。
表配置 逻辑表名称、数据节点与分表规则的配置。
数据节点配置 用于配置逻辑表与真实表的映射关系。可分为均匀分布和自定义分布两种形式。
 均匀分布  指数据表在每个数据源内呈现均匀分布的态势，例如：
db0 ├── t_order0 └── t_order1 db1 ├── t_order0 └── t_order1 那么数据节点的配置如下：
db0.t_order0, db0.t_order1, db1.t_order0, db1.t_order1  自定义分布  指数据表呈现有特定规则的分布，例如：
db0 ├── t_order0 └── t_order1 db1 ├── t_order2 ├── t_order3 └── t_order4 那么数据节点的配置如下：
db0.t_order0, db0.t_order1, db1.t_order2, db1.t_order3, db1.t_order4 分片策略配置 对于分片策略存有数据源分片策略和表分片策略两种维度。
 数据源分片策略  对应于 DatabaseShardingStrategy。用于配置数据被分配的目标数据源。
 表分片策略  对应于 TableShardingStrategy。用于配置数据被分配的目标表，该目标表存在于该数据的目标数据源内。故表分片策略是依赖于数据源分片策略的结果的。
两种策略的 API 完全相同。
自增主键生成策略 通过在客户端生成自增主键替换以数据库原生自增主键的方式，做到分布式主键无重复。</description>
    </item>
    
    <item>
      <title>行表达式</title>
      <link>https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/inline-expression/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/inline-expression/</guid>
      <description>实现动机 配置的简化与一体化是行表达式所希望解决的两个主要问题。
在繁琐的数据分片规则配置中，随着数据节点的增多，大量的重复配置使得配置本身不易被维护。通过行表达式可以有效地简化数据节点配置工作量。
对于常见的分片算法，使用 Java 代码实现并不有助于配置的统一管理。通过行表达式书写分片算法，可以有效地将规则配置一同存放，更加易于浏览与存储。
语法说明 行表达式的使用非常直观，只需要在配置中使用 ${ expression } 或 $-&amp;gt;{ expression } 标识行表达式即可。 目前支持数据节点和分片算法这两个部分的配置。行表达式的内容使用的是 Groovy 的语法，Groovy 能够支持的所有操作，行表达式均能够支持。例如：
${begin..end} 表示范围区间
${[unit1, unit2, unit_x]} 表示枚举值
行表达式中如果出现连续多个 ${ expression } 或 $-&amp;gt;{ expression } 表达式，整个表达式最终的结果将会根据每个子表达式的结果进行笛卡尔组合。
例如，以下行表达式：
${[&amp;#39;online&amp;#39;, &amp;#39;offline&amp;#39;]}_table${1..3} 最终会解析为：
online_table1, online_table2, online_table3, offline_table1, offline_table2, offline_table3 配置数据节点 对于均匀分布的数据节点，如果数据结构如下：
db0 ├── t_order0 └── t_order1 db1 ├── t_order0 └── t_order1 用行表达式可以简化为：
db${0..1}.t_order${0..1} 或者
db$-&amp;gt;{0..1}.t_order$-&amp;gt;{0..1} 对于自定义的数据节点，如果数据结构如下：
db0 ├── t_order0 └── t_order1 db1 ├── t_order2 ├── t_order3 └── t_order4 用行表达式可以简化为：</description>
    </item>
    
    <item>
      <title>分布式主键</title>
      <link>https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/key-generator/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/key-generator/</guid>
      <description>实现动机 传统数据库软件开发中，主键自动生成技术是基本需求。而各个数据库对于该需求也提供了相应的支持，比如 MySQL 的自增键，Oracle 的自增序列等。 数据分片后，不同数据节点生成全局唯一主键是非常棘手的问题。同一个逻辑表内的不同实际表之间的自增键由于无法互相感知而产生重复主键。 虽然可通过约束自增主键初始值和步长的方式避免碰撞，但需引入额外的运维规则，使解决方案缺乏完整性和可扩展性。
目前有许多第三方解决方案可以完美解决这个问题，如 UUID 等依靠特定算法自生成不重复键，或者通过引入主键生成服务等。为了方便用户使用、满足不同用户不同使用场景的需求， Apache ShardingSphere 不仅提供了内置的分布式主键生成器，例如 UUID、SNOWFLAKE，还抽离出分布式主键生成器的接口，方便用户自行实现自定义的自增主键生成器。
内置的主键生成器 UUID 采用 UUID.randomUUID() 的方式产生分布式主键。
SNOWFLAKE 在分片规则配置模块可配置每个表的主键生成策略，默认使用雪花算法（snowflake）生成 64bit 的长整型数据。
雪花算法是由 Twitter 公布的分布式主键生成算法，它能够保证不同进程主键的不重复性，以及相同进程主键的有序性。
实现原理 在同一个进程中，它首先是通过时间位保证不重复，如果时间相同则是通过序列位保证。 同时由于时间位是单调递增的，且各个服务器如果大体做了时间同步，那么生成的主键在分布式环境可以认为是总体有序的，这就保证了对索引字段的插入的高效性。例如 MySQL 的 Innodb 存储引擎的主键。
使用雪花算法生成的主键，二进制表示形式包含 4 部分，从高位到低位分表为：1bit 符号位、41bit 时间戳位、10bit 工作进程位以及 12bit 序列号位。
 符号位（1bit）  预留的符号位，恒为零。
 时间戳位（41bit）  41 位的时间戳可以容纳的毫秒数是 2 的 41 次幂，一年所使用的毫秒数是：365 * 24 * 60 * 60 * 1000。通过计算可知：
Math.pow(2, 41) / (365 * 24 * 60 * 60 * 1000L); 结果约等于 69.</description>
    </item>
    
    <item>
      <title>强制分片路由</title>
      <link>https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/hint/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://shardingsphere.apache.org/document/current/cn/features/sharding/concept/hint/</guid>
      <description>实现动机 通过解析 SQL 语句提取分片键列与值并进行分片是 Apache ShardingSphere 对 SQL 零侵入的实现方式。若 SQL 语句中没有分片条件，则无法进行分片，需要全路由。
在一些应用场景中，分片条件并不存在于 SQL，而存在于外部业务逻辑。因此需要提供一种通过外部指定分片结果的方式，在 Apache ShardingSphere 中叫做 Hint。
实现机制 Apache ShardingSphere 使用 ThreadLocal 管理分片键值。可以通过编程的方式向 HintManager 中添加分片条件，该分片条件仅在当前线程内生效。
除了通过编程的方式使用强制分片路由，Apache ShardingSphere 还计划通过 SQL 中的特殊注释的方式引用 Hint，使开发者可以采用更加透明的方式使用该功能。
指定了强制分片路由的 SQL 将会无视原有的分片逻辑，直接路由至指定的真实数据节点。</description>
    </item>
    
  </channel>
</rss>