0. What is Object Storage
kv存储，但value 是非结构化数据（文件）
键值存储（KV Storage）。用于存储非结构化数据的键值存储，有一个特殊的名字，叫对象存储（Object Storage）。
它和结构化数据的键值存储，实现机制上往往有极大的差异。对象存储的 Key，看起来也像一个文件系统的路径（Path），但仅仅是像而已。
对于对象存储来说，Key 中出现的 “/” 字符，只是一个普通字符。在对象存储中，并不存在目录（Directory）这样的概念。
既然对象存储是一个键值存储，就意味着我们可以通过对 Key 做 Hash，或者对 Key 按 Key Range 做分区，都能够让请求快速定位到特定某一台存储机器上，从而转化为单机问题。
这也是为什么在数据库之后，会冒出来那么多 NoSQL 数据库。因为数据库和文件系统一样，最早都是单机的，在伸缩性、性能瓶颈（在单机数据量太大时）、可靠性、可用性上遇到了相同的麻烦。
NoSQL 数据库的名字其实并不恰当，它们更多的不是去 SQL，而是去关系（我们知道数据库更完整的称呼是关系型数据库）。有关系意味着有多个索引，也就是有多个 Key，而这对数据库转为分布式存储系统来说非常不利。
七牛云存储的设计目标是针对海量小文件的存储，所以它对文件系统的第一个改变也是去关系，也就是去目录结构（有目录意味着有父子关系）。所以七牛云存储不是文件系统（File System），而是对象存储（Object Storage）。
蛮多七牛云的新手会问，为什么我在七牛的 API 中找不到创建目录这样的 API，根本原因还是受文件系统这个经典存储系统的影响。
1. 为什么不把文件存在 web 服务器上
系统设计时，经常遇到需要上传文件的场景。为啥不直接把文件上传到web服务器上，为啥要存在对象存储里？
为了Scale。包括：
- 磁盘空间scale
比如一天几T的上传，放web服务器没法扩展，因此要单独提一个存储service出来； -
针对海量数据的存储优化：sharding解metadata爆炸；使用Erasure code提高存储利用率
单独提一个存储service出来后可以针对海量数据做优化。例如传统基于小块的文件系统不适合存大量数据、会metadata爆炸，而Object Storage在file systems之上加了一层分治sharding；
image.png
传统存储没有冗余容错，而类似HDFS用三副本又太浪费了，Object Storage可以针对性的做空间利用率优化，例如换了一种冗余方案（Erasure code）达到更大的磁盘利用率。
image.png
- 服务器运行时资源scale
上传、下载文件都占用服务器资源，包括：- web服务器连接数限制
但是这个其实是可以改可以调参的，参考单服务器最大tcp连接数及调优汇总、如何实现单服务器300万个长连接的？ - IO资源占用（磁盘IO、网络IO、网卡带宽限制）
上传、下载都需要IO，如果量大IO达到瓶颈，会影响正常业务请求的处理。IO瓶颈还可能导致CPU飚高 - 会不会影响虚拟内存或者提高内存page fault？不清楚
- web服务器连接数限制
2. 结论
- 如果做个小系统，不需要考虑上传的scale，完全可以上传到web服务器
- 为什么把前端静态文件发布到对象存储云服务？空间上没有瓶颈，个人理解这么做的好处是：
方便分压：帮web服务器节约运行时资源（主要是磁盘IO、网络带宽）
方便缓存。“此外，独立的域名也方便我们在代理服务层做动静分离，以便提升静态请求的处理速度。”
infra复用，例如对象存储支持CDN加速，省了自己给自己的网站域名搞cdn加速了
针对客户端（浏览器）优化
不传cookie;浏览器对域名有并发连接数限制
https://blog.csdn.net/scorpio3k/article/details/53020270
3. 对比其他存储，供选型参考
对象存储vs分布式文件系统（如hdfs)
38 | 文件系统与对象存储
对象存储=用于存储非结构化数据的KV存储
对象存储这个名字仅仅是名字，不要太想对象两个字代表什么。对比hdfs:
-
本质是kv存储不是文件系统，没有目录的概念，不需要做这种全局数据的同步，因此易于sharding。
image.png hdfs是面向大文件做的设计（用增大文件大小解决元数据爆炸问题），这套架构存小文件还是会元数据爆炸
详见原文：
但关于 Hadoop 的 HDFS 实际上业界有不少误区。GFS 的设计有很强的业务背景特征，本身是用来做搜索引擎的。HDFS 更适合做日志存储和日志分析（数据挖掘），而不是存储海量的富媒体文件。因为：
第一，HDFS 的 block 大小为 64M，如果文件不足 64M 也会占用 64M。而富媒体文件大部分仍然很小，比如图片常规尺寸在几百 K 左右。有人可能会说我可以调小 block 的尺寸来适应。但这是不正确的做法，HDFS 的架构为大文件而设计的，不可能简单通过调整 block 大小就可以满足海量小文件存储的需求。第二，HDFS 是单 Master 结构，这决定了它能够存储的元数据条目数有限，伸缩性存在问题。当然作为大文件日志型存储（一般单个日志文件大小在 1GB 级别），这个瓶颈会非常晚才遇到；但是如果作为海量小文件的存储，这个瓶颈很快就会碰上。
第三，HDFS 仍然沿用文件系统的 API 形式，比如它有目录这样的概念。在分布式系统中维护文件系统的目录树结构，会遭遇诸多难题。所以 HDFS 想把 Master 扩展为分布式的元数据集群并不容易。
对象存储
非结构化数据的存储方式，最理想的绝对不是分布式文件系统。
文件系统只是桌面操作系统为了方便用户手工管理数据而设计的产物。服务端操作系统发展的初期，人们简单沿用了桌面操作系统的整套体系框架。
但从非结构化数据的存储开始，出现了分叉路口。对服务端体系架构来说，文件系统其实是一个过时的东西。
非结构化数据最佳的存储方式，还是键值存储（KV Storage）。用于存储非结构化数据的键值存储，有一个特殊的名字，叫对象存储（Object Storage）。它和结构化数据的键值存储，实现机制上往往有极大的差异。
对象存储的 Key，看起来也像一个文件系统的路径（Path），但仅仅是像而已。对于对象存储来说，Key 中出现的 “/” 字符，只是一个普通字符。
在对象存储中，并不存在目录（Directory）这样的概念。
既然对象存储是一个键值存储，就意味着我们可以通过对 Key 做 Hash，或者对 Key 按 Key Range 做分区，都能够让请求快速定位到特定某一台存储机器上，从而转化为单机问题。
这也是为什么在数据库之后，会冒出来那么多 NoSQL 数据库。因为数据库和文件系统一样，最早都是单机的，在伸缩性、性能瓶颈（在单机数据量太大时
对象存储vs结构化数据的kv存储
如何选用NAS(文件存储)、OSS和EBS(Elastic Block Store,块存储)
https://help.aliyun.com/document_detail/140812.html?spm=a2c4g.11186623.6.543.1bfc2f30UgVbT0
