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

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

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

引言

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

概述

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

行存储

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

列存储

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

实际生产设计

在某项目中,用户共有五台服务器,一台作为管理节点,四台数据节点(如图一),磁盘空间共(4*17T)/2=34T(一主一备,故除2)。
炫“库”行动-人大金仓有奖征文—关于分布式分析型数据库KADB实际应用中的行列分区混存策略_第1张图片
日增量约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

你可能感兴趣的:(KADB,big,data,数据库,分布式存储)