拓宽管理“瓶颈”—— CirroData系统表的优化
数据库的系统表用来存放结构元数据，通过对元数据实现“增、删、改、查”等操作实现对数据库管理系统的控制。可以说系统表就是数据库的“总目录”，如果对系统表的操作和维护效率低下，则会成为整个数据库管理系统的性能“瓶颈”。
本篇介绍了传统系统表设计存在的问题，并详述了CirroData分布式数据库在系统表设计上所做的优化改进，从而大大提高了整个系统的管理效率。
数据库的系统表用来存放结构元数据，有两方面的功能：
数据库元数据的存储管理；
通过结构化的组织方式为数据库用户、管理员等提供数据库元数据的可视化视图，方便管理数据库。
CirroData借鉴Unix系统中一切皆文件的设计思想，将各种元数据当作普通的数据库表来进行设计与实现。目前实现了database，table, schema, index，cluster等几十张系统表。
本篇中CirroData的优化涉及系统表查询计划的执行，包括系统表数据的存储和扫描。
如上图所示，CirroData系统表数据扫描分三个模块，数据扫描层、计算层和存储层。
数据扫描层负责下发数据扫描指令给计算层并将计算层读取的数据返回给数据扫描层的调用者执行器。
计算层负责对从存储层读取的数据进行格式转换，过滤。
存储层负责存储系统表的数据，并对外提供Read/Write/Delete功能。
如上图所示，系统表中的计算层由三个模块组成，分别是Filter、Convertor、Read模块组成。具体如下：
Read模块负责读取存储在HDFS中的元数据并组成全列的RowData行数据。
Convertor层负责将RowData数据转换成内存存储格式(MDP)的系统表数据。
Filter层将Convertor层传入的MDP数据进行行和列过滤以去除冗余数据，并将终所需数据传递给Scan层。
存储层采用HDFS文件系统进行系统表数据的存储，每条元数据以单个文件的形式存储在HDFS上。如下图所示：
1、IO性能问题
如上图所示，每条元数据在HDFS以单个文件进行存储，这样一张系统表的扫描会涉及多个文件数据的读取，会产生大量的IO操作，而对性能产生负面影响。
2、串行化计算的性能问题
如上图所示，数据是全量地在各个层流动，这会导致各当前层需要等待其下层将全量数据读取或计算好才会开始运行。这就产生了各层运行串行化计算导致的性能问题。
3、冗余计算问题
如图所示，计算层中Convertor需要将Read的RowData形式的全列系统表转换为MDP格式的内存格式的系统表数据。如果能直接Read出MDP格式的数据就没必要进行Convertor这个冗余操作。Filter需要接收全行及全列的数据并对其进行过滤。但Scan所需仅是目录列及部分行数据，因而对除目标列外其它数据的读取及计算是冗余的。
4、 开发维护问题
如上图中红色框部分，现有实现将数据的读取及业务层功能的实现集中于GetAllDB等接口中，违反了功能单一的原则，不易开发维护。
1、 IO性能问题优化
如上图所示，针对IO性能问题，本次优化采用分布式Key-value 存储技术。将系统表数据存储至KVStore。这样多条同类型的元数据存储至单个kv文件中，不仅利用kv的快速定位数据位置的优点，还能避免对大量小文件的IO，提升IO性能。
2、串行化计算的性能问题
如上图所示，串行化计算的性能问题，借鉴计算机指令级并行的流水线思想，将全量数据拆分为多个部分，进行流水线式的计算达到各层的运算并行化，从而提高各层的吞吐量，达到提升性能的目的。
3、冗余计算问题优化
本次优化了存储层与计算层的接口，将kvstore读取出的数据格式设计为MDP，避免了数据格式转换所带来的冗余计算开销。另外将Filter拆分为ColumnFilter 和 RowFilter，这样不仅能够利用流水线的思想提高计算效率，而且数据在经过ColumnFilter后会将多余的列数据过滤掉，减少内存的使用，达到了计算的时间和空间双重优化。
4、 系统表需求变更后实现的复杂性优化
如上图所示，借鉴将变化的部分抽取出来的设计思想，将数据的读取及业务层功能拆分开。数据的读取功能接口中是简单而且不变的，业务层功能会随着需求的变更产生变化，拆分开。
针对kvstore,只能给定keys就获取满足条件的数据。业务层代码只需要关注于各种系统表业务的处理，达到了数据的读取与业务功能分离开，提高了模块的可维护性。
对CirroData分布式数据库系统表的优化无疑从性能和开发维护方面都显著提升了效率，拓宽了整个系统的管理“瓶颈”。在实际应用和维护中，为用户提供了更好的操作体验。
来源：https://mp.weixin.qq.com/s/rd8Uga4vT0ShsQrj92F2DA
相关文章