数据库存储

数据库存储是指将数据持久性地存储在计算机系统中，以便后续检索、查询和管理。数据库系统使用不同的存储引擎和结构来组织和管理数据，如关系型数据库使用表格结构，文档数据库使用文档格式，图数据库使用图结构等。存储数据的目的是确保数据的安全性、可靠性和高性能访问。

数据库存储架构

OceanBase 数据库的存储引擎基于 LSM-Tree 架构，将数据分为静态基线数据（放在 SSTable 中）和动态增量数据（放在 MemTable 中）两部分，其中 SSTable 是只读的，一旦生成就不再被修改，存储于磁盘；MemTable 支持读写，存储于内存。数据库 DML 操作插入、更新、删除等首先写入 MemTable，等到 MemTable 达到一定大小时转储到磁盘成为 SSTable。在进行查询时，需要分别对 SSTable 和 MemTable 进行查询，并将查询结果进行归并，返回给 SQL 层归并后的查询结果。同时在内存实现了 Block Cache 和 Row cache，来避免对基线数据的随机读。

数据库存储数据

在 OceanBase 数据库的存储视角看，存储结构里最上层是 Partition Group，对应一个分区组，很多时候我们也将其简称为 PG。PG 是一个为了取得极限性能而抽象出来的一个概念。我们知道在一个用户的事务中，可能会操作很多张不同的表，在 OceanBase 数据库的分布式架构下，很难保证这些不同的表在相同的服务器上，那么这就势必会带来分布式事务，而分布式事务是依赖两阶段提交的，会有更大的开销；如果这些不同的表都在相同的服务器上，我们就有可能对这个事务做一阶段优化，以取得更好的性能。但大多数情况下，对表的位置其实是没有办法保证的。对于互联网下的很多应用，我们发现业务都会根据 User Id 做表的分区，并且多张表的分区规则都是相同的，对于这些表我们提供了语法来构建 Table Group，对于 Table Group 中的相应分区我们称之为 Partition Group，OceanBase 数据库会保证同一个 Partition Group 中的多个 Partition 始终绑定在一起，那么对于同一个 Partition Group 的事务操作就会被优化为单机事务，以取得更好的性能。

在一个 Partition Group 中可能包含多个 Partition，注意这些 Partition 的分区键和分区规则要完全相同。Partition Group 是 OceanBase 数据库的 Leader 选举和迁移复制的最小单位。Partition 就是表的一个分区，和 Oracle/MySQL 对于分区的定义基本相同。表的分区规则可能有很多种，例如 Hash 分区、Range 分区、List 分区甚至二级分区等等，但对于存储层来说，并不关心以上分区规则，都一视同仁为 Partition。

在 OceanBase 数据库中, 对于用户表支持创建局部索引，局部索引的特征就是在存储上会和主表绑定在同一个 partiton 内部存储，主表和每个索引在内部会存储在各自独立的Table Store 内，在每一个Table Store 中会包含多个 SSTable 和 MemTable。MemTable 存储于内存，存储动态数据，提供读写操作；SSTable 存储于磁盘，存储静态数据并且只读。详情参考数据存储概述。

数据库存储的转储与合并

OceanBase 数据库的存储引擎基于 LSM-Tree 架构，数据大体上被分为 MemTable 和 SSTable 两部分，当 MemTable 的大小超过一定阈值时，就需要将 MemTable 中的数据转存到 SSTable 中以释放内存，这一过程称之为转储 。转储会生成新的 SSTable，当转储的次数超过一定阈值时，或者在每天的业务低峰期，系统会将基线 SSTable 与之后转储的增量 SSTable 给合并为一个 SSTable，这一过程称之为合并。详情参考转储与合并。

数据库存储相关文章

如何降低数据库存储成本？

数据无压缩是 MySQL 的痛点之一，当企业数据量不断增加，这便成为一大问题。OceanBase 的存储引擎是基于 LSM-Tree 自研的一套高级压缩的存储引擎，它和 B+ 树不同，其写入会先放在内存，当内存写到一定程度之后，会直接转储到磁盘，然后在每天的业务低峰时间（默认是凌晨两点），将当天的所有转储整理一遍，并且压缩好放在基线 SSTable (ROS) 数据里。通过这个被称作合并的过程，LSM 树存储结构的基线数据都是无空隙的，与 B+ 树的每个页中都会有一些空隙相比，把原有没经过压缩的数据压缩到 MySQL 的 1/4 到 1/5，甚至更高的压缩比，所以 OceanBase 天然压缩比就要比 MySQL 好，从而降低数据库存储成本。

翼支付实现数据存储成本降低与数据库整体效率提升

https://open.oceanbase.com/blog/27200148

翼支付的消息中心为消息推送、微信推广、消息邮件等提供服务，底层使用 MySQL 作为存储，结合 MyCat 进行分库，使用分区表。随着数据量的不断增长，MySQL 单机磁盘使用率达到 90%，且在不断增加，底层无法扩容，同时面临分库无法平滑扩、DDL 执行缓慢、维护成本高等问题，亟须分布式数据库解决这些问题。OceanBase帮助翼支付完成从集中式架构到分布式架构转型，实现存储空间使用率大幅度下降70%以上。

如何在高性能的前提下，降低数据库存储成本？

数据压缩最终目的是降本增效，降本不能牺牲效率，因此实现高压缩比的前提一定是先保证高性能，这也是更适合用户关键业务系统的压缩方案。在2022年 5 月举行的中国国际大数据产业博览会上，OceanBase 的“高压缩比分布式存储引擎”荣获了“领先科技成果奖”。OceanBase 获奖的关键原因是这一自研的引擎创造性地解决了传统数据库无法平衡“性能”和“压缩比”的难题，本文也将分享我们对破解这一难题的思考。

分布式数据库相关方案

大存储类数据库降本解决方案

https://www.oceanbase.com/solution/large-storage

OceanBase 作为原生分布式数据库具备高压缩比特性通过分布式存储引擎摒弃了传统数据库的定长数据块存储， 采用基于 LSM-Tree 的存储引擎和自适应编码压缩技术大大降低存储成本，创造性的解决了传统数据库无法平衡“性能”和“压缩比”的难题。

冷数据归档降本解决方案

面对快速增长的在线数据，尤其在例如新零售、支付等订单和交易场景，数据往往多呈现为流水型特征，写入一段时间后即不会再次访问或更新；对访问频率很低甚至为0的数据，其占用的在线业务库固态存储空间，造成了大量硬件资源浪费，堆高企业的IT成本。OceanBase通过智能化的历史库平台工具结合数据库内核海量存储的能力，帮助企业轻松完成冷数据归档，释放宝贵的存储资源，对数据生命周期实现完整掌控。

https://www.oceanbase.com/solution/data-archive