关于对象存储的若干事

引言

最近在阅读鸣嵩的一篇文章，数据库的下一场革命：S3 延迟已降至原先的 10%，云数据库架构该进化了 收获很多，过去时间也基于对象存储做过一些功能实现，特记录下。关于鸣嵩：

曹伟，花名鸣嵩，原阿里巴巴OLTP和 NoSQL数据库产品总负责人，已经独立创业，成立 杭州云猿生数据有限公司。
曹伟 2011年加入阿里数据库团队，作为核心成员历经双11、RDS等阿里数据库变革历程，主导云数据库 POLARDB和HybridDB产品的自主研制，并在 SIGMOD、VLDB等顶级国际学术会议上发表多篇一作文章，他也是中国计算机学会数据库专委会委员

对象存储

对象存储很多人都很熟悉，耳熟能详的很多产品，Amazon S3、Google Cloud Storage 、 Microsoft Azure Storage、阿里云OSS、腾讯云COS等等，我们会发现只要是云厂商，均会提供对象存储产品。

优点

包括：

1. 易于管理，访问简单，通过 RESTful APIs（如HTTP/HTTPS）访问，简单的接口PUT/GET/DELETE；提供多语言的SDK
2. 高度可扩展，在任何Region内可读写
3. 命名空间扁平：对象存储没有像文件系统那样的层级目录结构，而是使用唯一的标识符来检索对象。当成对象存储的路径也可以类似于文件系统多级目录看待，通过LIST操作列出所有前缀匹配若干“路径”下的所有对象，但是LIST很耗时。
4. 成本低，价格便宜，1TB 1个月120元左右。
5. 总吞吐高

缺点

1. 单个对象读写延迟大
2. 性能低：与块存储相比，对象存储的性能可能较低，尤其是对于需要高速随机访问的场景；因为对象存储的实现，LIST操作也可能就是一个随机访问的过程
3. 一致性模型：对象存储提供不同的一致性模型，可能影响业务逻辑

RDS

RDS（Relational Database Service）是指关系型数据库服务，它是一种提供在云中托管、管理关系型数据库的服务。RDS 本质上是关系型数据库上云后的产品，典型产品，包括Amazon RDS、Azure SQL Database、阿里云RDS、腾讯云RDS、华为云RDS，我们会发现只要是云厂商，基本也均会提供RDS产品(这句话很熟悉)。

RDS的众多特性这里不展开，其中RDS 通常以云盘（即块存储）作为其核心存储基础设施，在上述文章中，抛出了如下观点：

在技术革新缺席的前提下，云盘在性价比和计费策略方面失去了其竞争优势，我们判断其会从云厂商的主导产品降级为边缘选项。

文章中，认为公有云的关系型数据库，将会从依赖云盘->利用好对象存储，向采用更加云原生的架构的新时代迈进。

云上存储介质

云盘

云盘主要缺点如下：

1. 云盘定价高。相比于不到1千元 1TB NVMe SSD，云盘需要更多价格。个人觉得，目前主要收益于硬件发展确实很迅速，笔者最近更换笔记本电脑，加装了几TB的固态硬件，价格确实已经很便宜，机械硬盘已经不再考虑了。
2. 云盘弹性不足，仅支持扩容，不支持缩容。比如业务高峰期间，完成扩容；业务高峰过后，无法迅速缩容，进一步加大业务使用成本，无法按量付费。
3. 高可用能力成本高。灾难恢复能力局限于单个可用区（AZ）。如果希望实现跨越AZ的高可用，需要多AZ购买。对于分布式数据库而言，成本更高：

• 单个AZ云盘多副本存储，保证单AZ内存储的可用性
• 分布式采用多副本同步（上层通过RAFT等共识算法实现复制），多个AZ场景下数据冗余过多

4. 性能不足。云盘使用分布式架构，通过 Erasure coding 机制将数据分割成多个小片段，同时所有IO操作都需要网络，延迟较本地盘高一个数量级。这里感触也是比较多，在云盘很多服务下，有时候经常因为达到云盘本身的IO带宽上限进而影响服务。

云上的本地盘实例存储

和云盘不同，实例存储采用了类似于 SR-IOV 和 SPDK 的高效虚拟化技术。优势在于：

1. 实例存储的延迟和带宽都接近物理 SSD 的性能
2. 价格便宜，1TB每月不到300元

最大缺点在于：单副本存储，没有多副本高可用机制，如果宿主机故障了，数据永久丢失，因为没多副本。

SR-IOV 和 SPDK 是用于提高虚拟化环境中网络和存储性能的两种不同技术，分别关注 I/O 虚拟化和存储性能优化。

SR-IOV (Single Root I/O Virtualization):

SR-IOV 是一种硬件虚拟化技术，旨在提高虚拟化环境中的网络和 I/O 性能它允许物理设备（如网卡）在多个虚拟机之间进行直接共享，而无需主机 CPU 的干预。关键特点：

• 硬件虚拟化： SR-IOV 允许物理设备在多个虚拟机之间创建虚拟功能，而无需主机的软件层介入。因此虚拟机可以直接地访问物理硬件，从而提高了性能。

• 虚拟机隔离： SR-IOV 提供了一种在虚拟环境中实现硬件 I/O 隔离的方法。每个虚拟机可以被分配到物理设备的一个虚拟功能，而这个虚拟功能可以被单独配置和管理。

• 单根结构： 单根结构指的是整个 SR-IOV 网络设备的管理和配置由单一的根设备进行。这有助于简化配置和管理。

• 性能提升： 相对于传统的软件实现的虚拟网络，SR-IOV 提供了更低的虚拟化开销，从而提高了网络性能。

SPDK (Storage Performance Development Kit):

SPDK 是一个用于构建高性能存储应用程序的开源软件开发工具包。目标是提高存储系统的性能和效率。SPDK 的关键特点：

• 用户态操作： SPDK 在用户态（用户空间）运行，避免了传统的内核态（内核空间）存储堆栈的一些性能限制，从而减少 I/O 操作的延迟。

• 零拷贝： SPDK 鼓励零拷贝操作，通过直接的用户态 I/O 操作来避免数据在用户态和内核态之间的多次复制，从而减少存储系统的处理时间。

• NVMe 支持： SPDK 适用于支持 NVMe（Non-Volatile Memory Express）设备的高性能存储系统。它提供了针对 NVMe 设备的优化，最大程度地利用其性能潜力。

• 异步 I/O 操作： SPDK 使用异步 I/O 操作，允许应用程序并行处理多个 I/O 请求，提高了系统的并发性。

• 模块化设计： SPDK 的设计模块化，允许开发者选择性地使用或扩展其功能，以适应不同的应用场景。

对象存储对比

云盘、云上本地盘实例存储、对象存储对比：

特点	云盘	云上本地盘实例存储	对象存储
存储类型	块存储	虚拟化技术	对象存储
访问方式	块设备访问	接口访问	HTTP(S) 访问，通过 API
访问性能	高，适合随机读写	高，适合随机读写	通常较低，适合大规模数据
成本	最高	较低	最低
适用场景	适用于需要低延迟的应用	单个对象读写延迟大，但总吞吐很高	适用于大规模数据、归档等
数据高可用	高，适用于关键业务，但成本高	低，宿主机挂了数据没了	高，通过冗余和分布实现，但成本低
可伸缩性	适用于小规模到大规模，但不具备迅速缩容	适用于小规模到大规模， 但不具备迅速缩容	高
吞吐	低	低	高，支持 10Gb 乃至 100Gb 的访问带宽

综上比较，对象存储在定价、高可用成本、吞吐等各方面都很有优势，但是单个对象读写延迟较高。在过去基于对象存储开发的项目，笔者也深刻感知到这一点，比如单个对象PUT/GET只有十几M/S，但利用底层对象存储的并行机制结合业务层的异步和并行框架设计，可以跑到上G/s的速度。

而文章中提到

对象存储的缺陷是其延迟比较高，首字节访问延迟可能高达数十毫秒。这一问题部分源于早期对象存储解决方案通常使用 HDD 作为存储媒介，并且在软件层面，I/O 请求的排队处理也会造成一定延迟。然而，高延迟并非对象存储的本质缺陷，而是由于成本考虑和产品定位所做的权衡。

这个也特别有道理，本身一个系统设计最终是各方面的选择和取舍。而 AWS Reinvent 大会上发布的"S3 Express One Zone"服务，将延迟减少至原先的十分之一，实现了毫秒级的响应速度，这样的延迟其实已经和之前印象中对象存储特性很不一致了。当然带来的缺陷是：

• S3 Express One Zone不再支持跨AZ的容灾和可用，数据都在单个AZ内。这个也很好理解，跨AZ的读写，因为网络RT很大，比如北京到深圳 RT有24毫秒左右，跨城的延迟很难去优化到毫秒级，可能在上百毫秒，甚至更高
• 定价贵。价格是 S3 标准版的 7 倍，是云盘 EBS gp3 的 2 倍。个人感觉是留下未来的降价空间，给客户打折~~~

延迟+成本+持久性

参考数据库的下一场革命：S3 延迟已降至原先的 10%，云数据库架构该进化了 文章中一张图

云盘/NAS：低延迟、持久性好（高可用），但是成本较大
实例存储：低延迟、成本低（单个副本），但是持久性差
对象存储：延迟加大、成本低、持久性好

有点类似之前的文章浅谈CAP+ACID+BASE理论
的CAP，很难有一种云存储产品，在延迟、成本、持久性各方面都达到很好的效果。

目前降本增效是企业广为提的一个概念，如何基于最低的成本的构建考虑的数据库服务？

基于云上的本地盘实例存储

云上的本地盘实例存储低延迟且成本低，但是单副本存储。基于云上的本地盘实例存储，上层通过多副本的机制构建数据库系统，但是问题在于多个云上的本地盘实例存储，可能因为相同的原因的丢失数据， 比如同一批固件BUG的SSD。基于云上的本地盘实例存储，上层采用多副本机制，也未必降低丢失数据的概率。对数据持久性有极高要求的生产环境来说，这种方案并不适用。

延迟和持久分离

通过对象存储保证高持久性、通过云盘/实例存储来保证延迟。具体而言：

1. 写操作，有缓存或者聚合，直接写云盘/实例存储等低延迟存储介质，上层通过共识算法多副本同步。
2. 云盘/实例存储等的数据，会被后台搬迁到对象存储上，同时云盘等只保留数据即可，这样主要数据在对象存储上，不仅高持久，而且低成本（存储便宜）
3. 读操作：构建缓存（比如内存的Cache）；对于位于对象存储，可以采用预热、并行读取等技术手段，保证读取的高效性

Serverless

Serverless 是一个很火的概念，Serverless 本质是一种云计算服务模型，其主要理念是使用者无需关心底层的服务器资源和管理，而可以专注于业务逻辑。核心特点是事件驱动、按需自动扩展以及按执行时间计费。而对于Serverless 数据库，提供了低门槛、灵活扩展和缩容、按量付费等重要特性。其中上述特性对于存储的隐含要求在于：

1. 需要保证按量付费，需要存储池化，需要用多少，就给云厂商付多少钱，对象存储很匹配这一点。
2. 高可用。Serverless 不关心底层的服务器资源和管理，自然也希望本身服务提供高可用的能力。因此Serverless的数据库，需要保证其计算节点池和存储池都在跨 AZ 环境中提供无缝的容灾能力。对象存储也提供了跨AZ的读写能力。

基于对象存储的云数据库

基于上述分析，文章中提出了基于对象存储的云数据库的关键特性:

行列混合存储格式

由单纯的行存储变为行列混合存储，其中这里主要原因目前很多数据库厂商在提HTAP，而列存天然适合于AP数据分析类的业务场景。

关于HTAP（Hybrid Transactional/Analytical Processing）是一种数据库架构，旨在同时支持事务处理（Transactional Processing，OLTP）和分析处理（Analytical Processing，OLAP）。传统上，这两种工作负载分别在不同的系统上执行（比如分析用数据仓库），但 HTAP 将它们集成到同一个系统中，以提供更为综合的数据处理能力。
将行存数据转换为 Pax 格式（行列混合存储格式）存入对象存储好处不仅在适用HTAP，而且可以减少内存开销、降低数据加载时间等

OLTP 与数据湖的深度融合

数据湖（Data Lake）是一种用于存储大量结构化和非结构化数据的架构，旨在为企业提供一个灵活、低成本的数据存储和分析解决方案。数据湖的核心思想是将数据以原始形式保存，并在需要时进行分析、处理和提取价值。关键特点和优势：

• 多样性数据： 数据湖容纳多种类型的数据，包括结构化数据（如关系型数据库中的表格）、半结构化数据（如XML、JSON）以及非结构化数据（如文本文件、图像、音频和视频等）。目前其实多模数据库也支持这么多类型，所以个人理解数据湖从某些方面定义其实和多模数据库类似
• 原始数据存储： 数据湖保存原始数据，不对数据进行预处理或规范化。企业可以存储原始数据，然后根据需要进行多层次的处理和分析。
• 弹性存储： 数据湖通常建立在分布式存储系统上，如HDFS(Hadoop Distributed File System）或云存储服务，以提供弹性和可扩展性。
• 低成本： 数据湖采用相对低成本的存储解决方案
• 分析和处理： 支持多种分析和处理工具，包括SQL查询、数据挖掘、机器学习和大数据处理框架。
• 实时和批处理： 数据湖支持实时和批处理模式
• 安全性： 数据湖通常提供安全性控制，包括对数据的访问权限、加密、身份验证等，以确保敏感数据得到保护。

一种TP和AP系统数据流转的方式，比如数据库->ETL或者CDC能力->数据仓库。
ETL（提取、转换、加载）流程不仅管理负担重，而且实时性较难保证，中间流程过多。
一种新的方式，在数据库中，直接支持将全量数据以行列混合存储格式持久化并写入对象存储，OLTP 数据库可以无缝地将在线数据直接写入数据湖环境，企业可以更快捷、方便使用这些数据

K8s数据库管理

K8S+对象存储+数据库会让管理更简单

总结

最大几点收获如下：

1. 不同时代的硬件发展，会导致系统的架构巨大变化，比如早期的机械盘，数据库领域较多采用B+树的设计，SSD更适合LSM tree的设计，而目前硬件迭代很多，在很多新型硬件下，原来系统的设计或者假设就不存在了，比如超大内存。因此我们需要学习和了解新的硬件，然后设计合适的软件架构。软件基于硬件构建。
2. 企业客户的一个最大需求在于，如何节约成本同时功能完善、性能齐全，传说的既要也要。一些情况不合理，但是有一些情况是可以通过新的设计来满足的，技术服务于业务需求
3. 云盘/对象存储各有优缺点，合适的搭配可以达到更好的效果，有点类似于将军指挥，士兵前线，各司其职的思想。设计是需要权衡的，成本、延迟、持久如何权衡。
4. 技术发展很快，比如对象存储的低延迟，S3 Express One Zone在牺牲了跨AZ的容灾，也提供了相当低延迟的读写服务，基于这种特性一定会有新的设计。