数据获取
我在 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$,但我还没有测试过除了生命周期请求费外,还有没有其他额外的请求,因此还没判断出哪个方法更节省成本。