Apache Cassandra SSTable 存储格式详解

2024-06-02 16:48
文章标签 详解 存储 格式 apache cassandra sstable

本文主要是介绍Apache Cassandra SSTable 存储格式详解，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

 

简介： 在 Cassandra 中，当达到一定条件触发 flush 的时候，表对应的 Memtable 中的数据会被写入到这张表对应的数据目录（通过 data_file_directories 参数配置）中，并生成一个新的 SSTable（Sorted Strings Table，这个概念是从 Google 的 BigTable 借用的）。

在 Cassandra 中，当达到一定条件触发 flush 的时候，表对应的 Memtable 中的数据会被写入到这张表对应的数据目录（通过 data_file_directories 参数配置）中，并生成一个新的 SSTable（Sorted Strings Table，这个概念是从 Google 的 BigTable 借用的）。每个 SSTable 是由一系列的不可修改的文件组成，这些文件在 Cassandra 中被称为 Component。本文是基于 Cassandra 3.11.4 版本介绍的，这个版本生成的 SSTable 由以下 Component 组成：

-rw-r--r-- 1 root root   43 May  3 11:55 md-1-big-CompressionInfo.db
-rw-r--r-- 1 root root  155 May  3 11:55 md-1-big-Data.db
-rw-r--r-- 1 root root   10 May  3 11:55 md-1-big-Digest.crc32
-rw-r--r-- 1 root root   16 May  3 11:55 md-1-big-Filter.db
-rw-r--r-- 1 root root   66 May  3 11:55 md-1-big-Index.db
-rw-r--r-- 1 root root 4866 May  3 11:55 md-1-big-Statistics.db
-rw-r--r-- 1 root root   98 May  3 11:55 md-1-big-Summary.db
-rw-r--r-- 1 root root   92 May  3 11:55 md-1-big-TOC.txt

从上面文件名可以看出，所有的 Component 都是由 md-1-big 开头的，每个文件名都是由 version - generation - SSTable Format type - Component name 组成，由 - 分割，每个字符的含义如下：

  • version：这个代表 SSTable 存储格式的版本号，目前最新的 Cassandra 3.11.4 版本为 md，其他有效的版本为 jb、ka、la、lb、ma、mb 以及 mc 等，比如 Cassandra 3.0.8 的版本就是 mc。具体参见 org.apache.cassandra.io.sstable.format.big.BigFormat.BigVersion；
  • generation：代表索引号，每次生成新的 SSTable 时，这个索引号都会递增；
  • SSTable Format type：SSTable格式类型，主要有两种 BIG 和 LEGACY，但是他们的名字都是 big；
  • Component name：代表当前文件存储的信息类型，比如 Data 代表存储的是用户实际写入的数据；Index 代表存储的是索引数据等。当前版本的 Cassandra 组件有 Data.db、Digest.crc32、CompressionInfo.db、Summary.db、Filter.db、Index.db、TOC.txt 以及 Statistics.db。

上面这些组件共同构建 SSTable，每种文件存储不同类型的数据，本文就是来介绍这些文件的作用以及文件之间的关联。

md-1-big-Data.db、md-1-big-Index.db 以及 md-1-big-Summary.db 文件介绍

md-1-big-Data.db

从名字就可以看出，md-1-big-Data.db 是存储用户插入到 Cassandra 对应表中数据的，这个文件的数据存储格式我们在 《Apache Cassandra 数据存储模型》 这篇文章中已经详细介绍了。

为了有个更直观的了解，假设我们有一张名为 iteblog_test 的表，建表语句和导入数据的语句如下：

create table iteblog_test(username text, type text, email text, age text, cril text, briday text ,PRIMARY KEY(username, type));insert into iteblog_test(username, type, email) values ('iteblog', '456', 'wyphao.2007@163.com');
insert into iteblog_test(username, type, email, age) values ('iteblog', '123', 'hadoop@spark.org', '99');
insert into iteblog_test(username, type, briday) values ('cassandra', '246', '2019-04-29');

我们对这张表执行 flush 操作，这时候底层生成的 md-1-big-Data.db 内容如下：

00000000  87 00 00 00 f2 00 00 07  69 74 65 62 6c 6f 67 7f  |........iteblog.|
00000010  ff ff ff 80 00 01 00 fb  3d 04 00 03 31 32 33 1a  |........=...123.|
00000020  15 90 86 02 08 02 39 39  08 10 68 61 64 6f 6f 70  |......99..hadoop|
00000030  40 73 70 61 72 6b 2e 6f  72 67 04 00 03 34 35 36  |@spark.org...456|
00000040  18 21 00 03 08 13 77 79  70 68 61 6f 2e 32 30 30  |.!....wyphao.200|
00000050  37 40 31 36 33 2e 63 6f  6d 01 00 09 63 61 73 73  |7@163.com...cass|
00000060  61 6e 64 72 61 58 00 f0  08 32 34 36 12 17 e0 24  |andraX...246...$|
00000070  4d 75 05 08 0a 32 30 31  39 2d 30 34 2d 32 39 01  |Mu...2019-04-29.|
00000080  ac b6 4c 9c                                       |..L.|
00000084

从最后边那列可以看出，md-1-big-Data.db 文件存储了用户插入到 iteblog_test 表的数据，并且同一个 Partition Key 以及静态列（如果有）只会在同一个 SSTable 中存储一份；Partition Key 相同的行对应的 Clustering key 是有序排序的。比如上面 Partition Key 为 iteblog 对应了两行数据，他们在 md-1-big-Data.db 文件是按照字符串的字典顺序升序排序的。关于 md-1-big-Data.db 文件的底层存储格式可以参见 《Apache Cassandra 数据存储模型》 的说明，这里就不再详细介绍了。

md-1-big-Index.db

SSTable 对应的 md-1-big-Data.db 可能会很大，为了加快查询速度，Cassandra 对 md-1-big-Data.db 文件中的每个 Partition Key 建立了相关索引数据，这个就是 md-1-big-Index.db 文件的作用了。md-1-big-Index.db 文件存储的内容其实很简单，存储的是 Partition Key 及其在 md-1-big-Data.db 文件中的起始偏移量。

md-1-big-Summary.db

如果 md-1-big-Index.db 文件也很大，也可能会影响查询速度。所以 Cassandra 引入了 md-1-big-Summary.db 文件，对索引文件 md-1-big-Index.db 进行抽样。具体过程为：每隔 128 （这个数由 DEFAULT_MIN_INDEX_INTERVAL 决定，好像不可以配置）个 Partition Key 就将对应的 Partition Key 及其在索引文件中的起始偏移量写入到 Summary.db 文件中去。同时，Summary.db 文件最后面还会存储 md-1-big-Index.db 文件中的起止 Partition Key。

这三个文件的关系

前面已经简单介绍了这三个文件的作用，为了直观的表示这是三个文件的关系，我这里画了一张图，帮助大家理解。
Apache Cassandra SSTable 存储格式详解
注意：上面的 iteblogxxx 代表的是 Partition Key，并且假设这些 Partition Key 对应的 hash token 是升序的。

md-1-big-Statistics.db

包含有关 SSTable 的统计元数据的文件。主要包含当前 SSTable 的：

  • 最大最小 token 的值及对应的 Partition Key；
  • Partitioner，默认为 org.apache.cassandra.dht.Murmur3Partitioner，和 Bloom Filter FP chance，主要用于校验 SSTable，在读取 Data.db 之前会先被读取；
  • SSTable 元数据，比如 SSTable 最大最小的时间戳、最大最小 local deletion time、最大最小的 TTL、SSTable 文件的压缩率、行数、列个数以及最大和最小的 ClustringValues，如果为空这保存为 0 等等
  • Partition Key 的类型；
  • Clustering Key 的类型；
  • 静态列的名字及类型；
  • 正常类的名字及类型；
  • Clustering Key 的类型；

md-1-big-CompressionInfo.db

存储 SSTable 的压缩相关的信息，包括使用的压缩算法的名字（LZ4Compressor，SnappyCompressor 和 DeflateCompressor，SSTable 的压缩算法可以在创建表的时候通过 WITH compression = {'sstable_compression': 'SnappyCompressor' 设置，默认为 LZ4Compressor），压缩算法的配置选项，chunkLength（默认为 65536），未压缩数据的长度，chunk 的个数等相关的信息

md-1-big-Filter.db、md-1-big-Digest.crc32

md-1-big-Filter.db

存储 Partition Key 布隆过滤器相关的信息，这个文件会被加载到内存，在查询的时候可以确定某行数据是否在这个 SSTable 中，减少访问磁盘的次数。

md-1-big-Digest.crc32

这个文件存储的仅仅是数据文件的 CRC 校验码信息。

md-1-big-TOC.txt

这个文件主要存储 SSTable 的 Component 名字，所以我们打开这个文件可以看到如下的内容：

  • Statistics.db
  • Digest.crc32
  • Data.db
  • Filter.db
  • CompressionInfo.db
  • Summary.db
  • TOC.txt
  • Index.db
    这个就是 SSTable 对应的八个 Component 。

这篇关于Apache Cassandra SSTable 存储格式详解的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1024537。

相关文章

Spring Security基于数据库验证流程详解

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明（认真看哦） AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证，则会调用 #attemptAuthentica
阅读更多...
异构存储（冷热数据分离）

异构存储（冷热数据分离）

异构存储主要解决不同的数据，存储在不同类型的硬盘中，达到最佳性能的问题。 异构存储Shell操作 （1）查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies （2）为指定路径（数据存储目录）设置指定的存储策略 hdfs storagepolicies -setStoragePo
阅读更多...
HDFS—存储优化（纠删码）

HDFS—存储优化（纠删码）

纠删码原理 HDFS 默认情况下，一个文件有3个副本，这样提高了数据的可靠性，但也带来了2倍的冗余开销。 Hadoop3.x 引入了纠删码，采用计算的方式，可以节省约50％左右的存储空间。 此种方式节约了空间，但是会增加 cpu 的计算。 纠删码策略是给具体一个路径设置。所有往此路径下存储的文件，都会执行此策略。 默认只开启对 RS-6-3-1024k
阅读更多...
OpenHarmony鸿蒙开发（ Beta5.0）无感配网详解

OpenHarmony鸿蒙开发（ Beta5.0）无感配网详解

1、简介 无感配网是指在设备联网过程中无需输入热点相关账号信息，即可快速实现设备配网，是一种兼顾高效性、可靠性和安全性的配网方式。 2、配网原理 2.1 通信原理 手机和智能设备之间的信息传递，利用特有的NAN协议实现。利用手机和智能设备之间的WiFi 感知订阅、发布能力，实现了数字管家应用和设备之间的发现。在完成设备间的认证和响应后，即可发送相关配网数据。同时还支持与常规Sof
阅读更多...
6.1.数据结构-c/c++堆详解下篇（堆排序，TopK问题）

6.1.数据结构-c/c++堆详解下篇（堆排序，TopK问题）

上篇：6.1.数据结构-c/c++模拟实现堆上篇（向下，上调整算法，建堆，增删数据）-CSDN博客 本章重点 1.使用堆来完成堆排序 2.使用堆解决TopK问题 目录 一.堆排序 1.1 思路 1.2 代码 1.3 简单测试 二.TopK问题 2.1 思路(求最小)： 2.2 C语言代码（手写堆） 2.3 C++代码（使用优先级队列 priority_queue）
阅读更多...
K8S（Kubernetes）开源的容器编排平台安装步骤详解

K8S（Kubernetes）开源的容器编排平台安装步骤详解

K8S（Kubernetes）是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。以下是K8S容器编排平台的安装步骤、使用方式及特点的概述： 安装步骤： 安装Docker：K8S需要基于Docker来运行容器化应用程序。首先要在所有节点上安装Docker引擎。 安装Kubernetes Master：在集群中选择一台主机作为Master节点，安装K8S的控制平面组件，如AP
阅读更多...
嵌入式Openharmony系统构建与启动详解

嵌入式Openharmony系统构建与启动详解

大家好，今天主要给大家分享一下，如何构建Openharmony子系统以及系统的启动过程分解。 第一：OpenHarmony系统构建      首先熟悉一下，构建系统是一种自动化处理工具的集合，通过将源代码文件进行一系列处理，最终生成和用户可以使用的目标文件。这里的目标文件包括静态链接库文件、动态链接库文件、可执行文件、脚本文件、配置文件等。      我们在编写hellowor
阅读更多...
LabVIEW FIFO详解

LabVIEW FIFO详解

在LabVIEW的FPGA开发中，FIFO（先入先出队列）是常用的数据传输机制。通过配置FIFO的属性，工程师可以在FPGA和主机之间，或不同FPGA VIs之间进行高效的数据传输。根据具体需求，FIFO有多种类型与实现方式，包括目标范围内FIFO（Target-Scoped）、DMA FIFO以及点对点流（Peer-to-Peer）。 FIFO类型 **目标范围FIFO（Target-Sc
阅读更多...
019、JOptionPane类的常用静态方法详解

019、JOptionPane类的常用静态方法详解

目录 JOptionPane类的常用静态方法详解 1. showInputDialog()方法 1.1基本用法 1.2带有默认值的输入框 1.3带有选项的输入对话框 1.4自定义图标的输入对话框 2. showConfirmDialog()方法 2.1基本用法 2.2自定义按钮和图标 2.3带有自定义组件的确认对话框 3. showMessageDialog()方法 3.1
阅读更多...
脏页的标记方式详解

脏页的标记方式详解

脏页的标记方式 一、引言 在数据库系统中，脏页是指那些被修改过但还未写入磁盘的数据页。为了有效地管理这些脏页并确保数据的一致性，数据库需要对脏页进行标记。了解脏页的标记方式对于理解数据库的内部工作机制和优化性能至关重要。 二、脏页产生的过程 当数据库中的数据被修改时，这些修改首先会在内存中的缓冲池（Buffer Pool）中进行。例如，执行一条 UPDATE 语句修改了某一行数据，对应的缓
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2