把同一份负载放进两种存储再对比

目标

把同一份语料分别放入文件系统、S3 兼容存储（SeaweedFS S3 网关）和 SeaweedFS Filer 这三处，亲自测量数量、时间和延迟，学会用数字而不是个人喜好来选择存储。

为什么重要

存储选型不是靠抄录基准测试表格就能决定的。因为同一个产品，随工作负载不同，可能是最佳选择，也可能是最差选择。在 2,000 个 4KiB 文件上拉开的差距，到了一个 200MiB 文件上就消失了，反过来也有这种情况。本实验让你亲自测量，来确认这一点。尤其是第 4 步，亲自数一数 2,000 个文件装进了几个卷文件，“擅长处理小文件”这句话就变成了具体的结构问题。最后的决策表要做成以后真正做选择时可以直接拿出来用的形式。

关于对比对象，补充一点。本实验的 S3 一侧原本是 MinIO。MinIO 把每个对象存为磁盘上的一个目录加一个元数据文件（xl.meta），所以第 2 步测出的文件系统成本，它对每个对象都原样承担——这曾是小文件问题的典型反面。2025 年社区版停止发布二进制文件，因此从这个镜像中移除了，现在第 3 步的 S3 服务器是 SeaweedFS 的 S3 网关。因此本实验现在测量的不是两个存储引擎的对决，而是小文件成本的两个层面。文件系统（第 2 步）体现的是“磁盘上文件数量”的成本，S3（第 3 步）和 Filer（第 4 步）则是从两个入口敲打同一个 SeaweedFS，体现“请求数量”的成本。通过 S3 写入时卷文件也不会增加，这一点同样在第 3 步一并确认。

步骤

在 /root/cmp/corpus/ 之下创建 2,000 个 4096 字节的文件。名称从 f0000.bin 到 f1999.bin。
在 /root/cmp/fs.txt 中写入 files=2000、data_bytes=8192000、disk_kb=<du -sk 결과>（占位符为 du -sk 的结果）三行。disk_kb 必须大于数据大小。
在 S3 服务器（http://127.0.0.1:9000）上创建存储桶 lab-cmp，把语料整体上传，并在 /root/cmp/s3.txt 中写入 objects=2000 seconds=<소수>（占位符为小数）。
把同一份语料放入 SeaweedFS Filer 的 /cmp/ 之下，并在 /root/cmp/sw.txt 中写入 files=2000 dat_files=<n> seconds=<소수>（占位符为卷文件数量和小数）。dat_files 必须不大于 20。
从每个存储中随机读取 100 个，在 /root/cmp/latency.csv 中写入 store,avg_ms 表头，以及 fs、s3、filer 三行。
把一个 200MiB 文件放入三个存储并读取，在 /root/cmp/bigfile.csv 中写入 store,put_ms,get_ms 表头和三行。
在 /root/cmp/decision.md 中写一张 Markdown 表格。行标题是 소파일 대량、대용량 소수、S3 API 필요、운영 인력（均为韩文，依次意为“大量小文件”“少量大文件”“需要 S3 API”“运维人力”）四个，并且必须有推荐列。

参考

生成文件：dd if=/dev/urandom of=f0000.bin bs=4096 count=1 或 Python 循环
磁盘使用量：du -sk /root/cmp/corpus
测量时间：date +%s.%N 前后的差值，或 time
S3 一侧：凭据在 /opt/fixtures/s3/creds.env，profile 用与 s3-basics 第 1 步相同的方法创建 local。上传用 aws s3 cp --recursive，读取用 boto3 更方便。
两个 SeaweedFS 是不同的进程。S3 服务器是实验环境启动的（数据在 /var/lib/lab-s3/data），第 4 步的 Master·Volume·Filer（9333·8180·8888）则需要自己启动。
常见错误 1：往三个存储里放入不同的数据再做比较。
常见错误 2：把缓存已预热和未预热的状态混在一起测量——保持顺序一致。

创建用于比较的语料

在 /root/cmp/corpus/ 之下创建 2,000 个 4096 字节的文件。名称从 f0000.bin 到 f1999.bin。

必须把同样的数据放入三处才能比较。准确对齐大小和数量。

放入文件系统并测量元数据成本

在 /root/cmp/fs.txt 中写入 files=2000、data_bytes=8192000、disk_kb=<du -sk 결과>（占位符为 du -sk 的结果）三行。disk_kb 必须大于数据大小。

数据大小和实际占用的块是不同的。也同时数一下文件数量。

放入 S3 并测量耗时

在 S3 服务器（http://127.0.0.1:9000）上创建存储桶 lab-cmp，把语料整体上传，并在 /root/cmp/s3.txt 中写入 objects=2000 seconds=<소수>（占位符为小数）。

每一个对象都是一次请求。确认数量是否就等于时间，以及 S3 服务器的卷文件是否会增加。

放入 SeaweedFS 并测量卷文件数量

把同一份语料放入 SeaweedFS Filer 的 /cmp/ 之下，并在 /root/cmp/sw.txt 中写入 files=2000 dat_files=<n> seconds=<소수>（占位符为卷文件数量和小数）。dat_files 必须不大于 20。

直接使用上一项实验中启动的守护进程。卷文件的数量是关键的观察点。

比较随机读取延迟

从每个存储中随机读取 100 个，在 /root/cmp/latency.csv 中写入 store,avg_ms 表头，以及 fs、s3、filer 三行。

以随机顺序读取同样的 100 个。把三个值汇总到一个文件中。

用一个大文件做同样的比较

把一个 200MiB 文件放入三个存储并读取，在 /root/cmp/bigfile.csv 中写入 store,put_ms,get_ms 表头和三行。

在小文件上拉开的差距，到了大文件上会怎样，这是结论的一半。

编写选型标准表

在 /root/cmp/decision.md 中写一张 Markdown 表格。行标题是 소파일 대량、대용량 소수、S3 API 필요、운영 인력（均为韩文，依次意为“大量小文件”“少量大文件”“需要 S3 API”“运维人力”）四个，并且必须有推荐列。

按工作负载特性，用表格整理出该选哪一边。行标题就是评分标准。