数据存储后端【免费下载链接】opendalApache OpenDAL: One Layer, All Storage.项目地址https://gitcode.com/gh_mirrors/op/opendal点击查看免费下载本文以 Apache OpenDAL 官方发布博客《OwO #1: The v0.40 Release》为骨架结合当前仓库中的核心源码core/core/src与升级文档core/core/src/docs/upgrade.md系统梳理 v0.40 版本在核心库 API 设计、语言绑定、应用与集成生态上的关键变化并还原其背后的 RFC 演进脉络帮助读者理解 OpenDAL 从追加写与普通写分离走向统一 Write 接口 流式 Lister 元数据预取这一 API 哲学的转变过程。OwOOutcome、Working、Outlook是 Apache OpenDAL™ 的版本发布博客系列用于向社区同步当前的工作成果Outcome、正在进行的工作Working与未来的探索方向Outlook。本文对应系列的第一篇《OwO #1: The v0.40 Release》发布于 2023 年 9 月 15 日围绕即将发布的 v0.40 展开。读懂这篇发布说明读者可以掌握v0.40 中append与write的合并方式、list/lister双轨 API 的正确选型、list_with().metakey()的元数据预取用法以及oay、oli、object_store等周边生态项目的定位。OwO 是什么OpenDAL 的版本发布博客系列OwO 是 Outcome成果、Working进行中、Outlook展望三个词的缩写。作为 Apache OpenDAL 的发布博客系列每一期都按这三个维度组织内容Outcome第一个 O总结当前版本取得的关键成果Working中间的 w同步正在推进中的工作Outlook第二个 O讨论 OpenDAL 未来的方向。在 v0.40 时期OpenDAL 的总体架构由四个主要组成部分构成Core用 Rust 编写的核心库Bindings由 OpenDAL Rust 核心驱动的各语言绑定Applications基于 OpenDAL Rust 核心构建的应用Integrations与其他项目的协作集成。这四个部分也正是后续章节的组织线索读者可以在当前仓库的目录结构中一一对应核心实现在 core/core语言绑定在 bindings集成项目在 integrations。Outcomev0.40 的交付成果Core 核心库从功能堆叠到API 统一合并 Append 与 WriteRFC-2578自 v0.36 起OpenDAL 就支持了独立的append操作。但团队发现append 与 write 之间存在大量重复逻辑因此决定将两者合并为一个统一的写函数。此后用户无需再单独处理 appendlet mut w op.writer_with(test.txt).append(true).await?; w.write(content_a).await?; w.write(content_b).await?; w.close().await?;这样用户可以在自己的业务逻辑中直接复用Writer而无需区分新建写入与追加写入两套路径。这一合并最终固化为 RFC-2578Merge Append Into Write在 core/core/src/docs/upgrade.md 中明确给出了迁移指引一次性写入文件请使用op.write()追加写入文件请使用op.write_with().append(true)替代原来的op.append()同样的规则适用于writer()与writer_with()。从当前源码可以印证这一设计已完全落地在 operator_futures.rs 中FutureWriter::append(mut self, v: bool)直接将标志位写入写参数self.args.append v而 ops.rs 中的OpWrite::append()则供底层服务在运行时查询该标志决定走新建还是追加路径。也就是说append从独立的操作降级为Write 操作的一个布尔选项这是 v0.40 最典型的 API 简化范例。新的 Lister APIRFC-2774为了提升 API 一致性v0.40 对列目录listing系列函数做了调整新增了list与list_with两个一次性返回全部条目的方法并把原先的list重命名为流式的lister与lister_with// 旧 API let lister: Lister op.list(dir).await?; // 新 API let entries: VecEntry op.list(dir).await?; let lister: Lister op.lister(dir).await?;这一改动使 API 语义更加统一一次性取回全部条目用list流式逐条消费用lister。在 RFC-2774 的迁移说明中还有三条关键指引一次性列目录使用list()递归列出目录使用list_with().delimiter()或lister_with().delimiter()替代原来的scan()流式列出使用lister()或lister_with()。对照当前源码 operator.rs可以看到这套双轨设计被完整保留list()L2057与lister()L2211是便捷入口list_with()L2104与lister_with()L2246则返回可链式配置选项的 Future。源码注释同时提示list会把整个列表物化进内存面对大规模结果集应优先使用lister流式处理。List With MetakeyRFC-2779为了加速 list 操作v0.40 支持在列目录过程中顺带获取并缓存元数据从而省去额外的独立 metadata 调用let entries: VecEntry op .list_with(dir/) .metakey(Metakey::ContentLength | Metakey::ContentType).await?; // 直接使用元数据 let meta: Metadata entries[0].metadata();这一设计让元数据获取变得更直观用户不再需要为每个 entry 单独发一次metadata()请求而是声明自己关心的元数据字段集合Metakey位标志OpenDAL 在列表过程中尽力补齐。其底层原理记录在 RFC-2779 设计文档 中对每个服务而言stat会返回完整的元数据集如s3返回ContentLength | ContentType | LastModified | ...fs只返回ContentLength | LastModified而list通常只返回部分元数据s3返回ContentLength、LastModifiedfs则一个都不返回。因此list得到的 entry 元数据可能处于三种状态已填充Filled、不存在NotExist或未知Unknown。metakey机制允许 OpenDAL 将用户声明的元数据需求下传给底层服务服务尽力而为地通过列表响应或补充stat调用满足需求。RFC 还提出了stat_complete_metakey能力位用于描述某服务通过stat能取到的完整元数据集合Lister据此决定是否需要补发stat请求。升级文档中的Before / After对照upgrade.md直观展示了这一 API 如何消除循环内的逐条metadata()异步调用。演进说明metakey是 v0.40 时代的重要设计但在后续版本中其概念被进一步简化。根据 RFC-5314Remove Metakey 与 upgrade.mdOpenDAL v0.51 移除了Metakey概念改为由服务声明MetadataCapability并尽最大努力返回尽可能多的元数据。读者在阅读旧代码或迁移历史项目时可留意这一版本差异。Buffered Writerv0.40 为核心库增加了通用的缓冲写入支持用户只需为 writer 指定缓冲大小let w op.writer_with(path/to/file).buffer(8 * 1024 * 1024).await?升级文档upgrade.md详细说明了其行为语义不指定 buffer时每次调用write()都会直接调用底层存储指定 buffer 后只有缓冲写满或调用close()时才会真正落到底层存储。此外buffered writer 还带来一个重要便利用户不再需要为 writer 预先指定content_length()。迁移示例为- let mut w op.writer_with(path/to/file).content_length(1024).await?; let mut w op.writer_with(path/to/file).await?;从当前源码看这一缓冲机制在 operator_futures.rs 中演化为chunk()选项Sets chunk size for buffered writes即设定单次写入的分块大小例如.chunk(8 * 1024 * 1024)会让数据在close时以单次 API 调用发送。其他核心改进v0.40 还移除了原有的range_read与range_reader接口统一收敛为read_with().range()与reader_with().range()upgrade.md- op.range_read(path, range_start..range_end).await?; op.read_with(path).range(range_start..range_end).await?;- let reader op.range_reader(path, range_start..range_end).await?; let reader op.reader_with(path).range(range_start..range_end).await?;这再次体现了 v0.40 的整体基调把分散的专用 API 并入统一的、可选项驱动的*_with()接口族。更多细节可查阅 core/CHANGELOG.md。Bindings 语言绑定两个首发、两个新增v0.40 在语言绑定层面迎来了重要里程碑Copendal-cpp 达到首个可发布状态欢迎社区试用并提供反馈Haskellopendal-hs 达到首个可发布状态Javaopendal-java 在此版本中启用了更多可用服务用户可以访问 Rust 核心默认未开启的服务如redis同时启用了 blocking 层允许用户以阻塞方式访问s3等服务全新绑定新增 opendal-dotnet 与 opendal-php 两个语言绑定项目。这些绑定均由 OpenDAL Rust 核心驱动各绑定目录下均有对应的Cargo.toml与 Rust FFI 层印证了Core Bindings这一架构下一次实现、多语言复用的扩展模式。Applications 应用层oay 与 oli[oay]OpenDAL Gateway允许用户通过既有协议如s3、webdav访问 OpenDAL 支持的服务工作方式类似一个把请求转发到 OpenDAL 服务的代理。本版本实现了基础的webdav支持——用户可以把任意存储服务变身为 WebDAV 服务器。[oli]OpenDAL CLI允许用户像使用s3cmd、gcloud那样通过命令行访问存储服务。本版本修复了一些体验问题并完善了文档。Integrations 集成object_storeobject_store 的目标是在 OpenDALOperator之上实现object_storecrate 的 trait让用户可以把 OpenDAL 作为object_store的后端使用。该集成在 v0.40 时大部分功能可用但仍有一些 OpenDAL 尚未支持的边缘场景此版本在集成层面没有新进展团队正在等待相关 issueAllow list paths that do not end with/的解决。Working正在进行的工作v0.40 发布时团队同步推进着以下事项object_store支持让该集成稳定可用并为其找到实际用户移除路径必须以/结尾的限制实现列出不以/结尾的路径扩展start-after支持将分页续列能力推广到更多服务对应 issue #2786。其中路径/限制与start-after都属于列表list能力的深化与上文 RFC-2774 的 Lister 重构一脉相承先把 API 形态统一再逐步补齐各服务的能力差异。Outlook面向未来的探索OpenDAL 团队在 v0.40 时期已经开始探索一些创新方向OpenDAL REST/gRPC API为 OpenDAL 提供 REST/gRPC 服务端OpenDAL CacheOpenDAL 原生的缓存库让用户更高效地访问数据OpenDAL File System基于 OpenDAL 构建的只读文件系统Rust 实现kio-opendal由 OpenDAL 驱动的 KIO 插件让用户在 KDE Dolphin 文件管理器中访问不同的存储服务gvfs-opendal由 OpenDAL 驱动的 gvfs 插件让用户在 GNOME Files 中访问不同的存储服务。这些方向从数据访问协议层REST/gRPC、文件系统延伸到桌面集成层KIO、GVFS展现了 OpenDAL 作为统一存储访问层的横向野心。欢迎社区参与讨论。总结作为 OwO 系列的开篇《OwO #1》完整呈现了 OpenDAL v0.40 的三个侧面Outcome 层面核心库完成了append并入writeRFC-2578、Lister API 双轨化RFC-2774、list_with().metakey()元数据预取RFC-2779与 Buffered Writer 四大 API 演进C/Haskell 绑定首发、dotnet/php 绑定加入oay 网关获得 WebDAV 能力object_store集成持续推进Working 层面聚焦列表能力深化路径/限制、start-after推广与集成生态落地Outlook 层面探索 REST/gRPC 服务、缓存、文件系统与桌面文件管理器插件等新形态。对开发者而言v0.40 的核心启示是 OpenDAL 的 API 设计取向能用选项表达的能力append、range、buffer就并入统一的*_with()接口能用类型区分语义的场景一次性list与流式lister就显式分流。这些设计决策至今仍能在 core/core/src/types/operator/operator.rs 与 core/core/src/types/operator/operator_futures.rs 的源码中直接观察到是理解 OpenDAL API 演化历史的绝佳样本。赞分享数据存储后端【免费下载链接】opendalApache OpenDAL: One Layer, All Storage.项目地址https://gitcode.com/gh_mirrors/op/opendal点击查看免费下载相关推荐Apache OpenDAL 目录列表能力演进从 ObjectStream RFC 到现代 Lister APIApache OpenDAL 目录列表能力演进从 ObjectStream RFC 到现代 Lister API 导读 本文以 OpenDAL 核心仓库中的数据存储后端Apache OpenDAL D 绑定实战指南构建、API 与并行读写Apache OpenDAL D 绑定实战指南构建、API 与并行读写 Apache OpenDAL 的 D 语言绑定位于 bindings/d https数据存储后端OpenDAL Lister API从 RFC 2774 到 list/lister 分层设计的实现剖析OpenDAL Lister API从 RFC 2774 到 list/lister 分层设计的实现剖析 本篇围绕 Apache OpenDAL 的 RFC《数据存储后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
数据存储后端【免费下载链接】opendalApache OpenDAL: One Layer, All Storage.项目地址https://gitcode.com/gh_mirrors/op/opendal点击查看免费下载本文以 Apache OpenDAL 官方发布博客《OwO #1: The v0.40 Release》为骨架结合当前仓库中的核心源码core/core/src与升级文档core/core/src/docs/upgrade.md系统梳理 v0.40 版本在核心库 API 设计、语言绑定、应用与集成生态上的关键变化并还原其背后的 RFC 演进脉络帮助读者理解 OpenDAL 从追加写与普通写分离走向统一 Write 接口 流式 Lister 元数据预取这一 API 哲学的转变过程。OwOOutcome、Working、Outlook是 Apache OpenDAL™ 的版本发布博客系列用于向社区同步当前的工作成果Outcome、正在进行的工作Working与未来的探索方向Outlook。本文对应系列的第一篇《OwO #1: The v0.40 Release》发布于 2023 年 9 月 15 日围绕即将发布的 v0.40 展开。读懂这篇发布说明读者可以掌握v0.40 中append与write的合并方式、list/lister双轨 API 的正确选型、list_with().metakey()的元数据预取用法以及oay、oli、object_store等周边生态项目的定位。OwO 是什么OpenDAL 的版本发布博客系列OwO 是 Outcome成果、Working进行中、Outlook展望三个词的缩写。作为 Apache OpenDAL 的发布博客系列每一期都按这三个维度组织内容Outcome第一个 O总结当前版本取得的关键成果Working中间的 w同步正在推进中的工作Outlook第二个 O讨论 OpenDAL 未来的方向。在 v0.40 时期OpenDAL 的总体架构由四个主要组成部分构成Core用 Rust 编写的核心库Bindings由 OpenDAL Rust 核心驱动的各语言绑定Applications基于 OpenDAL Rust 核心构建的应用Integrations与其他项目的协作集成。这四个部分也正是后续章节的组织线索读者可以在当前仓库的目录结构中一一对应核心实现在 core/core语言绑定在 bindings集成项目在 integrations。Outcomev0.40 的交付成果Core 核心库从功能堆叠到API 统一合并 Append 与 WriteRFC-2578自 v0.36 起OpenDAL 就支持了独立的append操作。但团队发现append 与 write 之间存在大量重复逻辑因此决定将两者合并为一个统一的写函数。此后用户无需再单独处理 appendlet mut w op.writer_with(test.txt).append(true).await?; w.write(content_a).await?; w.write(content_b).await?; w.close().await?;这样用户可以在自己的业务逻辑中直接复用Writer而无需区分新建写入与追加写入两套路径。这一合并最终固化为 RFC-2578Merge Append Into Write在 core/core/src/docs/upgrade.md 中明确给出了迁移指引一次性写入文件请使用op.write()追加写入文件请使用op.write_with().append(true)替代原来的op.append()同样的规则适用于writer()与writer_with()。从当前源码可以印证这一设计已完全落地在 operator_futures.rs 中FutureWriter::append(mut self, v: bool)直接将标志位写入写参数self.args.append v而 ops.rs 中的OpWrite::append()则供底层服务在运行时查询该标志决定走新建还是追加路径。也就是说append从独立的操作降级为Write 操作的一个布尔选项这是 v0.40 最典型的 API 简化范例。新的 Lister APIRFC-2774为了提升 API 一致性v0.40 对列目录listing系列函数做了调整新增了list与list_with两个一次性返回全部条目的方法并把原先的list重命名为流式的lister与lister_with// 旧 API let lister: Lister op.list(dir).await?; // 新 API let entries: VecEntry op.list(dir).await?; let lister: Lister op.lister(dir).await?;这一改动使 API 语义更加统一一次性取回全部条目用list流式逐条消费用lister。在 RFC-2774 的迁移说明中还有三条关键指引一次性列目录使用list()递归列出目录使用list_with().delimiter()或lister_with().delimiter()替代原来的scan()流式列出使用lister()或lister_with()。对照当前源码 operator.rs可以看到这套双轨设计被完整保留list()L2057与lister()L2211是便捷入口list_with()L2104与lister_with()L2246则返回可链式配置选项的 Future。源码注释同时提示list会把整个列表物化进内存面对大规模结果集应优先使用lister流式处理。List With MetakeyRFC-2779为了加速 list 操作v0.40 支持在列目录过程中顺带获取并缓存元数据从而省去额外的独立 metadata 调用let entries: VecEntry op .list_with(dir/) .metakey(Metakey::ContentLength | Metakey::ContentType).await?; // 直接使用元数据 let meta: Metadata entries[0].metadata();这一设计让元数据获取变得更直观用户不再需要为每个 entry 单独发一次metadata()请求而是声明自己关心的元数据字段集合Metakey位标志OpenDAL 在列表过程中尽力补齐。其底层原理记录在 RFC-2779 设计文档 中对每个服务而言stat会返回完整的元数据集如s3返回ContentLength | ContentType | LastModified | ...fs只返回ContentLength | LastModified而list通常只返回部分元数据s3返回ContentLength、LastModifiedfs则一个都不返回。因此list得到的 entry 元数据可能处于三种状态已填充Filled、不存在NotExist或未知Unknown。metakey机制允许 OpenDAL 将用户声明的元数据需求下传给底层服务服务尽力而为地通过列表响应或补充stat调用满足需求。RFC 还提出了stat_complete_metakey能力位用于描述某服务通过stat能取到的完整元数据集合Lister据此决定是否需要补发stat请求。升级文档中的Before / After对照upgrade.md直观展示了这一 API 如何消除循环内的逐条metadata()异步调用。演进说明metakey是 v0.40 时代的重要设计但在后续版本中其概念被进一步简化。根据 RFC-5314Remove Metakey 与 upgrade.mdOpenDAL v0.51 移除了Metakey概念改为由服务声明MetadataCapability并尽最大努力返回尽可能多的元数据。读者在阅读旧代码或迁移历史项目时可留意这一版本差异。Buffered Writerv0.40 为核心库增加了通用的缓冲写入支持用户只需为 writer 指定缓冲大小let w op.writer_with(path/to/file).buffer(8 * 1024 * 1024).await?升级文档upgrade.md详细说明了其行为语义不指定 buffer时每次调用write()都会直接调用底层存储指定 buffer 后只有缓冲写满或调用close()时才会真正落到底层存储。此外buffered writer 还带来一个重要便利用户不再需要为 writer 预先指定content_length()。迁移示例为- let mut w op.writer_with(path/to/file).content_length(1024).await?; let mut w op.writer_with(path/to/file).await?;从当前源码看这一缓冲机制在 operator_futures.rs 中演化为chunk()选项Sets chunk size for buffered writes即设定单次写入的分块大小例如.chunk(8 * 1024 * 1024)会让数据在close时以单次 API 调用发送。其他核心改进v0.40 还移除了原有的range_read与range_reader接口统一收敛为read_with().range()与reader_with().range()upgrade.md- op.range_read(path, range_start..range_end).await?; op.read_with(path).range(range_start..range_end).await?;- let reader op.range_reader(path, range_start..range_end).await?; let reader op.reader_with(path).range(range_start..range_end).await?;这再次体现了 v0.40 的整体基调把分散的专用 API 并入统一的、可选项驱动的*_with()接口族。更多细节可查阅 core/CHANGELOG.md。Bindings 语言绑定两个首发、两个新增v0.40 在语言绑定层面迎来了重要里程碑Copendal-cpp 达到首个可发布状态欢迎社区试用并提供反馈Haskellopendal-hs 达到首个可发布状态Javaopendal-java 在此版本中启用了更多可用服务用户可以访问 Rust 核心默认未开启的服务如redis同时启用了 blocking 层允许用户以阻塞方式访问s3等服务全新绑定新增 opendal-dotnet 与 opendal-php 两个语言绑定项目。这些绑定均由 OpenDAL Rust 核心驱动各绑定目录下均有对应的Cargo.toml与 Rust FFI 层印证了Core Bindings这一架构下一次实现、多语言复用的扩展模式。Applications 应用层oay 与 oli[oay]OpenDAL Gateway允许用户通过既有协议如s3、webdav访问 OpenDAL 支持的服务工作方式类似一个把请求转发到 OpenDAL 服务的代理。本版本实现了基础的webdav支持——用户可以把任意存储服务变身为 WebDAV 服务器。[oli]OpenDAL CLI允许用户像使用s3cmd、gcloud那样通过命令行访问存储服务。本版本修复了一些体验问题并完善了文档。Integrations 集成object_storeobject_store 的目标是在 OpenDALOperator之上实现object_storecrate 的 trait让用户可以把 OpenDAL 作为object_store的后端使用。该集成在 v0.40 时大部分功能可用但仍有一些 OpenDAL 尚未支持的边缘场景此版本在集成层面没有新进展团队正在等待相关 issueAllow list paths that do not end with/的解决。Working正在进行的工作v0.40 发布时团队同步推进着以下事项object_store支持让该集成稳定可用并为其找到实际用户移除路径必须以/结尾的限制实现列出不以/结尾的路径扩展start-after支持将分页续列能力推广到更多服务对应 issue #2786。其中路径/限制与start-after都属于列表list能力的深化与上文 RFC-2774 的 Lister 重构一脉相承先把 API 形态统一再逐步补齐各服务的能力差异。Outlook面向未来的探索OpenDAL 团队在 v0.40 时期已经开始探索一些创新方向OpenDAL REST/gRPC API为 OpenDAL 提供 REST/gRPC 服务端OpenDAL CacheOpenDAL 原生的缓存库让用户更高效地访问数据OpenDAL File System基于 OpenDAL 构建的只读文件系统Rust 实现kio-opendal由 OpenDAL 驱动的 KIO 插件让用户在 KDE Dolphin 文件管理器中访问不同的存储服务gvfs-opendal由 OpenDAL 驱动的 gvfs 插件让用户在 GNOME Files 中访问不同的存储服务。这些方向从数据访问协议层REST/gRPC、文件系统延伸到桌面集成层KIO、GVFS展现了 OpenDAL 作为统一存储访问层的横向野心。欢迎社区参与讨论。总结作为 OwO 系列的开篇《OwO #1》完整呈现了 OpenDAL v0.40 的三个侧面Outcome 层面核心库完成了append并入writeRFC-2578、Lister API 双轨化RFC-2774、list_with().metakey()元数据预取RFC-2779与 Buffered Writer 四大 API 演进C/Haskell 绑定首发、dotnet/php 绑定加入oay 网关获得 WebDAV 能力object_store集成持续推进Working 层面聚焦列表能力深化路径/限制、start-after推广与集成生态落地Outlook 层面探索 REST/gRPC 服务、缓存、文件系统与桌面文件管理器插件等新形态。对开发者而言v0.40 的核心启示是 OpenDAL 的 API 设计取向能用选项表达的能力append、range、buffer就并入统一的*_with()接口能用类型区分语义的场景一次性list与流式lister就显式分流。这些设计决策至今仍能在 core/core/src/types/operator/operator.rs 与 core/core/src/types/operator/operator_futures.rs 的源码中直接观察到是理解 OpenDAL API 演化历史的绝佳样本。赞分享数据存储后端【免费下载链接】opendalApache OpenDAL: One Layer, All Storage.项目地址https://gitcode.com/gh_mirrors/op/opendal点击查看免费下载相关推荐Apache OpenDAL 目录列表能力演进从 ObjectStream RFC 到现代 Lister APIApache OpenDAL 目录列表能力演进从 ObjectStream RFC 到现代 Lister API 导读 本文以 OpenDAL 核心仓库中的数据存储后端Apache OpenDAL D 绑定实战指南构建、API 与并行读写Apache OpenDAL D 绑定实战指南构建、API 与并行读写 Apache OpenDAL 的 D 语言绑定位于 bindings/d https数据存储后端OpenDAL Lister API从 RFC 2774 到 list/lister 分层设计的实现剖析OpenDAL Lister API从 RFC 2774 到 list/lister 分层设计的实现剖析 本篇围绕 Apache OpenDAL 的 RFC《数据存储后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
