2016年2月，oracle出了12.2的beta2版本，并且在4月更新了相关文档，如Concepts，Administrator’s Guide，Global Data Services Concepts and Administration Guide等等。这个版本的文档，比之前2015年10月底文档要好很多，许多概念，演示demo，操作步骤都得到了很好的说明。

这里来谈一下sharding相关的几个概念：

（1）Table family：
有相关关联关系的一组表，如客户表（customers），订单表（order），订单明细表（LineItems）。这些表之间往往有外键约束关系，可以通过如下2中方式建立table family：

（1.1）通过CONSTRAINT [FK_name] FOREIGN KEY (FK_column) REFERENCES [R_table_name]([R_table_column]) ——这种关系可以有级联关系。

可以看到上面根表（root table）是customer表，主键是CustId，partition是根据CONSISTENT HASH，对CustId进行分区；
下一级的表是order表，主键是CustId+OrderId，外键是CustId且references Customers表，partition是参考外键；
再下一级表是LineItems表，主键是CustId+OrderId+ProductId，外键是CustId+OrderId，即上一层表达主键，partition是参考外键

（1.2）同关键字PARENT来显式的说明父子关系。——这种关系只有父子一层关系，不能级联。

注意上面的order表和LineItems表，都是属于同一个父表，即parent customers表。

另外，也注意上面的CustNo字段，在每个表中都是有的。而上面说的第一种的级联关系的table family，可以不在每个表中都存在CustNo字段。

（2）Sharded Table和Duplicated table：
上面创建在表，都是sharded table，即表的各个分区，可以分布在不同的shard node上。各个shard node上的分区，是不同的。即整个表的内容，是被切割成片，分配在不同的机器上的。
而duplicated table，是整个表达同样内容，在各个机器上是一样的。duplicate table在各个shard node上，是以read only mv的方式呈现：在shardcat中，存在mast table；在各个shard中，存在read only mv。duplicated table的同步：以物化视图的方式同步。

（3）chunk：
A chunk contains a single partition from each table of a table family. This guarantees that related data from different sharded tables can be moved together.
chunk的概念和table family密不可分。因为family之间的各个表都是有关系的，我们把某个table family的一组分区称作一个chunk。如
customers表中的1号～100万号客户信息在一个分区中；在order表中，也有1号～100万号的客户的order信息，也在一个分区中；另外LineItems表中的1号～100万号客户的明细信息，也在一个分区中，我们希望这些相关的分区，都是在一个shard node中，避免cross shard join。所以，我们把这些在同一个table family内，相关的分区叫做chunk。在进行re-sharding的时候，是以chunk为单位进行移动。因此可以避免cross shard join。

另外，虽然我们设计了chunk来避免cross shard join，但是在做查询的时候，还是有可能会查到非table family进行cross shard join，这在设计之初，就应该避免的。如果有cross shard，还不如用duplicated table。

注：chunk的数量在CREATE SHARDCATALOG的指定，如果不指定，默认值是每个shard 120个chunk

（4）chunk move：
chunk move的条件：
（1）re-sharding发生，即当shard的数量发生改变的时候，会发生chunk move。
注，re-sharding之后，chunk的数虽然平均，但并不连续。如：
原来是2个shard，1～6号chunk在shard 1，7～12号chunk在shard2。加多一个shard后，1～4号chunk在shard 1，7～10号chunk在shard 2，那么5～6，11～12号chunk在shard 3上。即：总是挪已经存在的shard node上的后面部分chunk。
（2）DBA手工发起：move chunk -chunk 7 -source sh2 -target sh1。将chunk 7从shard node sh2上，挪到shard node sh1上。


chunk move的过程：
在chunk migration的时候，chunk大部分时间是online的，但是期间会有几秒钟的时间chunk中的data处于read-only状态。
chunk migration的过程就是综合利用rman增量备份和TTS的过程：
level 0备份源chunk相关的TS，还原到新shard->开始FAN（等待几秒）->将源chunk相关的TS置于read-only->level 1备份还原->chunk up(更新routing table连新shard)->chunk down(更新routing table断开源shard)->结束FAN（等待几秒）->删除原shard上的老chunk


（5）shardspace：
create tablespace set的时候，指定shardspace。主要是在Composite sharding架构中使用多个shardspace。

（6）sharding 方式：
在gdsctl create shardcatalog时指定，
System-Managed Sharding：partitioning by consistent hash.主要作用是打散数据。

Composite Sharding：create multiple shardgroups for different subsets of data in a table partitioned by consistent hash. 分层，可以用不同的shardspace，不同的tablespace set，使用不同的硬件。高级的customer用更好的硬件资源。

Using Subpartitions with Sharding：all of the subpartitioning methods provided by Oracle Database are also supported for sharding. 更细粒度的分区。

（7）如何部署sharding：
简单来说，就是在gsdctl中运行如下命令。关于详细内容，我会另外再写一篇，讲讲sharding的部署和架构中的注意点。