#s3 #client #aws #async #tokio #api-bindings

s3-simple

简单、快速、高效的 bucket 操作 s3 客户端

5 个版本 (3 个重大变更)

0.4.0 2024年7月20日
0.3.0 2024年4月17日
0.2.0 2024年4月12日
0.1.1 2024年4月12日
0.1.0 2024年4月12日

#1285 in 网页编程

Download history 184/week @ 2024-04-14 31/week @ 2024-04-21 21/week @ 2024-04-28 16/week @ 2024-05-05 23/week @ 2024-05-12 40/week @ 2024-05-19 62/week @ 2024-05-26 82/week @ 2024-06-02 44/week @ 2024-06-09 28/week @ 2024-06-16 30/week @ 2024-06-23 27/week @ 2024-06-30 25/week @ 2024-07-07 124/week @ 2024-07-14 104/week @ 2024-07-21 78/week @ 2024-07-28

每月下载 335 次
用于 2 个 Crates (通过 cryptr)

Apache-2.0

79KB
1.5K SLoC

s3-simple

简单、快速、高效的 bucket 操作 s3 客户端

为什么?

为什么还需要另一个 s3 客户端 crate?因为现在有很多,很多都是不维护的,很多都有缺陷,很多都带有大量的依赖。

通常,你需要你的 bucket CRUD 操作,仅此而已。
这个 crate 是为了满足对高效解决方案的需求而创建的,它不会占用所有内存来处理大文件,同时尽可能快。
rust-s3 crate 中重用了相当多的代码,特别是用于头部签名。没有必要重新发明轮子。它所做的事情不同之处在于,它只使用异步,有一个固定的、内置的请求后端(reqwest)带有连接池,并且它不提供(也永远不会提供)所有可能的 S3 API 动作。

我尝试过相当多的不同的 s3 客户端 crate,但到目前为止对任何一个都不完全满意。有一些相当好的,比如 rusty-s3,但我不喜欢在不需要时使用预签名 URL,出于安全原因。是的,你不能用随机部分猜测 URL,但它们会被记录在许多你可以简单地读取它们的地方。
其他 crate 的问题在于,它们为每个单独的请求重新创建一个新的客户端,这意味着即使是只有 200 字节的对象也需要新的 TLS 握手,这是一个巨大的开销。然后其他一些又试图在写入磁盘的第一个字节之前将任何大小的文件完全缓冲到内存中,这几次 OOM 杀死我的应用程序,因为它们通常运行在不太强大的大型服务器上。

它提供的内容

  • 快速、高效、最小化客户端
  • 内部使用 reqwest 的连接池
  • 流式传输,不消耗您的内存
  • 故意不完整 S3 API 以降低复杂性
  • 仅接受通过访问密钥和密钥进行连接
  • 以下当前实现的操作
    • 为元数据执行 HEAD 对象
    • 获取对象 - S3Responsereqwest::Response 的包装,因此您自己决定是将其保存在内存中还是将其转换为流
    • 获取对象范围以进行部分下载
    • 删除对象
    • 上传对象(直接上传)
    • 从任何实现 AsyncRead 的源进行PUT流式传输
    • 列出存储桶内容
    • S3对象内部副本
  • 所有操作均针对 MinioGarage 进行测试

如何使用它

查看 示例,但基本上

let bucket = Bucket::try_from_env()?;

// upload
bucket.put("test.txt", b"Hello S3").await?;

// get it back
let res = bucket.get("test.txt").await?;
// no manual status code checking necessary,
// any non-success will return an S3Error
let body = res.bytes().await?;
assert_eq!(body.as_ref(), b"Hello S3");

依赖项

~9–26MB
~380K SLoC