- 背景：
目前，针对一些呈现海量增长模式的行业数据，随着操作量及计算量的增大，为了满足分布式数据库的高性能、高可靠性、高可扩展性要求，业务数据存储方式从传统集中式数据库存储正转向分布式数据库分片存储。而在我们进行分片库表设计时，如以CRM系统为例，往往存在两个客户之间存在一定的关联关系，那么我们在进行分片库表设计时，如何保证在已知一个客户标识情况下，从海量分片数据中快速能查询定位出另一个关联的客户标识。
- 分析：
在进行分片库表设计时，针对两个实体存在关联关系的场景，如CRM中的A、B两个客户，这两个客户之间存在关联关系，我们需要考虑已知A客户标识，在海量分片存储下能快速查询关联的B客户信息：
1）我们先建客户分片表：
创建分片库表：
CREATE TABLE ` customer ` (
`customer_id` varchar(20) not NULL,
`field_1` varchar(20) DEFAULT NULL,
`field_2` int(11) DEFAULT '1',
`shard1` bigint(20) DEFAULT NULL,
PRIMARY KEY (`customer_id `)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
然后设置分片键及其分片算法
sharding @@table name=' customer ' set type='sharding' and sharding_func='shard-XXX-FUNC' and sharding_id='shard1' and dn='dn1…';
2）然后采用双向分片键存储方式建客户关联关系分片表：
如创建客户关联关系分片库表：
CREATE TABLE ` customer_rela ` (
`customer_id_a` varchar(20) not NULL, --关联的A端客户标识
`field_1` varchar(20) DEFAULT NULL,
`field_2` int(11) DEFAULT '1',
`shard1` bigint(20) DEFAULT NULL,--本表记录的分片键
`customer_id_z` varchar(20) not NULL, --关联的Z端客户标识
` customer_id_z_shard1 ` bigint(20) DEFAULT NULL,--关联的Z端客户所在分片键
PRIMARY KEY (`customer_id_a `,`customer_id_z `)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
然后设置关联表的分片键及其分片算法
sharding @@table name=' customer_rela ' set type='sharding' and sharding_func='shard-XXX-FUNC' and sharding_id='shard1' and dn='dn1…';
当需要创建两个客户的关联关系时，可以从两端分别创建两条记录，记录双向的关联关系，同时记录双方客户所在的分片键标识
3）按照数据分片访问
当已知一个客户标识及其所在分片键的情况下，那么可以快速获取存在关联关系的另一个客户标识及其所在分片键：
Select customer_id_z, customer_id_z_shard1 from customer_rela where shard1 = ? and customer_id_a = ？
然后根据上述获取的另一个客户标识及其分片键，查询对应客户信息：
Select * from customer where shard1 = ? and customer_id = ？
4）为了保证数据处理的一致性，对上述关联关系表可以考虑封装公共服务进行处理
为了更高效查询定位数据所在分片，对于分布式数据库中记录实体之间关联关系的关联表（如上述的客户关系表），需要双向记录关联关系，并存储双方的分片键值。因此，为了保证该双向记录数据的完整性和一致性，需要封装公共的数据访问服务，对该数据进行增删改查。
- 结尾：
在企业云化转型过程中，为了支撑企业大型分布式应用快速上云、海量数据高效读写，那么对应用系统分布式数据库的库表分片分表设计显得非常重要，既要考虑实体表的分片策略，也要考虑实体之间关系表的分片策略，同时也要考虑分布式事务的一致性，另外，业务系统在对分片数据频繁读写时也可能会造成分片键的变更，从而引起记录所在分片的迁移需要进行寻址处理，所以企业大型分布式应用上云，既要充分考虑分布式数据库的合理选型，也要充分考虑数据层面的分片分表存储的合理设计。
