在所有的数据系统中,都会存在“冷数据”,它们被查询的次数相对没有那么频繁,也很少被修改,但却是稳定运行IT 系统中数据量的主要部分,因此必不可少。
但是随着时间的推移,如果继续将这些“冷数据”与频繁修改、点查的数据放在同一环境中进行同等处理,无疑会大大浪费系统资源,单个数据库的容量上限还可能会限制数据的存储。可若将“冷数据”定期归档到更经济的存储介质中,访问数据时采用从归档数据中还原的方法,又会对历史数据的查询性能和系统的复杂度带来负面影响。
面对此番境况,为了实现降本增效,越来越多的系统将数据分为线上库和历史库,并将在线数据定期同步到历史库,通过在存储和计算成本更低的环境上部署历史库来降低成本和满足业务需求。
“历史库”模式提出的新需求
虽然相比之前,这种“历史库”的模式能够在降低成本的同时保证业务需求,但其也对数据库管理系统带来了新的需求,主要包括以下几点:
第一,数据库需要拥有大容量的存储空间,即能够支持大量数据的存储和在线库数据高效地持续导入;
第二,数据库提供更低的存储成本,即能够用更少的磁盘空间,更经济的存储介质存储更多的数据;
第三,数据库提供和在线库近似的查询性能,即支持高效的少量事务型查询,同时能够支持高效的分析型查询;
第四,数据库支持低频率的历史数据更新;
第五,数据库对应用和在线库保持相同的访问接口,降低应用复杂度。
想要满足上述需求,并不简单,而OceanBase因为拥有良好的单机分布式扩展能力,支持 HTAP 混合负载处理能力,能够同时高效地支持业务系统的在线库和历史库场景,因此被众多用户选择。更重要的是,OceanBase可以在支持业务的同时至少降低一半的存储成本,据用户反馈,业务历史库从其他数据库迁移至 OceanBase 后,存储成本降低 80% 左右。
OceanBase降本增效背后的原因分析
那么,OceanBase为什么能实现这样的降本增效?。这和它的 LSM-tree 存储引擎和数据库压缩功能密不可分。
一方面,作为一款 HTAP 数据库产品, OceanBase 使用基于 LSM-Tree 架构的存储引擎,同时支持 OLTP 与 OLAP 负载,这种存储架构提供了优秀的数据压缩能力。在 OceanBase 中,增量数据会写入 clog 和 memtable 中, OceanBase 的 memtable 是内存中的 B+ 树索引,提供高效的事务处理能力。memtable 会定期通过 compaction 生成硬盘持久化数据 sstable ,多层 sstable会采用 leveled compaction 策略进行增量数据重整。sstable 中数据块的存储分为两层,其中 2M 定长的数据块(宏块)作为 sstable 写入 I / O 的最小单元,存储在宏块中的变长数据块(微块)作为数据块压缩和读 I / O 的最小单元。
在这样的存储架构下, OceanBase 的数据压缩集中发生在 compaction 过程中 sstable 的写入时,数据的在线更新与压缩得到了解耦。批量落盘的特性使其采用更激进的压缩策略。OceanBase 从 2.0 版本开始引入了行列混存的微块存储格式( PAX ),充分利用了同一列数据的局部性和类型特征,在微块内部对一组行以列存的方式存储,并针对数据特征按列进行编码。变长的数据块和连续批量压缩的数据也可以让OceanBase 通过同一个 sstable 中已经完成压缩的数据块的先验知识,对下一个数据块的压缩进行指导,在数据块中压缩尽量多的数据行,并选择更优的编码算法。
可以说,OceanBase 之所以能够在事务性能和压缩率之间取得更好的平衡,都得益于 LSM-Tree 的存储架构。
另一方面,OceanBase 同时支持不感知数据特征的通用压缩 ( compression ) 和感知数据特征并按列进行压缩的数据编码 ( encoding )。这两种压缩方式是正交的,也就是说,可以对一个数据块先进行编码,然后再进行通用压缩,来实现更高的压缩率。
而通用压缩的优点是对被压缩的数据没有任何假设,任何数据都可能找到模式并压缩,但往往出于平衡压缩性能和压缩率的考虑,通用压缩算法会放弃对一些复杂数据冗余模式的探测和压缩。对于关系型数据库来说,系统对数据库内存储的结构化数据有着更多的先验知识,利用这些先验知识可以对数据进行更高效的压缩。
OceanBase存储引擎的数据库压缩功能在不降低事务型负载性能的同时降低存储空间和存储成本,同时提升分析型负载的性能。高度压缩的数据既能够帮助历史库数据降低至少 50% 的存储成本,高效的写入查询和统一的配置接口又能够帮助业务增效。也正是基于这些特点,才让越来越多的企业开始在历史库场景使用 OceanBase 进行降本增效的实践。
领取专属 10元无门槛券
私享最新 技术干货