Socrates The New SQL Server in the Cloud

Categories:  Scholar

Socrates The New SQL Server in the Cloud

摘要翻译

云中的数据库即服务范式(DBaaS)越来越受欢迎. 组织采用这种范式是因为他们期望更高的安全性、更高的可用性以及更低、更灵活的高性能成本. 但是，很明显，在云中，传统的单片数据库架构无法满足这些期望. 本文介绍了一种新的DBaaS体系结构，称为苏格拉底。苏格拉底已经在Microsoft SQL Server中实现，并在Azure中以SQL DB Hyperscale的形式提供。本文描述了Socrates的主要思想和特性，并将其性能与Azure中先前的SQL DB进行了比较。

目录翻译

  • ABSTRACT
  • 1 INTRODUCTION
  • 2 STATE OF THE ART(介绍4种DBaaS系统)
  • 3 IMPORTANT SQL SERVER FEATURES(Socrate基于的一些重要SQL Server特性)
    • 3.1 Page Version Store 存储页面版本
    • 3.2 Accelerated Database Recovery 加速数据库恢复
    • 3.3 Resilient Buffer Pool Extension 弹性缓冲池扩展
    • 3.4 RBIO protocol
    • 3.5 Snapshot Backup/Restore 快照备份和恢复
    • 3.6 I/O Stack Virtualization I/O栈虚拟化
  • 4 SOCRATES ARCHITECTURE
    • 4.1 Design Goals and Principles
      • 4.1.1 Local Fast Storage vs. Cheap, Scalable, Durable Storage 本地快速存储vs.廉价、可扩展、持久的存储
      • 4.1.2 Bounded-time Operations 有限的时间内操作
      • 4.1.3 From Shared-nothing to Shared-disk
      • 4.1.4 Low Log Latency, Separation of Log 低日志延迟，日志分离
      • 4.1.5 Pushdown Storage Functions 计算下推到存储
      • 4.1.6 Reuse Components, Tuning, Optimization 重用组件、调优、优化
    • 4.2 Socrates Architecture Overview
    • 4.3 XLOG Service
    • 4.4 Primary Compute Node and GetPage@LSN
    • 4.5 Secondary Compute Node
    • 4.6 Page Servers
    • 4.7 XStore for Durability and Backup/Restore
  • 5 SOCRATES AT WORK
  • 6 DISCUSSION & SOCRATES DEPLOYMENTS
  • 7 PERFORMANCE EXPERIMENTS AND RESULTS 性能实验和结果
    • 7.1 Software and Services Used 使用的软件和服务
    • 7.2 Experiment 1: CDB Default Mix, Throughput, Production Cluster 实验1：CDB默认混合、吞吐量、生产集群
    • 7.3 Experiment 2: Caching Behavior 实验2：缓存行为
    • 7.4 Experiment 3: Update-heavy CDB, Log Throughput 更新繁重的CDB，日志吞吐量
  • 8 CONCLUSION

十问

Q1论文试图解决什么问题？

  • 论文提出了一个DBaaS系统Socrate
  • 实现更高的安全性、更高的可用性以及更低、更灵活的高性能成本的云上的数据库服务

Q2这是否是一个新的问题？

  • 不是, 系统领域的论文想解决的问题基本都差不多, 更多体现的实现的区别

Q3这篇文章要验证一个什么科学假设？

  • 无

Q4有哪些相关研究？如何归类？谁是这一课题在领域内值得关注的研究员？

  • DBaaS各家云上数据库基本都有研究
    • snowflake
    • redshift
    • polardb
    • aurora
  • 本文 日志与存储分离的思想, 和fdb的设计类似

Q5论文中提到的解决方案之关键是什么？

本文介绍了Socrates，一种新的OLTP数据库系统体系结构. 苏格拉底设计采用了计算与存储的分离。此外，Socrates将数据库日志与存储分离，并将日志视为first-class citizen。

  • 存算分离结构
    • 在Aurora基础上进一步分离了日志和存储, 按论文说法即分离了持久性和可用性
    • 将日志层和存储层分离就分离了持久性(由log层实现)和可用性(由storage层实现)。
      • 持久性是任何数据库系统避免数据丢失的基本属性。
      • 在出现故障时，需要可用性来提供高质量的服务。
      • 传统上，数据库系统通过将计算资源专门用于维护数据的多个副本的任务，将持久性和可用性的实现耦合起来。然而，通过将这两个概念分开，有巨大的、未开发的潜力:
        • (a)与可用性相比，持久性不需要fast storage中的copies
        • (b)与持久性相比，可用性不需要固定数量的replicas(因为quoram)
        • 把这两个概念分开，可以让苏格拉底用最合适的机制来完成手头的任务。具体来说，与目前市场上的其他数据库体系结构相比，Socrates在快速本地存储中需要更便宜的数据副本、更少的总体数据副本、更少的网络带宽和更少的计算资源来保持副本的最新

Q6论文中的实验是如何设计的？

实验一 对比HADR和Socrate的基础性能

image-20221201205426195

实验二: 缓存命中率

image-20221201205633858

image-20221201205652757

实验三: 对比日志吞吐量

image-20221201205827031

Q7用于定量评估的数据集是什么？代码有没有开源？

We used the CDB benchmark [1 ] which is Microsoft’sCloud Database Benchmark (also known as the DTU benchmark) and has been used to test the performance of all Microsoft DBaaS offerings in Azure. CDB is based on a synthetic database with six tables and a scaling factor to generate databases of different sizes. If not stated otherwise, we used a 1TB CDB database which is a size that is comfortably supported by HADR. We also did experiments that demonstrate the scalability of Socrates to much larger sizes (not supported by HADR).

Q8论文中的实验及结果有没有很好地支持需要验证的科学假设？

  • 实验没有太多参考价值

Q9这篇论文到底有什么贡献？

  • Socrates依赖于划分计算和存储的既定原则，以实现更好的可用性和弹性。此外，苏格拉底还分离了durability和availability。这种方法是新颖的，以前的文献中没有研究过

Q10下一步呢？有什么工作可以继续深入？

  • Further avenues for future work include exploring multi-master variants for Socrates
  • better HTAP support in Socrates
  • and making use of the log for other services such as audit and security.

重点关注

HADR结构

image-20221201211529902

  • 在苏格拉底之前，SQL DB基于一种称为HADR的体系结构，如图1所示。

  • 有一个主节点，它处理所有更新事务并将更新日志发送到所有次要节点。日志传送是在分布式数据库系统中保持副本一致性的事实上标准。此外，Primary定期将数据备份到Azure的标准存储服务(称为XStore):日志每5分钟备份一次，整个数据库的增量每天备份一次，每周备份一次。辅助节点可以处理只读事务。如果Primary失败，其中一个secondary将成为新的Primary。使用HADR, SQL DB需要4个节点(1个Primary和3个secondary)来保证高可用性和持久性:如果所有4个节点都失败，就会有数据丢失，因为日志每5分钟才备份一次。

  • 到目前为止，HADR体系结构已经成功地用于部署在Azure中的数百万个数据库。

    • HADR具有高性能，因为每个计算节点都有数据库的完整本地副本。

    • 消极的一面是，数据库的大小不能超过一台机器的存储容量。
    • 对于长时间运行的事务，当日志增长到超过机器的存储容量，并且在长时间运行的事务提交之前无法截断时，会出现一个特殊情况。O(数据大小)操作也会产生问题。例如，播种一个新节点的成本与数据库的大小成线性关系。备份/恢复、扩展和缩小是成本与数据库大小成线性增长的操作的进一步例子。这就是为什么SQL DB现在将数据库的大小限制在4TB(表1)。

Socrate结构

image-20221201212616066

图2显示了Socrates架构。很明显，它遵循了前一节中概述的所有设计原则和目标:(a)计算和存储的分离，(b)分层和向外扩展的存储，(c)有界操作，(d)日志与计算和存储的分离，(e)将功能转移到存储层的机会，以及(f)现有组件的重用。

苏格拉底的建筑有四层。应用程序连接到Compute节点。与HADR中一样，有一个Primary Compute节点处理所有读/写事务。可以有任意数量的secondary来处理只读事务或充当故障转移目标。Compute节点以与现在相同的方式实现查询优化、并发控制和安全，并支持T-SQL和相同的api。如果Primary失败，其中一个secondary将成为新的Primary。所有计算节点将数据页缓存在主存和SSD上的resilient buffer pool扩展。

苏格拉底体系结构的第二层是XLOG服务。这一层实现了“日志分离”原则。虽然这种分离在以前的文献中已经被提出，但这种日志的分离将Socrates与其他云数据库系统(如Amazon Aurora[20])区别开来。XLOG服务在存储层实现了低提交延迟和良好的可伸缩性(向外扩展)。因为Primary处理所有更新(包括DML操作)，所以只有Primary写入日志。当写入日志时，这种单一写入器方法保证了低延迟和高吞吐量。所有其他节点(例如，次要节点)以异步方式使用日志，以保持其数据副本的最新状态。

XLOG

image-20221206103919746

苏格拉底在Aurora的基础上将LOG与存储分离。首先将日志持久化到XLOG服务中，然后将其异步发送到一组页面服务器。每个页面服务器负责一个数据库分区，独立地回放日志，生成页面并为GetPage@LSN请求提供服务。

专业名词

DBaaS

CDB

参考文献

Buy Me a Coffee !
Read More

The Snowflake Elastic Data Warehouse

【2022-11-23】snowflake发表的论文, 云原生数据库经典论文