分布式数据库设计要点
1).选择分片对象
分布式数据库设计的第一个要点，就是选择需分片的对象。这其中需考虑几个问题：
数据规模
一般来说，选择分布式数据库的常见原因之一就是原有数据库容量不足，通过分布式架构存储更多的数据。因此，大数据量的表是优先采用分片设计的首要理由。当然，也存在些特例情况，如表虽然规模很大，但无法明确使用到部分数据或数据不经常使用等，也可考虑使用数据分析或大数据平台。
热点表
还有一种常见的的情况是表虽然不大，但非常热，在单机或集中式架构下成为热点，存在性能扩展的瓶颈。这种情况下，也适合采用分片方式将其分而治之。
管理需求
第三种情况是有些表有着管理需求，如归档、清理、备份等，也可以通过分片设计更精准地满足此类需求。
误区：所有表都需要分片
在分布式数据库下，是否是所有对象都需要分片呢？答案是否定的。当表采用分片化设计后，在享受到分片带来的收益的同时，势必也会有损失。如数据库约束会受到限制、数据表访问存在约束、数据库结构变更更为复杂等。因此，在分布式数据库下仍可考虑采用“单表”设计。此时，就需要考虑如存储位置（单片或广播）等。
2).选择分片键
当确定了哪些表采用分片设计后，后面的问题就是确定每个表的分片键如何选择？这往往也是分布式改造中最难取舍的地方。因为，分布式数据库下，数据只能按照一种方式分布。数据分布的方式主要就是由分片键字段和选择的分片算法来确定。因此，选择一个最具有代表意义的字段最为分片键尤为重要。而选择依据主要是看表是如何被访问的及字段的数据特征，根据多种因素综合考虑。当表按照某种分片逻辑拆分后，其他无法使用该拆分逻辑进行的访问又该如何处理呢？这是可考虑如异构二级索引、冗余对象等方式来解决了。下文介绍的小工具，就是从SQL语句的角度分析潜在的划分依据，供设计者参考。后面将详细展开说明。
3).关联对象设计
当表确定了分片方式后，其关联对象需同步进行设计。这里面设计包括：
约束
在分布式架构下，传统的约束会受到很大限制，这其中包括主键、外键、非空、唯一、检查五类。很多分布式数据库不再支持上面这些约束中的部分。这时就需在设计时有所考虑，将约束能力上移到应用侧去解决。
索引
索引，是优化数据库访问最常用的手段之一。在分布式架构下，索引能力同样有所限制。一般来说，若索引字段前缀包含分片字段，还可以支持；否则，只能通过异构索引方式来实现。可简单理解为，分布式架构下的索引就是按照另一种方式存储的分片表。当然，过多的索引在分布式架构下，开销也是很大的。因此，因分布式架构下分片内的数据已经有限，某些索引是可以考虑不再创建。
序列
序列，主要是为了满足唯一性或自增类需求的。这一能力在单机或集中式架构下比较简单，在分布式架构下通常可考虑用“分布式ID”的方式实现。功能上较之前还是有所限制，特别是自增需求。有些分布式数据库虽然支持，但性能也会较差。
视图
一般来说，分布式数据库支持简单视图，对于复杂视图来说则各有差异。此外，需要注意的是优化器的差异。针对视图类的优化，是比较考验优化器能力的，这点各家产品差异较大。
库内计算（存储过程、函数、触发器等）
针对库内计算，是单机或集中式数据库的一大优势。离数据越近的运算，其效率往往也越高，但对于分布式数据库，存在较大技术难点。目前行业内，能较完美地支持分布式架构下的库内计算，尚有不小的差距。建议还是在应用侧去解决。
4).关联语句验证
在做好上述分片设计后，很重要的一步就是要验证上面设计是否满足需要。验证的方式就是将对象关联的语句提取出来，分析在分布式条件下的运行情况。这里包括语法是否支持、语义是否等价、效率是否有保障？若上述验证不满足预期，就需要考虑做出调整。有些可通过改写方式解决，有些更为复杂情况可能需考虑在应用侧甚至架构层面来解决。这一过程也是很多分布式改造的痛点，存在大量验证过程。
5).其他需考虑因素
除去上述要点外，还有其他因素值得关注：
分区表情况
在传统数据库中，应对海量数据规模的有效手段之一就是分区。是否在分片条件下仍然使用分区，是需要综合考虑的。原则上来讲，数据经过分片设计，已经减少处理规模，分区必要性有所降低，要综合考虑。
复杂计算情况
分布式架构下，有些计算是无法下推到分片内完成的，这就需要提取分片数据，汇聚后计算。这对于上面的计算层的压力较大，也会造成很大的资源开销。这点要关注到分布式数据库的处理逻辑，验证其这方面能力如何。
数据分析需求
针对数据分析类需求，很多分布式数据库考虑到这点，引入诸如HTAP方向的技术能力来解决。有此类需求的场景，需重点验证。
工具实践：分片设计辅助分析
如上面阐述，在分布式数据库改造中，选择需分片的表、确定分片字段及方式是非常重要的环节。之前在不少客户实施过程中，这一过程较为繁琐。虽然通过用户培训，能够了解原理上手设计，但在实操中如何从纷繁复杂的运行环境中找到要点，在众多可能选择中选出相对较优仍比较困难。为解决上述问题，自己尝试通过工具解决上述痛点，降低迁移难度、减少工作量。其原理是以运行环境中SQL为输入，通过解析SQL语句，找到业务核心对象及使用方式；再关联数据字典提取数据特征，方便设计者快速做出选择且不遗漏重要信息。
使用建议
工具使用上，可依据如下步骤：
提取业务SQL。可通过系统日志、数据库日志等，提取业务SQL，作为工具输入。提取的SQL需真实反应线上情况，不遗漏重要的业务SQL。
分析业务SQL。通过工具分析提取SQL，获取输出报告。
辅助设计。得到报告后，可根据数据量定位待分片表；根据表字段及谓词字段，确定分片键的范围；根据前面信息和索引，做出初步的设计决策。
验证设计。根据初步的设计结果，在分布式环境下验证上述设计，判断是否满足之前提到的语法、语义及性能。
增强改进
这一工具，目前仅考虑到SQL文本，未来可增加对runtime信息的捕获能力，可更为准确描述业务负载。从上述信息中增加对不同语句权重，为后续设计判断提供更为丰富的依据。
中嘉和信北京机房以康盛机房、亦庄国际机房、四季青机房为主，作为互联网数据中心集成服务领域的标杆企业，中嘉和信一直以客户需求为导向，以技术创新为驱动，以服务质量为保障，学习创新，合作共赢，持续为客户提供更加优质的产品和服务，陪伴客户共同成长，助力客户实现梦想。如有业务需求请拨打010-51265666进行咨询，欢迎预约参观机房！
文章来源：互联网，如有侵权联系删除！
