抖音背后的存储之对象存储基本介绍
抖音背后的存储
假如通过仔细思考，设计了一个如图的架构;客户端我们肯定需要有一个，然后也要有账号，也要有评论服务;但核心的来说，像抖音这类AP都是UGC，就是用户生产内容的平台，所以重中之重我们的内容生产到推荐这一条链路;
这一条链路上，会有片源，也就是承接用户上传的内容，然后还有个审核服务，对这些内容进行合规的审核，最后这些内容会根据机器学习打上标签，通过各位同学历史观看兴趣通过推荐服务推荐到各位同学的手机上
这里小明对短视频生产/消费链路做了更细粒度分解，分成了如图的几个服务，首先第1步是片源服务，将用户上传的视频存起来，这个用户原始的视频我们叫源视频;然后会有转码服务，将源视频转为不同码率的视频，为什么需要转码呢，因为不同的客户端(如不同的手机电脑）型号，能接受的分辨率是不一样的，因此需要转码来适配，这里转码完后的也需要存储起来，以供后续客户端拉取;然后图下面还有个抽帧服务，将视频抽成不一样的侦，用于审核服务做审核，这里也需要有个存储把这些图片存储起来;最后就是推荐服务了，将对应视频推荐出去，然后客户端就可以来拉取观看啦;
单视频假设10MB:
转码3个码率:10MB
抽帧20张图片:1MB
总计:21MB，24个视频/图片
1000/S视频上传:
Day: 1730TB，20亿个视频/图片
Month: 51900TB,622亿个视频/图片
Year: 631450TB,7568亿个视频/图片
一块磁盘4TB:
Day: 432块盘
Month: 12960块盘
Year: 157680块盘
小明现在的当务之急，是寻找一个合适的存储，要求:
海量:从前面分析，这个存储系统一定要能够存储如此大的海量
易用:好的存储能够解放业务，让业务专注于业务逻辑开发
便宜:这么大的存储量，越便宜就越能省下宝贵的经费
那有没有这样的存储呢?
对象存储基本介绍
这里详细类比了各类存储，单机存储首先我们排除，数据量实在是太大了，单机肯定存不下，单机数据库同理。
那分布式数据库呢，现代的分布式数据库在容量和弹性上面都有很大进展，是否可以呢?答案也是No，因为分布式数据库只适合存储结构化or半结构化数据，什么是结构化数据呢，上过上面提到踝程的同学应该有印象，就是数据和数据之间有一定关系，如用户信息，一个用户会关联包括电话号码，性别等各种维度的信息，这些信息一般都是不超过KB级别的，超过MB级别就不适合使用数据库处理了;
唯一的选择就是分布式存储，分布式存储是针对海量存储场景特别设计的存储，能够存储海量的大数据;
刚刚对比还是比较抽象的，我们来更详细的对比HDFS和TOS的接口;
接口对于任何一种存储来说，都是最重要的表征，为什么呢，因为一种新的存储之所以提出来，是因为它在新场景下解决了其他存储很难解决的问题，针对这类场景提供了新的接口可大幅简化业务逻辑
