Cloud OLTP Architectures
| OLTP Architectures | Computation | Buffer | Storage |
|---|---|---|---|
| Disaggregated Compute-Storage | One RW Primary Node + Multiple RO Secondary Nodes |
Local Cache for each Compute Node | Aggregated Log & Page Storage |
| Disaggregated Compute-Log-Storage | One RW Primary Node + Multiple RO Secondary Nodes |
Local Cache for each Compute Node | Disaggregated Log & Page Storage |
| Disaggregated Compute-Bufer-Storage | One RW Primary Node + Multiple RO Secondary Nodes |
Local Cache + Shared Remote Buffer | Disaggregated Log & Page Storage |
1 Disaggregated Compute-Storage Architecture
Motivations：
- Elasticity. 计算存储独立扩展
- Efficiency. 减少写放大（write amplification）问题
- Availability. 多层恢复机制，可处理各种 exception
Key Features：
- 计算存储分离
- Log is the database. 将日志作为存储中心，写 log，通过 log 回放。为减少因为检查点、脏页写、数据同步导致的 I/O 开销，将 redo 任务卸载到存储层。
? AWS Aurora[22]
Data write Path：
- 主节点在 local cache 中更新 local page，并生成 redo log
- 主节点将 redo log 传给云存储中的大多数节点
- 当大多数 data replicas 已完成 log 的写入后，提交写事务
Data sync path：
- 通过 log 保证 replicas 的一致性（将 log 同步到其他未同步的节点）
- 在存储节点中异步地回放 redo log 到 page
- 将 log 传到二级节点，以 page 的形式进行读
Data read path：
- 计算节点检查 local cache 是否存在数据，若存在且数据是最新的，则返回
- 若 cache miss，则计算节点会发送读请求到存储层
- 对存储层中的每个节点：若数据所在 page 是最新的，直接从该 page 中获取数据；否则从 redo log 中重放 page
- 计算节点从存储层获取数据，并在 local cache 中通过缓存替换策略更新数据，然后返回
优点：
- 更低的写延迟：写完 log 就能提交写操作，不用等待 page 在存储节点完成更新
- 减少写放大：将 log replay 下推到存储层，防止写数据时因为写 dirty page 导致的开销；共享存储架构，防止为一个分片维护多副本。
- 更优的弹性：存算分离，计算存储独立扩展
缺点：cache miss 时更高的读延迟：更新的数据可能没有被 replay 到 page，导致读数据时还需重放日志，导致额外的读延迟
2 Disaggregated Compute-Log-Storage OLTP Architecture
Motivations：
- Efficiency. 通过日志存储，提供更高的写性能
- Elasticity. 将 log storage & page storage 分离后，二者可独立扩展，提供更高的弹性机制
Key Features：将 log 存储和 page 存储分离
? Azure HyperScale、HUAWEI Taurus[7]、Socrates[2]。Socretes 将存储分为 Xlog Service、Page Servers 分别用于日志存储和页面存储，Xlog Service 将写请求持久化到日志中，Page Servers 负责处理读请求。
Data write Path：
- 主节点在 local cache 中更新 local page，并生成 redo log
- 主节点将 redo log 传给 log storage 中的大多数节点
- 当大多数 log replicas 已完成 log 的写入后，提交写事务
Data sync path：
- 从 log storage 中获取 redo logs 并发送给 page storage
- 在 page storage 的节点中异步地回放 redo log 到 page
- page storage 中不同节点的 page 可通过 gossip 协议保持一致性
- 当 redo log 在所有 page storage 节点重放完毕，log 就能在 log storage 中被删除
- 将 log 传到二级节点，以 page 的形式进行读
Data read path：
- 计算节点检查 local cache 是否存在数据，若存在且数据是最新的，则返回
- 若 cache miss，则计算节点会发送读请求到 page storage
- 对存储层中的每个节点：若数据所在 page 是最新的，直接从该 page 中获取数据；否则等待数据同步完
- 计算节点从 page storage 获取数据，并在 local cache 中通过缓存替换策略更新数据，然后返回
优点：
- 更低的写延迟：通过 log storage service，相较于 Disaggregated Compute-Storage Architecture，写操作更快
- 更优的弹性：log 存储和 page 存储分离，二者独立扩展，可以实现 cost & performance 的平衡
缺点：cache miss 时更高的读延迟：更新的数据可能没有被 replay 到 page，导致读数据时还需等待日志重放，导致额外的读延迟
3 Disaggregated Compute-Bufer-Storage OLTP Architecture
Motivations：
- Latency. 通过远程共享内存，减少读延迟
- Throughout. 使用远程共享内存池作为统一的数据结构，这样不同计算节点就能从相同的缓冲区域读取 page，从而减少不同计算节点上相同请求对读取数据的复制，实现较高的读吞吐量
- Elasticity. 内存资源与计算和存储分离，可按需动态分配
Key Features：所有计算节点共享远程弹性缓冲区
? Alibaba PolarDB Serverless[5]，使用远程共享内存的同时，通过各种技术来确保共享缓存区的数据一致性和查询性能，如 RDMA 技术、缓存失效、全局锁存器、读取视图。
Data write Path：
- 主节点在 local cache 中更新 local page，并生成 redo log
- 主节点将 redo log 传给 log storage 中的大多数节点
- 当大多数 log replicas 已完成 log 的写入后，提交写事务
- 更新 shared buffer 中的 page
Data sync path：
- shared buffer 中的 page 永远不会被写入 page storage
- 在 page storage 的节点中异步地回放 redo log 到 page
- 将 log 传到二级节点，以 page 的形式进行读
Data read path：
- 计算节点检查 local cache 是否存在数据，若存在且数据是最新的，则返回
- 若 cache miss，则计算节点检查 shared buffer 是否存在数据，若存在且数据时最新的，则从中获取数据并返回
- 若仍 cache miss，则计算结点会从 page storage 中获取数据，并在 shared buffer 中通过缓存替换策略更新数据，然后返回
- 计算节点从 shared buffer 中获取数据，并在 local cache 中通过缓存替换策略更新数据，然后返回
优点：
- 更低的读延迟：计算节点从远程内存中读取数据，比从远程存储中读数据更快
- 更高的读吞吐量：不同计算节点共享相同的远程缓冲区，减少了不同计算节点上相同请求对读取数据的复制
- 更优的弹性：内存资源与计算和存储分离，可按需动态分配
缺点：内存层的复杂网络开销：远程内存需要同时满足高网络吞吐和低延迟的需求，因此远程内存的网络将成为该数据库系统的瓶颈
Key Techniques of Cloud OLTP Databases
- Transaction Processing
- 写 log，从 redo log 中读，使用 log 进行 OLTP [22]
- 写 log，从 page server 读，page server 使用 log 和 page 进行 OLTP [7]
- 写 log，从 shared buffer 读，通过 Disaggregated Compute-Bufer-Storage OLTP Architecture 支持 OLTP [2, 5]
- Data Replication
- Quorum-based log replication [22, 23]
- Paxos-based log replication [5]
- Log-page-separated replication [7]
- Data Node Recovery
- ARIES-based recovery methods
- Non-Redo recovery methods，基于 log is the database 机制，跳过 redo 阶段
- Storage Management
- log 和 page 耦合的存储 [22]
- log 和 page 分离的存储 [7]
- log、buffer、page 分离的存储 [2. 5]
Cloud OLAP Architectures
| OLAP Architecture | Computation | Storage |
|---|---|---|
| Disaggregated Compute-Storage | Multiple Clusters with Worker Nodes |
Local Cache + Cloud Storage |
| Disaggregated Compute-Memory-Storage | Multiple Worker Nodes with Shuffle Layer |
Memory Pool + Cloud Storage |
1 Disaggregated Compute-Storage OLAP Architecture
-
Motivations：
- Elasticity. 计算存储独立扩展
- Availability. 可容忍集群和节点的故障
- heterogeneous workloads. 异构工作负载，高 I/O 带宽或高计算能力
-
Key Features：
- 计算存储分离
- Multi-tenancy and Serverless
- Elastic Data Warehouses，DWs 中的 EC2 服务器实例数目可弹性更改
- 计算节点本地 SSD 缓存热点数据
- 云存储服务，e.g., AWS S3、Google Cloud Storage、Azure Blob Storage
-
优点：(与本地无共享 OLAP 架构相比)
- 高可用：因为 (1) 跨多个可用性区域的数据复制和 (2) 可伸缩的云服务，集群和节点故障可快速恢复
- 更经济：资源被多个租户虚拟化共享，Serverless computing 提供 query-level 粒度的按需付费
- 更优的弹性：计算和存储分离，可按需动态分配
-
缺点：若本地缓存没有命中，则网络流量会成为瓶颈。需要设计高效有用的缓存和计算下推策略。
? Snowflake[6, 24]，Redshift[17]。Snowflake 采用三层架构，云服务层负责管理元数据、虚拟仓库VWs、查询、事务、安全；中间计算层使用具有 EC2 实例的 VWs 处理查询；存储层使用 Amazon S3 持久化数据。
查询执行流程：
- 通过云服务层 Parse query，generate and optimize query plan
- 在一个 VW 中 execute query
- 若 local cache 没有命中，通过 pruning 和 computation pushdown 从云存储加载数据
Query Optimization based on Metadata：元数据存储在云服务层，包括 schema、data version、location、statistics、logs 等信息，查询优化相关技术有：pruning、zero-copy cloning、time traveling (MVCC)
- Pruning：元数据可存储一些统计信息，用于缩小数据获取范围
- Zero-copy cloning：不用物理的去拷贝数据。如现在要创建一个表 T2，它是表 T 的拷贝，此时只需新建一个元数据，而无需拷贝数据
- Time traveling：存储多版本信息
Elastic Scaling in the Cloud：云上的弹性扩缩容有 lazy consistent hashing 算法，来实现更平滑的扩展。在 VW 中添加一个新结点时，一致性哈希是延迟的，只有当一个相关的 task 被调度时，该结点才会拉取要负责数据并缓存。
2 Disaggregated Compute-Memory-Storage OLAP Architecture
- Motivations：
- Elasticity. 计算存储独立扩展
- Centralized Scheduling. 中心化的调度，提高资源利用率
- Complex workloads. 复杂的工作负载，可应对大的中间结果
- Key Features：
- 计算存储分离
- 共享内存层可加速 join 操作
- Multi-tenancy and Serverless
- 计算节点本地 SSD 缓存热点数据
- 云存储服务，e.g., AWS S3、Google Cloud Storage、Azure Blob Storage
- 优点：(与本地无共享 OLAP 架构相比)
- 更高的吞吐量：引入了一个共享内存层来加速分布式 join 的 shuffle 处理，通过避免从磁盘上读写中间结果，来降低 I/O 成本
- 更高的资源利用率：计算资源虚拟化，可按需调度
- 更优的弹性：内存与计算和存储分离，可按需动态分配
- 缺点：shuffle 内存层可能产生较高的成本。需要设计高效的算子下推和调度算法来减少加载到内存的数据。
? BigQuery[14]，使用 Dremel query engine，引入了一个共享内存层来加速分布式 join 的 shuffle 处理，通过避免从磁盘上读写中间结果，来显著降低延迟。
Key Techniques of Cloud OLAP Databases
- Query Processing
- 使用 shuffle memory pool 的 columnar scan [14]
- 使用算子下推的 columnar scan，将计算下推到存储层，? Amazon S3
- 使用缓存和算子下推的 columnar scan [25]
- Storage Management
- 本地缓存 + 共享存储 [6, 17]
- 统一内存池 + 共享存储 [14]
- 半结构化数据管理 [6, 24, 28]
- Serverless Computing
- function as a service，查询是基于 cloud function service 自适应执行的 [18]
- elastic query engine，能通过动态配置查询引擎来执行查询 [4]
- Security. 两种数据保护技术
- 基于软件的数据保护 [6]
- 基于硬件的数据保护，? Intel SGX 的 enclave [1]
- Machine Learning. 将机器学习应用于云数据库，? Sagemaker [13]
挑战和开放问题
- 多写架构：现有的云数据库只支持一写多读，因此需要云原生的多写技术，可扩展写能力。
- 细粒度的 Serverless：现有的弹性云数据库只支持粗粒度的 Serverless (e.g., query engine)，会受到弹性伸缩的高延迟影响，支持细粒度的 Serverless 来有效地为传入的 queries 调度资源是有挑战的。
- 云原生 HTAP 数据库：现有的云原生数据库主要是面向 OLTP 或 OLAP。没有云原生的 HTAP 系统。主要的挑战是如何通过 SLA-aware 优化，明智地为 OLTP 和 OLAP 工作负载调度资源。
- Multi-Cloud 数据库：为了提供高可用性的云数据服务，例如零停机时间，它需要能够利用多云部署功能的多云数据库。有效地确定数据放置策略以及在多个云中有效地迁移数据是一个挑战。
Distributed HTAP Techniques
[TODO]
参考链接
Cloud Databases: New Techniques, Challenges, and Opportunities