当前位置: 首页 > 工具软件 > CockroachDB > 使用案例 >

CockroachDB架构——存储层

夏华藏
2023-12-01

CockroachDB架构的存储层对磁盘数据进行读写。
--注意:
1)如果您还没准备好,我们推荐您阅读架构概览。

一.概览
每个CockroachDB节点包含至少一个store,其在节点启动时指定,其是CockroachDB进程在磁盘上读写数据的地方。
数据通过RocksDB以键值对存储于磁盘,RocksDB主要以黑盒API被处理,每个store包含两个RocksDB实例:
1)一个用于存储临时分布SQL数据。
2)一个用于节点上的所有其他数据。
此外,还有一个块缓冲在一个节点的所有stores间共享。这些stores反过来拥有范围副本的集合。一个范围的多个副本从来不会放在相同store上或者甚至同一个节点上。
1.与其他层的交互
CockroachDB中,存储层与其他层的关系如下:
1)从复制层进行成功的读写。

二.组件
1.RocksDB
CockroachDB使用RocksDB——一个嵌入式键值store——对磁盘数据进行读写。您能在RocksDB Basics GitHub页上发现更多的信息。
RocksDB与CockroachDB集成的很好主要有以下几个原因:
1)键值store,其简化了到我们键值层的映射。
2)原子写批和快照,其给我们一个事务子集。
底层RocksDB引擎通过前缀压缩保证了键值的高效存储。
2.MVCC
CockroachDB很大程度上依赖于多版本并发控制(MVCC)来处理并发请求和保证一致性。这其中很多工作通过使用混合逻辑时钟(HLC)时间戳来区分数据的版本,跟踪提交时间戳,及表示一个数值的垃圾收集过期时间。所有这些MVCC数据都被存储于RocksDB中。
不管存储层的实施,MVCC数值广泛用于强制事务层的一致性。例如:CockroachDB维护一个时间戳缓冲,其存储键值最近被读的时间戳。如果写操作发生的时间戳比该读时间戳缓冲中的最大值还小,其表示有一个潜在的异常,且该事务必须以更晚的时间戳重新开始。
1)时间旅行(Time-travel)
像在SQL:2011标准中描述的,CockroachDB支持时间旅行查询(通过MVCC开启)。
为了做到这点,所有的模式信息背后也有一个类MVCC模型。这让您执行SELECT...AS OF SYSTEM TIME,且CockroachDB使用当时的模式信息来定制查询。
使用这些工具,您能从数据库获得早至垃圾收集时间的一致性数据。
3.垃圾收集
CockroachDB定期对MVCC数值进行垃圾收集以减少磁盘上存储数据的大小。为了做到这点,当一个时间戳比垃圾收集时间更早的新MVCC值出现时,我们将对旧的MVCC数值进行压缩。垃圾收集时间能在集群、数据库或表级别通过配置gc.ttlseconds复制区域变量进行设置。复制区域相关的更多信息,请参考配置复制区域。
1)保护时间戳
从v20.1开始,垃圾收集仅对不被保护时间戳覆盖的MVCC数值进行。保护时间戳子系统是为了确保依赖于历史数据操作的安全,像:
a)导入(Imports),包括IMPORT INTO。
b)备份。
c)数据更新捕获(CDC)(又名改变输送(changefeeds))。
d)在线模式改变。
保护时间戳确保开启较短GC TTL时历史数据的安全。较短GC TTL意味着更少的MVCC数值被保留。 这也许有助于降低全天频繁更新数据行负载的查询执行成本,因为,SQL层必须扫描之前的MVCC数值来发现一个数据行的当前数值。
a)保护时间戳的工作原理
保护时间戳通过创建保护记录进行工作,这些记录存储于内部系统表中。当长期运行的类似备份的作业想保护某个时间戳的数据不被垃圾收集时,其创建一个与数据和时间戳相关的保护记录。
成功创建保护记录后,时间戳小于或等于保护时间戳的特定数据的MVCC数值不会被垃圾收集。当创建保护记录的作业完成其工作后,其将移去该记录,允许垃圾收集器对先前保护的数值进行垃圾收集。

三.与其他层的交互
1.存储和复制层
存储才能从Raft日志向磁盘提交写,也将请求的数据(即,读)返回复制层。

四.个人观点
1)很多NewSQL分布式数据库几乎都用了RocksDB,这个多说。
2)分布式数据库来讲,存储层不可或缺,虽然,很多都用了RocksDB,但实现机制大同小异。

 类似资料: