来自TUM的Database的论文

关键字：云数据仓库

下载链接

相关仓库

摘要选取

“远程网络和本地 NVMe 带宽之间的差距正在缩小，这使得云存储更具吸引力”

emmm，但你们想怎么解决高延迟的差距😅放到之前我也许会相信，但是今年黑5的云存储也不怎么诱人，价格并不吸引人

we present AnyBlob, a novel download manager for query engines that optimizes throughput while minimizing CPU usage.

期待（搓手手😋）

We discuss the integration of high-performance data retrieval in query engines and demonstrate it by incorporating AnyBlob in our database system Umbra

与Umbra结合，Sounds Good

Our experiments show that even without caching, Umbra with integrated AnyBlob achieves similar performance to state-of-the-art cloud data warehouses that cache data on local SSDs while improving resource elasticity.

他们想怎么比较？

正文选取

1 Introduction

In future data centers, database systems may even run on hardware that separates memory and compute.

俗称存算分离

In 2018, AWS introduced instances with 100 Gbit/s (≈12 GB/s) networking – resulting in a fourfold increase in per-instance bandwidth [22, 26].

In contrast to Infiniband, 100 Gbit/s Ethernet has not only become widely-available but also affordable

有点好奇AWS是如何实现100Gbit/s的网络的，自定义FPGA网卡必然是用上的，但不运行在Infiniband，那要怎么做？

Surprisingly, no empirical study for general-purpose analytics (OLAP) on cloud object stores has been conducted.

论文的Motivation：在云上进行OLAP还没怎么出过论文

Challenge 1: Achieving instance bandwidth. Because the latency of each object request is high, saturating high-bandwidth networks requires many concurrently outstanding requests. Therefore, a careful network integration into the DBMS is crucial to achieve the complete bandwidth available on network-optimized instances. Challenge 2: Network CPU overhead. In contrast to fetching

将网络集成到DMBS里解决高延迟问题？有意思😍

In contrast to the desire for multi-cloud systems, each cloud vendor provides its own networking library.

不同厂商的云技术很多是割裂的，但我认为K8s可以解决这个问题

Contribution 1: Experimental study of cloud object stores.

这种实验是动态的，2024年的实验不一定对2024有效

Contribution 2: AnyBlob, a low overhead multi-cloud library.

In contrast to existing solutions, our approach does not need to start new threads for parallel requests because it uses io_uring [21],

现在的数据库Paper基本都用io_uring吧😂

2 Cloud Storage Charaterstic

Methodlogy: 测AWS，Google，IBM，Azure，OCI三家公司的S3存储

image-20241123150655439

恕我直言：这个测试我感觉不好😅

既没有测试Minio这个最大的开源S3系统，也没有测Cloudflare D2这个廉价且有CDN的S3系统

选择的都是这几家的普通服务，也没有花钱看看大家云厂商是怎么优化的

2.1 Object Storage Architecture

问就是S3😆说到对象存储基本都是S3

2.2 Object Storage Cost

That‘s is a good question

Cost structure

每家都有自己的规则，都最终都会归结于存储成本和带宽成本

2.3 latency

Different request sizes

分布式存储会增大延迟，热数据会减少延迟

Noisy neighbors

高峰时间段，即使你没有高负载，你访问的延迟也会增大

Latency variations between cloud vendors.

差异不大

第二章先看到这里

2.4-2.8充斥着大量实验细节，感兴趣直接看原文

3 AnyBolb

使用异步请求减少线程带来的上下文切换（AWS的做法是每请求就通过Curl开一个线程）

3.1 AnyBlob Design

看图说话时间，但我怎么看都像是重新讲了一遍IO_Uring的工作原理

image-20241123153410899

3.2 Authentication & Security

Transparent authentication

透明化各家的认证系统

AnyBlob enables encryption-at-rest

推荐encryption-at-rest方案

静态数据加密的工作原理

  1. 数据加密：
  • 数据在写入磁盘之前被加密。
  • 常用的加密算法包括 AES（Advanced Encryption Standard）。
  • 加密密钥由专门的密钥管理系统（KMS，Key Management System）管理。
  1. 数据解密：
  • 数据在从磁盘读取到内存时被解密。
  • 只有持有正确密钥的系统或用户才能访问解密后的数据。
  1. 密钥管理：
  • 密钥的保护至关重要。如果密钥被泄露，攻击者可以解密数据。
  • 通常，密钥存储在专用的硬件安全模块（HSM）或云服务的密钥管理系统中。

实现静态数据加密的方式

静态数据加密可以在以下层级中实现：

1) 文件级别加密

  • 特定文件或目录加密。
  • 适用于操作系统或应用程序的文件系统，例如 eCryptfs 或 EncFS。
  • 适合小范围数据保护，但对大规模存储性能可能有影响。

2) 数据库加密

  • 数据库本身支持静态数据加密，例如 MySQL 的 Transparent Data Encryption (TDE) 和 PostgreSQL 的加密扩展。
  • 数据在写入数据库存储文件前被加密。

3) 磁盘/卷加密

  • 整个存储设备或卷被加密。
  • 常用工具：dm-crypt (Linux)、BitLocker (Windows)、FileVault (macOS)。
  • 优点：易于管理，对操作系统透明。
  • 缺点：加密层对所有数据一视同仁，缺乏细粒度控制。

4) 云存储加密

  • 云服务商提供的静态数据加密。
  • AWS S3 提供服务端加密（SSE），支持 KMS 集成。
  • Google Cloud Storage 和 Azure 也提供类似功能。

与其他加密技术的对比

特性静态数据加密 (At Rest)传输数据加密 (In Transit)使用中数据加密 (In Use)
数据状态存储在磁盘或数据库上网络中传输的数据在内存中被处理的数据
主要目标防止物理设备泄露风险防止中间人攻击和窃听防止运行时内存数据泄露
典型工具BitLocker, TDETLS, HTTPS, VPNSGX, Homomorphic Encryption

3.3 Domain Name Resolver Strategies

Resolution overhead.

提前缓存好不同存储节点的IP，从而避免域名解析带来的延迟

Throughput-based resolver.

启用负载均衡

MTU-based resolver.

减少或消除巨型帧，从而降低CPU拆包开销

统一各个节点的MTU量

MTU discovery.

寻找支持高MTU的路径，尽可能提高MTU量

3.4 Performance Evaluation

略

4 Cloud Storage Integregation

4.1 Database Engine Design

列式存储

下面这张图主要关于元信息存储

image-20241123163936013

4.2 Table Scan Operator

很多操作都还是Umbra原样

Scan design preliminaries.

Morsel picking.

Worker jobs.

image-20241123164419410

4.3 Object Scheduler

还是Umbra

4.4 Relation & Storage Format

还是Umbra

4.5 Encryption & Compressio

lz4和前面的encryption-at-rest

5 EXPERIMENTAL EVALUATION

略

Cloud DBMS: AWS Athena和RedShift等

Processing in the cloud: 各大云厂商的Spark和Hadoop

Spot instances(竞价实例): 研发的AnyBolb很适合这种场景

Serverless computing: 不在同一个竞争赛道

Cloud storage for DBMS: 各类数据湖（Apache Iceberg）

Memory disaggregation: 未来可期

Networking and kernel APIs：使用更快的RDMA以及Nvme SSD

4.3 Object Scheduler

总结

一个基于io_uring的Umbra数据库S3读取方案，Over