分布式数据库是近几年比较关注的领域。一方面，随着数据规模不断增大，数据使用场景更加多样化，对底层数据库的要求也越来越高；另一方面，对数据库的可用性和可扩展性也提出了更高的要求。分布式数据库的出现恰好满足了以上两方面的需求。但是当用户选择使用分布式时，首要的问题就是如何将之前基于单机或集中式数据库设计的数据结构迁移到分布式环境中。核心点在于数据分片的设计。核心有两点：一是选择什么字段或者字段组合作为shardingkey；另一个是用于分片的分片算法。本文试图解决第一个问题。1、是否需要设计分片？你需要设计分片吗？相信这是大家第一个提出的问题。分布式数据库作为一种新的架构，确实可以解决一些场景问题，但是在设计之初就需要考虑数据分片。有没有更透明的方式来解决碎片化问题，由此引出一个概念——“数据分布独立性”。这意味着用户或用户程序像使用集中式数据库一样使用分布式数据库，而不考虑全局数据的分布。也就是说，全局数据的逻辑分片和分片的物理位置对用户和用户应用都是透明的。因此，分布式数据库中的分布独立性也变成了分布透明。分布式数据库系统提供的分布透明度越高，用户编写应用程序就越容易。理想情况下，软件工程师根本不必处理应用程序级别的分片，因为那不是他们的真正工作。然而，理想很丰满，现实很骨感。全透明数据分片在一些场景下仍然面临问题，比如低延迟、业务复杂、多中心等，这些场景仍然希望能够精确控制数据分片规则甚至物理位置。因此，如何设计分片策略成为了DBA们在新环境下不得不面对的问题，至少在很长一段时间内是这样。就像数据库初学者需要学习的范式理论一样，未来数据分片的设计也是测试架构、研发和DBA的基本要求之一。这里稍微说明一下，分布式数据库的实现方式主要有两种，一种是分库分表；另一个是NewSQL。两者的对比可以参考下图。具体在sharding方面，前者通常可以提供更加灵活和精准的sharding控制，而后者在sharding的易用性上更有优势。2、如何选择分片字段数据分片的设计需要考虑两点：一是分片字段的选择；二是分片字段的选择。另一种是相应的分片算法。后续会重点介绍分片字段的选择。下面简单介绍一下分片算法。1).分片算法分片算法包括LIST、RANGE、HASH或自定义算法。可以根据各个拆分算法的特点进行选择。如果范围是统一的，可以使用HASH，对于冷热数据，可以使用RANGE。同时可以配合一些特征设计，比如利用二级映射解决伸缩问题，特征编码域满足多特征拆分等。最常见的两种算法的描述如下：RANGE通过数据的范围来分库分表，是一种最简单的分库方案，也可以与其他分库分表方案灵活结合。当需要使用分片字段进行范围搜索时，RANGE分片策略可以快速定位数据进行高效查询。大多数情况下，跨分片查询的问题是有效避免的。在后期的扩展中，也更加方便。只需要添加节点，不需要迁移其他分片的数据。但是，这种分发方式容易产生数据热点。虽然HASH分库分表的方案有很多，但是Hash分库分表是最流行和最常见的方案。随机分片不是随机的，也是有一定规律可循的。通常，HASH模用于分片分裂，因此有时也称为离散分片。随机分片数据比较均匀，不易出现热点和并发访问瓶颈。但是对于后续的数据迁移来说就不是很方便了。使用一致的HASH算法可以在很大程度上避免这个问题。另外，离散分片也容易出现跨分片查询的复杂问题。2).FragmentationFields碎片域的选择涉及到很多因素，在脑图分类中列出。下面将对每个因素进行详细说明：数据结构：主键或唯一键主键和唯一键是数据库中常用的保证非空和唯一性的约束。在分布式环境中，通常建议使用主键或唯一键字段作为片键或片键的一部分，否则无法完成约束验证；当然也有支持单独约束验证的产品。这里有个扩展问题，就是主键设计问题。在分布式数据库架构中，尽量不要使用自增作为表的主键。自增性能差，安全性不高，不适合分布式架构。通常可以使用UUID或全局分词器（雪花算法）之类的东西。简而言之，用有序的全局唯一替换自增是分布式数据库主键的推荐做法。数据结构：索引可以通过shardkey将SQL查询路由到指定的shard，但在实际生产环境中，业务需要通过其他索引访问表。遗留系统的索引需要一个单独的策略。通常的策略是使用索引表，即将索引转换成另一个分片表，通过二次查询来解决查询，但显然这种方法不够优雅。因此，最优的设计不是创建索引表，而是将索引数据整合到shardkey信息中，这样可以直接通过查询的列知道shard信息。效率更高，查询可以提前知道数据对应的分片信息，只需一次查询就可以得到想要的结果。综上所述，索引对分片字段的选择没有直接影响。对于高频索引查询，可以考虑加强shardkey的设计。也可以通过全局二级索引（一些分布式数据库支持）或分片内的公共索引来实现。数据结构：字段类型作为shardingkey的字段。通常选择比较简单的数据类型字段来提高效率，比如常见的数字、日期、文本等，不推荐复杂的字段，比如LOB、JSON等。另外还需要考虑类型设计时注意分片域的稳定性，尽量不要改动DDL。数据特点：表规模表规模是是否使用sharding的关键因素之一。表一旦碎片化，必然会造成一定的“功能退化”。如果可以使用其他方法来减小表的大小，则应尽可能优先考虑其他方法。通过表的全生命周期规划，如常规的数据归档、压缩、转储、清洗等策略，减少数据量；或者通过表分区、垂直表分区等数据库内置的策略，可以有效地减小表的大小。数据特性：分散性这里所说的分散性是指数据根据某个领域或领域的组合应用分片算法后是否足够分散。数据分片的初衷是为了减小表的大小，其基本原则之一就是尽可能分散数据。这里需要统计拆分后数据的分散程度，尽量选择能够完全分散的字段作为shardingkey。这里需要注意的是，如果选择的字段具有业务特性，还需要关注未来业务变化对其的影响。访问特性：可变性选择一个固定不变的字段作为分片键。虽然有些分布式数据库也支持修改shardkey，但是毕竟修改会涉及到数据的移动，成本非常高；最好选择不变的字段。接入特点：对于事务隔离，尽量选择按字段拆分的数据，数据变化的处理可以集中在分片中。如此大量的业务变更，可以通过本地事务完成，开销比全局小很多，效率也高。访问功能：数据过滤和关联。此类字段经常用作数据过滤字段，选择率非常好。它们可以优先作为分片字段。另一种情况是和其他关联表一起使用，最好选择那些参与关联操作的字段。数据关联后，join动作尽量在本地完成，减少数据shuffle或向上迁移、聚类操作。通过对系统中执行的SQL进行统计分析，可以筛选出需要分片的表中使用频率最高或最重要的字段类分片。这可能包含一些来自OLAP类的查询，可以排除这部分SQL。Shardingfieldorder如果使用多个字段作为shardingkey，顺序因素一般没有影响。主要针对分片算法，可以使用字段来做分片。但是在复合分片的情况下，必须考虑分片字段的主次关系。
