​分布式数据库，无疑是近些年来数据库领域的重大技术进步。越来越多的用户考虑将传统集中式或单机数据库，迁移到分布式数据库。然而，正如同其他新技术一样，使用分布式数据库同样面临一定的使用门槛。如何平滑地迁移到这一新架构，享受新架构带来的优势的同时，还需规避潜在的劣势。尽管很多分布式数据库产品，正努力降低使用门槛，让用户近似传统数据库的体验去使用它，但这一过程仍面临诸多问题。此外，要想更好地使用分布式数据库，是需要其实现细节有着更多的了解。本文，尝试从研发角度谈谈，如何上手分布式数据库，针对常见的如何做表分片、如何选择分片键等问题加以描述。为了降低过程难度，结合之前在项目实施中的一点经验，自己也尝试编写工具来方便迁移分析。

1. 分布式数据库设计要点

1).选择分片对象

分布式数据库设计的第一个要点，就是选择需分片的对象。这其中需考虑几个问题：

数据规模

一般来说，选择分布式数据库的常见原因之一就是原有数据库容量不足，通过分布式架构存储更多的数据。因此，大数据量的表是优先采用分片设计的首要理由。当然，也存在些特例情况，如表虽然规模很大，但无法明确使用到部分数据或数据不经常使用等，也可考虑使用数据分析或大数据平台。

热点表

还有一种常见的的情况是表虽然不大，但非常热，在单机或集中式架构下成为热点，存在性能扩展的瓶颈。这种情况下，也适合采用分片方式将其分而治之。

管理需求

第三种情况是有些表有着管理需求，如归档、清理、备份等，也可以通过分片设计更精准地满足此类需求。

误区：所有表都需要分片

在分布式数据库下，是否是所有对象都需要分片呢？答案是否定的。当表采用分片化设计后，在享受到分片带来的收益的同时，势必也会有损失。如数据库约束会受到限制、数据表访问存在约束、数据库结构变更更为复杂等。因此，在分布式数据库下仍可考虑采用“单表”设计。此时，就需要考虑如存储位置（单片或广播）等。

2).选择分片键

当确定了哪些表采用分片设计后，后面的问题就是确定每个表的分片键如何选择？这往往也是分布式改造中最难取舍的地方。因为，分布式数据库下，数据只能按照一种方式分布。数据分布的方式主要就是由分片键字段和选择的分片算法来确定。因此，选择一个最具有代表意义的字段最为分片键尤为重要。而选择依据主要是看表是如何被访问的及字段的数据特征，根据多种因素综合考虑。当表按照某种分片逻辑拆分后，其他无法使用该拆分逻辑进行的访问又该如何处理呢？这是可考虑如异构二级索引、冗余对象等方式来解决了。下文介绍的小工具，就是从SQL语句的角度分析潜在的划分依据，供设计者参考。后面将详细展开说明。

3).关联对象设计

当表确定了分片方式后，其关联对象需同步进行设计。这里面设计包括：

约束

在分布式架构下，传统的约束会受到很大限制，这其中包括主键、外键、非空、唯一、检查五类。很多分布式数据库不再支持上面这些约束中的部分。这时就需在设计时有所考虑，将约束能力上移到应用侧去解决。

索引

索引，是优化数据库访问最常用的手段之一。在分布式架构下，索引能力同样有所限制。一般来说，若索引字段前缀包含分片字段，还可以支持；否则，只能通过异构索引方式来实现。可简单理解为，分布式架构下的索引就是按照另一种方式存储的分片表。当然，过多的索引在分布式架构下，开销也是很大的。因此，因分布式架构下分片内的数据已经有限，某些索引是可以考虑不再创建。

序列

序列，主要是为了满足唯一性或自增类需求的。这一能力在单机或集中式架构下比较简单，在分布式架构下通常可考虑用“分布式ID”的方式实现。功能上较之前还是有所限制，特别是自增需求。有些分布式数据库虽然支持，但性能也会较差。

视图

一般来说，分布式数据库支持简单视图，对于复杂视图来说则各有差异。此外，需要注意的是优化器的差异。针对视图类的优化，是比较考验优化器能力的，这点各家产品差异较大。

库内计算（存储过程、函数、触发器等）

针对库内计算，是单机或集中式数据库的一大优势。离数据越近的运算，其效率往往也越高，但对于分布式数据库，存在较大技术难点。目前行业内，能较完美地支持分布式架构下的库内计算，尚有不小的差距。建议还是在应用侧去解决。

4).关联语句验证

在做好上述分片设计后，很重要的一步就是要验证上面设计是否满足需要。验证的方式就是将对象关联的语句提取出来，分析在分布式条件下的运行情况。这里包括语法是否支持、语义是否等价、效率是否有保障？若上述验证不满足预期，就需要考虑做出调整。有些可通过改写方式解决，有些更为复杂情况可能需考虑在应用侧甚至架构层面来解决。这一过程也是很多分布式改造的痛点，存在大量验证过程。

5).其他需考虑因素

除去上述要点外，还有其他因素值得关注：

分区表情况

在传统数据库中，应对海量数据规模的有效手段之一就是分区。是否在分片条件下仍然使用分区，是需要综合考虑的。原则上来讲，数据经过分片设计，已经减少处理规模，分区必要性有所降低，要综合考虑。

复杂计算情况

分布式架构下，有些计算是无法下推到分片内完成的，这就需要提取分片数据，汇聚后计算。这对于上面的计算层的压力较大，也会造成很大的资源开销。这点要关注到分布式数据库的处理逻辑，验证其这方面能力如何。

数据分析需求

针对数据分析类需求，很多分布式数据库考虑到这点，引入诸如HTAP方向的技术能力来解决。有此类需求的场景，需重点验证。

2. 工具实践：分片设计辅助分析

如上面阐述，在分布式数据库改造中，选择需分片的表、确定分片字段及方式是非常重要的环节。之前在不少客户实施过程中，这一过程较为繁琐。虽然通过用户培训，能够了解原理上手设计，但在实操中如何从纷繁复杂的运行环境中找到要点，在众多可能选择中选出相对较优仍比较困难。为解决上述问题，自己尝试通过工具解决上述痛点，降低迁移难度、减少工作量。其原理是以运行环境中SQL为输入，通过解析SQL语句，找到业务核心对象及使用方式；再关联数据字典提取数据特征，方便设计者快速做出选择且不遗漏重要信息。下面根据工具输出，简单介绍下，感兴趣者可与我私聊。

1).输出解读

概览信息

此部分主要为概览性信息，主要包括数据库及分析语句。

此部分为收集数据库信息。目前支持MySQL，其他数据库可扩展支持。

此部分为分析SQL文本。根据输入，可能为多条。

设计参考

此部分是根据输入的SQL语句，提取出表。根据数据字典信息提取表的统计信息。这里需重点关注表大小。如上面所说，表大小分片设计的考虑因素之一。小规模的表，是可以考虑设计为单表或广播表。

此部分是根据数据表，提取索引信息。这些原有的索引设计，可作为后续分片设计的参考之一。此外，分片情况下索引代价过大，也可根据此信息做取舍设计。

此部分根据SQL语句解析结果，提取关联或过滤谓词；并进一步将谓词左右的字段及字段数据特征显示出来。这些提取出的字段，可作为分片键字段选择的重要参考依据。其对应的数据类型、是否为空、基数及使用它的谓词，可方便设计者快速决策。

2).使用建议

工具使用上，可依据如下步骤：

提取业务SQL。可通过系统日志、数据库日志等，提取业务SQL，作为工具输入。提取的SQL需真实反应线上情况，不遗漏重要的业务SQL。

分析业务SQL。通过工具分析提取SQL，获取输出报告。

辅助设计。得到报告后，可根据数据量定位待分片表；根据表字段及谓词字段，确定分片键的范围；根据前面信息和索引，做出初步的设计决策。

验证设计。根据初步的设计结果，在分布式环境下验证上述设计，判断是否满足之前提到的语法、语义及性能。

3).增强改进

这一工具，目前仅考虑到SQL文本，未来可增加对runtime信息的捕获能力，可更为准确描述业务负载。从上述信息中增加对不同语句权重，为后续设计判断提供更为丰富的依据。​