aws 统计S3上占用存储总量

s3是亚马逊对象存储设备,是亚马逊云平台推出的第一个产品,采用键值的方式进行存储,底层数据块存在不同交换机不同服务器上,以保障数据不会丢失,官方给出的承诺是99.999999999%,晕么,各位看官也别数了,我数过了是11个9,也就是说存储在S3上的数据,你可以非常放心,再也不用担心数据丢失问题了,可以理解为永远也不会丢失,S3呢,是按使用量和访问量来收取费用的,存储收取的费用非常低,所以非常适合存储一些大数据,例如日志,数据库备份等,在S3上需要创建一个一个bucket,就是桶的概念,来存储数据,单文件可以支持近50T左右,具体数据不记得了,想具体了解的可以上官网上去查数字,对于一般来说,是肯定够通用了,S3的出现解决了传统运维的很大问题,例如:你做一个应用架构,涉及存储方面,你需要存储选型,考虑未来扩展,如果1T数据,你可以用1块盘,10T用10块盘,100T,你估计要上专业存储设备了,而且可能是一个数据集群,然后就是随着数据的扩展,不断扩展,这是传统运维的思路,到了云时代,一切就变了,数据可以直接存储在S3上,你在做应用架构时,你不需要考虑存储的扩展了,可以直接用S3做你应用的后台存储,而且用S3的API可以灵活的开发出你所需要的任何应用,关于S3的介绍咱就介绍到这里,说着说着就多了,今天这篇文章主要还是解决我们日常使用S3面对的问题(仅从运维角度,开发时另一个维度)。

开始前我们先假设一个场景,你们公司在S3上存储创建了一个bucket,bucketI下有超过1000个文件,每个文件大小不一,你要问这种场景会不会出现,那我告诉你,这是很正常的,随着业务发展,文件你传一个,我拷一个,慢慢就积攒起来了,容量上升会导致费用的产生,如果有一天你老板说,小张呀,你帮我查下目前S3上都我们用到多少存储了,你就打开bucket一看,我靠,这么多文件,难道让小弟我一个一个加起来,如果量级这么大,我估计你用你一个计算器我估计要算10天,而且如果中间有个地方算错了,那么恭喜你,你可以从头再来算一次了,虽然是假设的场景,但也的确反映了现状,其实我们有更好的方法来解决这么问题,不是有API吗,我调用API写一个计算方法是不是可以,到这,我肯定的告诉你,绝对可以,好了,我们上代码:

 

代码总体来讲比较简单,就是调用每个文件的size进行相加的操作,注意key.size是用字节来计算的,最后要自己要换算成G或T的单位,要不一串数字,老板会看疯的,:(      今天就到这里了,后续我会针对S3日常对运维操作会连载几篇文章,让大家彻底对S3有一个了解,喜欢的朋友可以给点个赞,:)