分布式数据库无疑是近年来数据库领域的一大技术进步。越来越多的用户正在考虑将传统的集中式或单机数据库迁移到分布式数据库。但是，与其他新技术一样，分布式数据库的使用也面临着一定的使用障碍。如何顺利迁移到这个新架构，在享受新架构带来的优势的同时，也需要规避潜在的劣势。尽管很多分布式数据库产品都在努力降低使用门槛，让用户可以像传统数据库一样使用，但是这个过程仍然面临很多问题。另外，为了更好的利用分布式数据库，有必要对其实现细节有更多的了解。在这篇文章中，我尝试从研发的角度谈谈如何入门分布式数据库，并描述常见的问题，如如何做表分片，如何选择分片键。为了降低过程的难度，结合项目实施的一点经验，我也尝试写了一些工具，方便迁移分析。一、分布式数据库设计要点1).选择要分片的对象设计分布式数据库的第一点是选择要分片的对象。需要考虑几个问题：数据规模一般来说，选择分布式数据库的一个常见原因是原有数据库容量不足，更多的数据通过分布式架构存储。因此，数据量大的表是首选分片设计的主要原因。当然，也有一些特殊情况。例如，虽然表的规模很大，但有些数据不能明确使用，或者数据不经常使用。也可以考虑数据分析或大数据平台。热点表的另一种常见情况是，表虽然不大，但是很热。在单机或集中式架构下成为热点，存在性能扩展瓶颈。这种情况下，用sharding来分而治之也是合适的。管理需求第三种情况是有些表有管理需求，比如归档、清理、备份等，也可以通过分片设计更准确的满足。误解：所有表都需要在分布式数据库中进行分段。是否所有对象都需要分片？答案是否定的。当表采用碎片化设计时，在享受碎片化带来的好处的同时，也难免会有损失。比如数据库约束会受到限制，存在数据表访问约束，数据库结构变化比较复杂等。所以在分布式数据库下还是可以考虑“单表”的设计。此时，您需要考虑诸如存储位置（单片机或广播）。2).选择分片键。确定了哪些表采用了sharding设计之后，接下来的问题就是确定每个表的shardingkey如何选择？这往往是分布式改造中最困难的选择。因为，在分布式数据库中，数据只能以一种方式分布。数据分布的方式主要由分片键字段和选择的分片算法决定。因此，选择一个最具代表性的字段作为分片键就显得尤为重要。选择依据主要是根据表的访问方式和字段的数据特性，综合各种因素综合考虑。当一张表按照一定的分片逻辑进行分片后，其他不能使用分片逻辑的访问怎么办？这可以通过考虑异构二级索引和冗余对象等方法来解决。下面介绍的这个小工具就是从SQL语句的角度来分析潜在的划分依据，供设计者参考。稍后将详细描述。3).关联对象设计当表分片方式确定后，需要同步设计其关联对象。这里的设计包括：约束在分布式架构下，传统的约束会受到很大的限制，包括五类：主键、外键、非空、唯一、校验。许多分布式数据库不再支持上述某些约束。这时候就需要在设计时考虑，将约束能力移到应用端来解决。索引索引是最常用的优化数据库访问的手段之一。在分布式体系结构中，索引功能也受到限制。一般来说，如果索引字段前缀包含分片字段，也可以支持；否则只能通过异构索引来实现。可以简单的理解为分布式架构下的索引是一个以另一种方式存储的分片表。当然，太多的索引在分布式架构中是昂贵的。因此，由于分布式架构下分片中的数据有限，一些索引可以考虑不再创建。Sequence序列，主要满足唯一性或自增性的要求。这种能力在单机或集中式架构中比较简单，而在分布式架构中，通常可以通过“分布式ID”的方式实现。功能相比之前还是有所限制，尤其是自增的需求。一些分布式数据库虽然支持，但是性能会很差。视图一般情况下，分布式数据库都支持简单视图，但对于复杂视图则有所不同。此外，需要注意的是优化器的差异。对于视图类的优化，考验的是优化器的能力，不同产品之间差异很大。库内计算（存储过程、函数、触发器等）针对库内计算，这是单机或集中式数据库的一大优势。离数据越近的操作往往效率越高，但对于分布式数据库来说，存在较大的技术难点。目前业界在分布式架构下完美支持馆内计算的能力还存在较大差距。建议在应用端解决。4).关联语句验证上面的分片设计完成后，很重要的一步就是验证上面的设计是否满足需求。验证的方式是提取与对象关联的语句，分析分布式条件下的运行情况。这包括语法是否支持，语义是否等价，效率是否有保证？如果上述验证不符合预期，则需要考虑调整。有些可以通过重写来解决，有些更复杂的情况可能需要在应用端甚至架构层面去考虑。这个过程也是很多分布式改造的痛点，有很多验证过程。5).其他需要考虑的因素除了以上几点，还有一些其他因素值得关注：分区表情况在传统数据库中，处理海量数据规模的有效手段之一就是分区。分片情况下是否使用分区需要综合考虑。原则上对数据进行了分片，降低了处理规模，减少了分区的必要性，应该综合考虑。在复杂计算的分布式架构下，有些计算无法下推到分片中完成，需要提取分片数据，聚合后计算。这给上层计算层带来了很大的压力，也造成了很大的资源开销。此时，我们要关注分布式数据库的处理逻辑，验证其在这方面的能力。数据分析需求针对的是数据分析需求。很多分布式数据库考虑到这一点，引入HTAP等技术能力来解决。有此类需求的场景需要重点验证。2.工具实践：分片设计的辅助分析上面已经解释了，在分布式数据库的改造中，选择分片的表，确定分片的字段和方式是非常重要的。在之前很多客户的实施过程中，这个过程是比较繁琐的。虽然通过用户培训，可以理解原理并上手设计，但在实践中仍然很难在复杂的运行环境中找到重点，并在众多可能的选择中做出最佳选择。为了解决以上问题，我尝试通过工具来解决以上痛点，降低迁移难度，减少工作量。其原理是以运行环境中的SQL作为输入，通过解析SQL语句找到核心业务对象和使用方法；然后关联数据字典提取数据特征，让设计者可以快速做出选择，不会遗漏重要信息。下面根据该工具的输出进行简单介绍，有兴趣的可以私聊我。1).输出解释概览信息这部分主要是概览信息，主要包括数据库和分析语句。此部分收集数据库信息。目前支持MySQL，其他数据库可以扩展支持。这部分用于分析SQL文本。根据输入，可能有多个条目。设计参考这部分是根据输入的SQL语句提取表。根据数据字典信息提取表统计信息。这里我们需要关注表的大小。如上所述，表大小分片设计的考虑因素之一。小型餐桌可设计成单人餐桌或广播餐桌。这部分是根据数据表提取索引信息。这些原始的索引设计可以作为后续分片设计的参考之一。另外，在分片的情况下，索引成本太高，也可以根据这个信息做一个trade-off设计。这部分根据SQL语句的解析结果提取关联或过滤谓词；进一步展示谓词周围的字段和字段数据特征。这些提取出来的字段可以作为片键字段选择的重要参考。它对应的数据类型，是否为空，基数，使用它的谓词，可以方便设计者快速决策。2).使用建议的工具来使用，按照以下步骤：提取业务SQL。可以通过系统日志、数据库日志等方式提取业务SQL，作为工具输入。提取的SQL需要真实反映线上情况，不遗漏重要的业务SQL。分析业务S??QL。通过工具分析提取SQL，得到输出报表。辅助设计。得到报告后，可以根据数据量定位到要分片的表；根据表字段和谓词字段确定shardingkey的范围；根据以往的信息和指标做出初步的设计决策。验证设计。根据初步设计结果，在分布式环境中对上述设计进行验证，判断是否满足上述语法、语义和性能要求。3).增强和改进此工具。目前，只考虑SQL文本。未来可以增加捕获运行时信息的能力，更准确地描述业务负载。从以上信息中对不同的句子进行加权，为后续的设计判断提供更丰富的依据。
