炫“库”行动-人大金仓有奖征文—关于分布式分析型数据库KADB实际应用中的行列分区混存策略

炫“库”行动-人大金仓有奖征文—关于分布式分析型数据库KADB实际应用中的行列分区混存策略

【本文正在参与炫“库”行动-人大金仓有奖征文】
活动链接：https://bss.csdn.net/m/topic/kingbase

引言

随着时代的发展，信息化的普及，人类迎来了史无前例的数据大爆发时代，鉴于数据量的庞大，对于数据的分析及应用也就变得尤为重要。分析型分布式数据库应运而生。但其实早在2013年，人大金仓就已经开始进行对MPP（massively parallel processing）数据库进行了研发并参与了众多项目，在海量数据管理上积累了一定的经验。

概述

在数据库中其实是没有行列分区混存的概念。但在实际应用中，行存和列存各有优势，如何取舍是个令人头疼的问题。在此我分享的是实际生产中采用的一种分区混存的设计。

行存储

行存储的应用非常广泛，像我们熟知的Oracle、MySQL和MongoDB采用的都是行存储模式。行存储模式顾名思义是将数据完整的存储在一个文件中的，这种存储模式的优势很显著，由于一条数据只存入一次所以写入效率很高，再加上KADB自身的分布式架构，面对大规模批量导入的性能是相当优秀的。

列存储

列存储模式的应用场景有一定的局限性，比如列存储需要将一条数据拆分成多个值进行保存，这就会导致导入效率有所降低。但列存储也有自己的优势所在，当我们面对宽表（超过100个字段）的时候，由于磁盘读写时只需要打开对应查询列的文件，列存储在查询上面相较于行存储有一定的优势；而且在列存储中，对于字段的压缩也有助于磁盘空间的管理和冷数据处理。

实际生产设计

在某项目中，用户共有五台服务器，一台作为管理节点，四台数据节点（如图一），磁盘空间共（4*17T）/2=34T（一主一备，故除2）。

日增量约10G/天，出于对磁盘空间和查询使用的考虑，最终决定使用列分区存储支撑该项目。经过将近五年的使用历史数据的堆积，再加上表膨胀、块碎片过多等因素导致我们无法将最大的数据表进行重构，由于日增量的增加导入效率已经无法满足用户使用需求，我们不得不另寻出路。因为之前使用的是列存表，所以第一个想到的便是通过列改行的方式加快导入速度。具体实现步骤如下

创建字段相同行存表

CREATE TABLE heap_xxx_202110 (like col_xxx_202110) with (APPENDONLY=true,ORIENTATION=row);

替换原分区表中列存子分区表

ALTER TABLE XXX EXCHANGE PARTITION FOR ('20211001') with TABLE col_xxx_202110;

导入已存在数据

INSERT INTO XXX SELECT * FROM col_xxx_202110;

删除被置换的列存子分区表

DROP TABLE col_xxx_202110;

至此我们便将2021年10月的子分区表从列存改为了行存，当然了，导入已存在的数据一般无需执行，因为实际生产中我们会提前建立行存子分区进行替换；但当月过后，我们需要将数据进行压缩时（将此法反向炼制即可），则必须执行导入已存在数据这一步。

结语

虽然方法看起来笨了些，但却实际解决了用户的痛点，还是有一定的意义的，在此分享给大家，欢迎大家提出问题，共同进步~

【本文正在参与炫“库”行动-人大金仓有奖征文】
活动链接：https://bss.csdn.net/m/topic/kingbase