数据获取
我在 2022年1月24日 pm2:48:35 CST 手动修改了一个测试文件1的储存类，从S3标准到IA类
由于桶的访问日志文件数据是有一段延迟时间的，所以在进行操作完后，最好等待一个小时后再进行日志查询
-
查询SQL
执行查询
SELECT * FROM S3审计日志表
where requestdatetime like '24/Jan/2022%'
and requester like '%员工号xxxx'其中条件分析：
由于执行时间为 2022年1月24日，所以SQL中的条件就是
requestdatetime like '24/Jan/2022%'requester 后半部分是登录S3桶的员工号
requester like '%员工号xxxx'-
数据过滤
去除不需要的字段和数据后，得到了单纯修改文件类的请求记录
| operation |
requesturi_operation |
requesturi_key
扫描二维码关注公众号，回复：
17237324 查看本文章
|
bytessent |
objectsize |
| REST.COPY.PART |
PUT |
测试文件1路径?uploadId=一长串字符串--&partNumber=3 |
230 |
16777216 |
| REST.COPY.PART |
PUT |
测试文件1路径?uploadId=一长串字符串--&partNumber=2 |
230 |
16777216 |
| REST.COPY.PART |
PUT |
测试文件1路径?uploadId=一长串字符串--&partNumber=1 |
230 |
16777216 |
| REST.COPY.PART |
PUT |
测试文件1路径?uploadId=一长串字符串--&partNumber=4 |
230 |
13697004 |
| REST.POST.UPLOADS |
POST |
测试文件1路径?uploads |
483 |
|
| REST.POST.UPLOAD |
POST |
测试文件1路径?uploadId=一长串字符串-- |
576 |
64028652 |
| REST.HEAD.OBJECT |
HEAD |
测试文件1路径 |
64028652 |
|
| REST.HEAD.OBJECT |
HEAD |
测试文件1路径 |
64028652 |
|
| REST.HEAD.OBJECT |
HEAD |
测试文件1路径 |
64028652 |
|
| REST.GET.OBJECT_TAGGING |
GET |
测试文件1路径?tagging |
115 |
|
| REST.GET.ACL |
GET |
测试文件1路径?acl |
550 |
|
| REST.GET.OBJECT_TAGGING |
GET |
测试文件1路径?tagging |
115 |
|
| REST.GET.OBJECT_TAGGING |
GET |
测试文件1路径?tagging |
115 |
请求分析
SQL中字段 【requesturi_operation】内容对应的是收费中请求类型
| key |
请求 |
请求个数 |
| 测试文件1路径 |
PUT |
4 |
| POST |
2 |
|
| HEAD |
3 |
|
| GET |
4 |
其中4个PUT请求中，所有objectsize 之和与文件的大小一致，为了验证文件大小会影响PUT请求，我又重新修改了一个文件的储存类，从IA类到GIR类
同样的，得到的请求统计如下
| key |
请求 |
请求个数 |
| 测试文件1路径 |
PUT |
4 |
| POST |
2 |
|
| HEAD |
3 |
|
| GET |
4 |
|
| 测试文件2路径 |
PUT |
17 |
| POST |
2 |
|
| HEAD |
3 |
|
| GET |
4 |
测试文件2的17个PUT请求中所有objectsize之和与文件的大小一致，可以确认PUT请求个数为文件除以16M的向上取整的个数，而其他请求（POST、HEAD、GET）都一致
成本计算
根据上面的分析，可以得到下面的公式：
优化后得
而通过生命周期转移的请求费是每 1000 个请求 0.01$，但我还没有测试过除了生命周期请求费外，还有没有其他额外的请求，因此还没判断出哪个方法更节省成本。