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


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信息的捕获能力,可更为准确描述业务负载。从上述信息中增加对不同语句权重,为后续设计判断提供更为丰富的依据。