存量非结构化数据300TB，每年新增不超过100TB，文件数也不是海量，有必要从NAS转到对象存储吗？

首先成熟商业产品的对象存储稳定性没什么问题。
其次，这个就不该是从存储端决定的，而是从应用端，或者整个架构侧决定的事情。
如果是很少几个系统在用这个nas，那换不换都无所谓，但是如果是一个通用平台，承载大量复杂应用，那就需要通盘考虑。
存储是否能够双活，mount的软硬模式夯住的风险，扩容能力等等，都还是次要，两种都能通过技术手段解决。

对象存储和NAS从存储视角没太大差异，但是从应用视角或者架构视角完全是两回事。
对象存储是一个应用层http的服务，需要读写时，一条语句临时访问读写就行，nas是要mount盘的。
如果说整体云原生体系做的比较好了，这时不可变基础设施已经是基本要求，应用侧架构师根本不可能允许使用nas。一个版本的应用镜像，推出几十个容器，然后要手动给每个容器去固定宿主机去依次挂盘么？根本不可行的，只能是应用直接访问http对象服务。

再从运维侧看，银行业的应用复杂度，导致某些虚机动辄几十上百个挂载目录的互访情况，运维人员做扩容都不敢新建，只敢克隆，而在对象存储环境，运维只要针对一个服务进行维护就好了，根本不需要去关注每个客户端。现在的服务质量，很多时候要求应用动态扩容，挂载一大堆目录这种怎么扩？单独给它再做基础镜像么？

还是最核心一个观点，这个事，不是存储侧的事，是架构或者应用侧的事。

仅仅从数据量来说 没有必要，还得结合业务读场景看看，
1、不是海量说明小文件不多！！！
2、是否存在读瓶颈，大规模并发读，
2、1年总量100T增量 写应该不是问题。

没有瓶颈完全没有必要，对象分布式可以解决读并发。

1传统nas的弊端：首先Nas还是传统文件系统的结构，非结构化数据通常是大量的小文件，随着数据量的继续增长传统文件系统检索会变慢。第二300T数据如果是在线数据的规模可以说已经很大了，这些数据的备份历史数据查询管理是一个庞大的任务庞大的任务，即使是在线加离线300T也要考虑为这些数据做容灾高可用即raid和容灾的消耗，维护的成本可想而知。
2对象存储冗余性高：经我们调研和poc测试，对象存储如果使用纠删码的方案做数据冗余，可以提供至少75%的得盘率，而其其冗余性高于raid，以某厂商5节点12+4纠删码方案，得盘率75%但可提供四块不在位于不同节点的硬盘同时故障或者至少一个节点故障，站点容灾对象存储支持双活，是比较好的非结构化数据存储的方案。
3对象存储的新特性：天然支持http访问方式原应用开发改造的工作量小，对移动端开发友好。自定义元数据等创新功能赋能新业务场景场景，更好服务有关联的业务系统。
4 对象的劣势：它是一种成本控制更好的方案不太追求性能性能，频繁修改的业务还是适合结构化的方案。