现有小文件,数量几亿甚至上百亿,目录深度较深,数据量大概是100TB,采用哪种存储架构存储比较合适?

现有小文件,数量几亿甚至上百亿,目录深度较深,数据量大概是100TB。
不知道采用哪种存储架构存储比较合适,还得要考虑备份。

13回答

张鹏张鹏  高级技术主管 , 中国金融电子化公司-中小金融机构灾备服务中心
zhuhaiqianghacmpruigng等赞同了此回答
不能光考虑如何存,还要考虑存完之后,如何用,例如如何检索我知道一家国产公司的产品,做这方面还可以。私聊吧显示全部

不能光考虑如何存,还要考虑存完之后,如何用,例如如何检索
我知道一家国产公司的产品,做这方面还可以。
私聊吧

收起
 2019-07-11
浏览3475
aixchina 邀答
十一浪子十一浪子  存储工程师 , 业余
hacmp挚爱咖啡赞同了此回答
最佳方式就是采用对象存储。对象存储在解决海量文件的存储方面性能是非常优秀的。同时,目前的对象存储大多采用的是分布式架构,所以数据安全也有极大的保障。显示全部

最佳方式就是采用对象存储。对象存储在解决海量文件的存储方面性能是非常优秀的。同时,目前的对象存储大多采用的是分布式架构,所以数据安全也有极大的保障。

收起
 2019-07-11
浏览3365
fuzzycolefuzzycole  产品经理 , UMCloud
hacmp挚爱咖啡赞同了此回答
当然分布式对象存储是最好的解决方案啦。现在主流就是s3协议,好处就是既有公有云的s3也有基于私有云部署的s3,多个集群间也可做迁移和同步。显示全部

当然分布式对象存储是最好的解决方案啦。
现在主流就是s3协议,好处就是既有公有云的s3也有基于私有云部署的s3,多个集群间也可做迁移和同步。

收起
 2019-07-11
浏览3402
捕风者捕风者  系统架构师 , HoneycombData Inc.
AlexHH赞同了此回答
目录层数深:是 posix 文件系统的缺陷结构百亿小文件,通常需要CMS+Object对象存储架构 对象存储不在意 一个层级放多少,可以基本无限扩展考虑到怎么使用,可以自己定义一套数据库来做元数据,也可以使用内存管理模块给应用层提供API 之前给某万亿大行做了 一套,现在应该数PB ...显示全部

目录层数深:是 posix 文件系统的缺陷结构
百亿小文件,通常需要CMS+Object对象存储架构

对象存储不在意 一个层级放多少,可以基本无限扩展
考虑到怎么使用,可以自己定义一套数据库来做元数据,也可以使用内存管理模块给应用层提供API

之前给某万亿大行做了 一套,现在应该数PB 小文件了

收起
 2019-08-15
浏览2691
thiefqwthiefqw  存储工程师 , dell存储售前部门
wzpystcdc赞同了此回答
如果不看预算的话,商业的几个软件定义存储都有解决方案,甚至业内最高IOPS的,DELLEMC-POWERMAX也可以考虑。如果担心预算的话,可以看看微软的S2D解决方案,100TB并不多,可以全部上NVME,有非常好的IOPS表现,成本也非常低...显示全部

如果不看预算的话,商业的几个软件定义存储都有解决方案,甚至业内最高IOPS的,DELLEMC-POWERMAX也可以考虑。
如果担心预算的话,可以看看微软的S2D解决方案,100TB并不多,可以全部上NVME,有非常好的IOPS表现,成本也非常低

收起
 2019-07-12
浏览3045
wzpystcdcwzpystcdc  研发工程师 , 某公司
可以用分布式对象存储,开源的ceph就可以实现这些要求。显示全部

可以用分布式对象存储,开源的ceph就可以实现这些要求。

收起
 2021-02-20
浏览483
raphlguraphlgu  项目经理 , 旭升
我说一下我们的使用环境和效果,仅供参考。 1、我们的使用环境。 容量。每个项目盘,50TB左右项目文件。 深度。最深深度十几层,平均深度也有6~7层。 大小。70%左右5~10MB文件,50%左右1~5MB文件 操作系统。Windows Server 2012 R2。因为项目文件权限管理采用微软NTFS权限 ...显示全部

我说一下我们的使用环境和效果,仅供参考。

1、我们的使用环境。

  • 容量。每个项目盘,50TB左右项目文件。
  • 深度。最深深度十几层,平均深度也有6~7层。
  • 大小。70%左右5~10MB文件,50%左右1~5MB文件
  • 操作系统。Windows Server 2012 R2。因为项目文件权限管理采用微软NTFS权限
  • 业务特点。90%读,10%写。其中并发访问量不小于1100+

2、我们的实际使用效果:

  • 存储。FC SAN绝对要好于NAS。无论是10Gbps还是25Gbps的NAS。
  • 文件服务器。物理机,VMware虚拟机,区别不大

我们使用经验:

  • 小文件数量多,文件深度较大情况下,如果有一定并发访问量,同时是即时性较强的业务数据。SAN的表现非常好。这是因为 SAN块协议是一个专用存储协议,能够更好处理IO命令,并通过专用SAN网络传输,不受当前环境的影响。
  • NAS的速度受到2个因素影响:NAS本身的文件系统、NAS的传输网络(以太网)。我们觉得NAS文件系统首先并不是为小文件而设计,因此没有海量小文件这方面的优势。另外NAS文件系统的优势在于丰富的数据管理功能,而不是性能。现在NAS厂家,如果免费提供的功能少于20+,都不好意思和用户讲。最后,我们的多年经验就是NAS依赖的以太网不是一种IO传输网络,在极端情况下会发生异常表现的几率很高,特别是TCP传输这层,过于复杂的可靠性保障机制,意味牺牲性能在所不惜,其实并不适合要求很高的IO场景。
收起
 2021-02-03
浏览829
SeaskyblueSeaskyblue  售前技术支持 , NetApp
一方面看存储产品参数,最重要的还是实测。100TB容量不算大,所以楼主的业务存储选型难度在于海量的小文件和目录深度。 NAS是一个最直觉的存储选项。NAS存储选型建议如下1、看厂商公布的NAS存储产品单一命名空间下支持的容量和文件数量,然后做一个简单的除法,就可以推断出NAS...显示全部

一方面看存储产品参数,最重要的还是实测。
100TB容量不算大,所以楼主的业务存储选型难度在于海量的小文件和目录深度。

NAS是一个最直觉的存储选项。NAS存储选型建议如下
1、看厂商公布的NAS存储产品单一命名空间下支持的容量和文件数量,然后做一个简单的除法,就可以推断出NAS存储对小文件的支持程度。当然能够实测是最好的。
2、首选集中式NAS存储,分布式NAS慎选。因为分布式存储目前只有副本和纠删码两种数据保护技术。副本对小文件性能好,但是3副本带来的容量放大,直接反应在采购成本和运维成本上。纠删码的容量效率高,但是对小文件的读写性能总是要做取舍,大多数情况下都是采用利用归并写来打包小文件提高写性能,代价就是读性能的损失。
3、可选项:如果有数据备份需求,需要考察存储自身是否支持海量小文件NAS备份。
4、高目录深度带来的访问性能下降,在当下还是NAS文件系统自身的技术限制,不是采用高端硬件就能彻底解决的。对于这样的业务场景,要么通过业务规划让目录深度变小,要么就是选用对象存储,因为对象存储是没有目录深度的概念的。

对象存储的技术特性适合海量小文件的业务场景,对象存储选型建议:
1、只能通过API来访问对象数据(需要业务端的适配)。
2、不适合频数据需要繁修改的业务。
3、避坑建议:最好通过测试来验证对象存储一个bucket,在性能不出现大幅下降前提下,能够实际存储的小文件数量。相信我,这是一个巨坑。
4、可选项:数据备份。对象存储是通过开启版本功能和bucket复制功能来近似实现数据备份。但是大多数情况下是依靠对象存储自身架构来实现更高的数据持久性保障,而不做数据备份。毕竟,对象存储更多保存的是很少变化的数据。

收起
 2020-12-06
浏览1118
采用分布式对象存储方案,当然选型测试最好验证一下小文件的性能平稳性,有些基于CEPH开源没有做改造的产品,这方面其实可能还不如NAS显示全部

采用分布式对象存储方案,当然选型测试最好验证一下小文件的性能平稳性,有些基于CEPH开源没有做改造的产品,这方面其实可能还不如NAS

收起
 2019-08-25
浏览2615
tang237294066tang237294066  存储架构师 , 某保险公司
对象存储,好用,还不用考虑备份的问题。显示全部

对象存储,好用,还不用考虑备份的问题。

收起
 2019-08-07
浏览2687

提问者

colins系统工程师, 金融行业

问题状态

  • 发布时间:2019-07-10
  • 关注会员:15 人
  • 问题浏览:9623
  • 最近回答:2021-02-20