这是一个创建于 2334 天前的主题，其中的信息可能已经有所发展或是发生改变。
服务器上有不少 10M 左右的小文件（ 5M 到 15M 之间居多），目前用 10M 的某云带宽，用户量并不大，正常是够用的，只有高峰期有点拥堵。
如果改用对象存储的话，要重新改写文件上传 /下载的系统，一方面增加工作量，另外也考虑到一旦用了第三方的存储服务，怕是以后再也难以转回自建的文件存储系统了。自建存储在路径、权限、访问控制等方面和第三方的对象存储差别比较大，需要改动的地方不少。
目前考虑的 2 种方案：
方案 1、就是使用对象存储，彻底代替自建的文件存储，以后只管买存储包就行。
方案 2、针对高峰拥堵的问题，毕竟不是上百兆的大文件下行，不会堵很久，先临时增加带宽 ，另外买一点 CDN。
总的文件存储大小将近 1TB，高频访问的部分大约 1% ~2% 的比例，以后大约也还是会维持这个比例，大家建议用方案 1，还是方案 2，综合性价比更优？
如果改用对象存储的话，要重新改写文件上传 /下载的系统，一方面增加工作量，另外也考虑到一旦用了第三方的存储服务，怕是以后再也难以转回自建的文件存储系统了。自建存储在路径、权限、访问控制等方面和第三方的对象存储差别比较大，需要改动的地方不少。
目前考虑的 2 种方案：
方案 1、就是使用对象存储，彻底代替自建的文件存储，以后只管买存储包就行。
方案 2、针对高峰拥堵的问题，毕竟不是上百兆的大文件下行，不会堵很久，先临时增加带宽 ，另外买一点 CDN。
总的文件存储大小将近 1TB，高频访问的部分大约 1% ~2% 的比例，以后大约也还是会维持这个比例，大家建议用方案 1，还是方案 2，综合性价比更优？
 |
1
denghongcai 2018-07-04 21:38:32 +08:00  1
方案 1 吧，对象存储+CDN。自建存储的稳定性，读写效率都不会特别好的，最重要的是以后扩展也麻烦。
|
 |
2
EsWann 2018-07-04 21:45:40 +08:00 via Android 1
同建议对象存储，以后用户量起来了之后，带宽绝对比对象存储贵，可靠性也比自建较强
|
 |
3
night98 2018-07-04 21:56:05 +08:00 1
自建出问题老板找你，对象存储出问题你还能甩锅，自己看着办。
|
 |
4
odirus 2018-07-04 22:04:55 +08:00 via Android 1
用对象存储。
资费便宜，运维起来省力气，用户体验也会比较好。 但数据库里面一定要有原始文件信息，比如某个业务有哪些文件，这些文件分别存放到哪个 bucket 下的哪个路径，以后迁移的时候才有底。 我们库里面就是用的自定义文件协议，返回给用户的时候就结合配置文件进行转换，即使切换服务商问题都不大。 |
|
5
odirus 2018-07-04 22:07:53 +08:00 via Android 1
路径问题某云是可以解决的，相当于用前缀模拟文件夹，权限问题可以分别设定各自的权限，也能继承上级目录（前缀）的权限，所以基本能满足。
|
Select Language