分布式数据库分片键的选择困难之频繁使用字段较多的问题

在上一篇文章中，我重点说明了在分布式数据库中分片键字段的原则性的选择问题。在业务系统分布式数据库设计时，业务系统覆盖的业务场景的复杂度不同，导致分片键选择的复杂度也相应变化：

1. 有的业务系统所有的业务场景中Where条件中总是带着某个特定的字段，这样就是比较简单的，只要将此字段设定为分片键就是OK的，因为分布式数据库逻辑中很容易通过此字段准确定位到相应的数据节点（Data Node），可以笼统的认为直达某个具体的数据库直接进行操作了。
2. 有的业务系统业务场景稍微复杂一点儿，在所有的业务场景中涉及频繁使用的是同时两个字段，在此种场景下，可以借助分布式数据库的二级分片能力，将这两个字段设置为二级分片键，即首先将字段1进行分片，在此基础上对字段2再进行分片。例如：在某个全国集中的业务系统中，对某表我们采用二级分片确保分布式数据库的整体设计，首先按照Province_Code进行list分片，即将某个省份的数据进行统一设置，将该省的数据集中分配到特定的数据库群体中，然后采用User_ID进行hash分片，确保将该省所有的数据通过User_ID采用hash算法分配到到以上数据库群体中某个特定的数据节点中。在此业务系统中，几乎全部的SQL语句都是携带Provice_Code和User_ID来进行请求的，这样分布式数据库能够准确快速高效的命中涉及的目标数据库。
3. 有的业务系统业务场景相比较而言更复杂，针对不同的业务场景使用不同的条件，在此种情况下，关键看不同业务场景中请求方请求的概率以及涉及的表的数据量等情况。先建议几种具体的方案：
   1. 如果所有的业务场景中某个字段携带过来的概率要明显高于其他的字段，建议使用此频率最高的字段为分片键，其他的业务场景的通过全集群扫描的方式来实现，即优先解决主要矛盾，将次要矛盾通过遍历所有数据节点的方式来解决。
   2. 如果所有的业务场景中携带过来字段的概率都差不多，那看一下使用频率比较多的业务场景的操作类型。
      • 如果只有一种业务场景是增删改，其他的业务场景都是查询，可以通过以此表作为基表创建物化视图来进行处理，即将增删改操作对应的高频率字段作为分片键来进行处理，其他的业务场景的高频率条件字段作为物化视图的分片键。如此可以高效发挥物化视图的优势，能够最大限度发挥缓存的效果，提供低时延的查询响应。
      • 如果有多个业务是更新操作，建议将最高频率的条件字段作为分片键，其他更新条件的字段需要创建索引，但是对于这种场景，跟不带字段或者就是携带非分片键字段的场景一致，基本上就是对分布式数据库所有的数据节点（Data Node）同步进行操作了，此场景下，木桶效应是体现的淋漓尽致的。也就是说，在对请求进行响应时，查询较慢的数据节点（Data Node）就是木桶效应的短板，整体分布式数据库的响应时长都是受此短板限制的，甚至超出应用系统的超时设置参数。

        以上是未考虑多表关联的场景，如果在实际的业务场景中，涉及多表关联的场景，把握一个原则，最大限度避免出现跨库操作的情况，如果涉及跨库操作，将大大影响整个分布式集群的性能。如何避免跨库查询，将在下篇文章中进行阐述。