技术名称
Row-column mixed
storage,即行列混合存储,是指一个数据库中既有行存储结构,又有列存储结构,两种存储结构结合使用以提升系统的整体性能。
作用或背景
传统面向OLTP或OLAP的数据库采用单一“按行存储”或“按列存储”的存储方案,无法兼顾行、列存储格式的优势。企业往往选择多款数据库产品进行组合,以支持事务处理、数据分析和日志存储等多种功能,这种组合式方案虽然解决了目前企业的应用需求,但仍存在几个固有的缺点:数据新鲜度受ETL限制,面向OLAP的数据库中存储的数据按ETL定期更新;数据冗余严重,两种系统存储数据会导致严重的数据冗余现象,增加存储空间;两种独立系统的使用与维护开销较大,需解决复杂的ETL数据迁移,数据转换与数据一致性等一系列问题。
技术源头
行列混合存储技术最早源于Natassa Ailamaki、David DeWitt、Mark Hill 和 Marios Skounakis在2001年发表的论文《Weaving Relations for Cache Performance》,论文中提出PAX(Partition Attributes Across)方案,是一种典型的先按行分组再按列存储的混合型实现,不过该技术实际很少使用。
2002年Ravi Ramamurthy、David DeWitt 和 Qi Su发表论文《A Case for Fractured Mirrors》提出 Fractured Mirrors方案,其核心理念是往存储引擎中写数据的时候写两份,一份数据用 NSM(行存)的存储格式,另一份用 DSM(列存)的存储格式,然后根据业务的不同访问不同存储格式的数据。
国外技术现状
国外行列混合存储数据库主要采用同一个引擎不同的数据存储格式,即数据在磁盘上只存储一份,数据加载到内存中时为其生成一份列存结构,此种方式并不是把行存数据在内存中重新复制一份,增加的内存开销不是很大,比如Oracle列存结构的内存开销大约在20%。目前主流行列混合数据库还是只能在行存上进行数据更新,通过内部数据合并机制把数据同步到列存。
国内技术现状
国内行列混合存储数据库技术实现上以行列数据分开不同的表存储和分布式多副本为主。华为 openGauss、腾讯 TDSQL-A 、达梦等数据库中用户可以根据应用场景在建表的时候选择行存储还是列存储表,表创建好后存储类型不能修改,不同存储类型的表可以做 join 查询;GBase 8a MPP 数据库采用行存列的方式实现行列混合存储,将部分列或全部列以行存储的方式在物理上进行存储,好像一个新的独立的“列”;TiDB 将行存数据存储在TiKV中,列存数据存储在TiFlash中,通过复制Raft log的方式将更新从行存同步到列存。目前国内行列混合存储引擎的研究方向还是以在行存储引擎的基础上增加列存模块为主,数据存储格式不同带来格式转换的问题,尚缺乏成熟的混存存储引擎方案。
国外代表产品
SQL Server 2012及以后版本、Oracle 12c及以后版本、SAP HANA
国内代表产品
TiDB、openGauss、达梦
详细描述
数据库存储引擎一般采用结构化的数据存储格式,包含按行存储和按列存储两种。行存储将一条记录的所有属性列连续存放在一起,记录的所有列值可通过单次磁盘I/O写入,有利于实现高效的事务处理,而列存储通常把同一列的数据连续存储在一起,进行查询时,系统只需读取部分属性列值,避免将冗余列读入内存,能够有效优化复杂查询。
行列混合存储技术结合了行存储引擎与列存储引擎的优势,不需要把数据复制到另外的数据库系统中就可以实现在线数据分析,解决了以往需要把一份数据进行多次复制来分别进行业务交易和数据分析的问题,极大的降低了数据存储的成本。
参考文献
《基于读写分离架构的混合存储引擎》胡爽
《面向HTAP的大规模分布式数据库混合存储引擎》姚入榕
《分布式列式内存数据库事务系统的设计与实现》韩锋
《行列混合存储数据库系统的研究》孙林超
《Enhancements to SQL Server Column Stores》
《Row-Store / Column-Store / Hybrid-Store》Kevin Sterjo
https://www.oracle.com/technetwork/database/in-memory/overview/twp-oracle-database-in-memory-2245633.pdf
https://docs.pingcap.com/zh/tidb/v4.0/tiflash-overview
https://help.aliyun.com/document_detail/93776.html
https://www.modb.pro/db/153877
https://www.modb.pro/doc/31573
https://opengauss.org/zh/docs/2.0.1/docs/Technicalwhitepaper/%E6%95%B0%E6%8D%AE%E5%BA%93%E6%A0%B8%E5%BF%83%E6%8A%80%E6%9C%AF.html