来自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存储
恕我直言：这个测试我感觉不好😅
既没有测试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的工作原理
3.2 Authentication & Security
Transparent authentication
透明化各家的认证系统
AnyBlob enables encryption-at-rest
推荐encryption-at-rest方案
静态数据加密的工作原理
- 数据加密：
- 数据在写入磁盘之前被加密。
- 常用的加密算法包括 AES（Advanced Encryption Standard）。
- 加密密钥由专门的密钥管理系统（KMS，Key Management System）管理。
- 数据解密：
- 数据在从磁盘读取到内存时被解密。
- 只有持有正确密钥的系统或用户才能访问解密后的数据。
- 密钥管理：
- 密钥的保护至关重要。如果密钥被泄露，攻击者可以解密数据。
- 通常，密钥存储在专用的硬件安全模块（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, TDE TLS, HTTPS, VPN SGX, 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
列式存储
下面这张图主要关于元信息存储
4.2 Table Scan Operator
很多操作都还是Umbra原样
Scan design preliminaries.
Morsel picking.
Worker jobs.
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