海量小文件存储共享解决方案

合集下载

华为OceanStor 100D对象存储解决方案介绍

华为OceanStor 100D对象存储解决方案介绍
• 能够在短时间内处理海量数据,为 业务提升客户体验
• 支持分支机构跨地域部署 • 支持数据同步和共享
……
热数据 温数据
冷数据
生产存储
本地备份
异地备份
数据保护、备份资源池
• 存储服务不中断、备份/归档数据不丢失 • 法规、审计的要求,数据需长时间保存,
系统规模增长时,能够灵活扩展 • 重删技术,最小化建设投资 • 部署和维护简单
10x性能提升
真正实现性能、容量线性增长
性能、容量同时提升
经济高效
性能及利用率同时提升,提供最优性价比云存储资源池
小对象在线聚合
Erasure Code
智能流控
对象重删
离线或纸质归档
隔日/隔周审批
票据、身份、合约等影像数据
传统存储架构
从隔日/隔周升级为实时在线 从本省授权升级为跨地域审批
业务连续性要求从半小时级提升为 “零”中断,TCO下降
实时在线
全生命周期存放
二三类账户 录音录像 APP
生物识别 …
票据 客户信息 会计凭证 交易过程数据 ….
对象接口数据平面
AI应用兴起,海量数据让自动驾驶走入生活
温冷数据分级归档
• 一次写,很少读,数据量巨大 • 分级归档,可离线保存 • 超长的数据生命周期,硬件设备可
更替、可更换、可升级 • 指数级的数据增长不能带来指数级
的费用投入
OceanStor 100D分布式对象存储
最大企业级商用存储集群 4096节点,EB级,弹性伸缩
更大
更快
OceanStor
业务0宕机
超声波传感器 GPS
激光雷达 毫米波雷达
摄像头
数据导入

企业云存储解决方案

企业云存储解决方案

企业云存储解决方案在现代数字化时代,企业面临着海量数据的管理和存储挑战。

传统的本地存储方式已逐渐无法满足企业数据增长的需求,因而越来越多的企业开始转向云存储解决方案。

企业云存储解决方案是一种基于云计算技术的分布式存储解决方案,能够提供弹性、安全、可靠的存储服务,帮助企业更好地管理和利用数据资源。

优势与特点1. 弹性扩展企业云存储解决方案具有弹性扩展的特点,可以根据企业的实际需求动态调整存储容量,从而降低了成本和资源浪费。

无论是小型企业还是大型企业,都可以根据业务需求灵活扩展存储容量,实现存储资源的优化利用。

2. 多地备份为了确保数据的安全性和可靠性,企业云存储解决方案通常提供多地备份功能。

通过将数据存储在多个地理位置的服务器上,可以避免单点故障导致数据丢失的风险,保障数据的完整性和持久性。

3. 数据加密企业云存储解决方案一般会采用加密技术来保护数据的安全性。

通过对数据进行加密处理,可以有效防止数据泄露和非法访问,提高数据的保密性和隐私性,符合企业的合规要求。

4. 高可靠性相比传统的本地存储设备,企业云存储解决方案具有更高的可靠性。

云存储提供商通常会部署复杂的故障转移和容灾机制,确保数据在发生硬件故障或灾难性事件时仍能保持可访问性。

应用场景1. 多设备协作随着企业员工办公设备多样化,基于云存储的文件共享和协作成为了重要需求。

企业云存储解决方案可以提供统一的数据存储和共享平台,方便员工在不同设备上实时协作和访问数据。

2. 大数据分析随着大数据技术的普及,越来越多的企业需要对海量数据进行分析和挖掘。

企业云存储解决方案提供了可扩展的存储资源和强大的计算能力,为企业的大数据分析提供了坚实的基础。

3. 灾备和容灾灾备和容灾是企业信息化建设中至关重要的一环。

企业云存储解决方案可以帮助企业建立健全的灾备和容灾机制,确保数据在灾难事件中能够及时恢复,并保障业务的持续性和稳定性。

总结企业云存储解决方案是企业信息化建设的重要组成部分,能够帮助企业降低成本、提高效率,更好地应对数据管理和存储的挑战。

海量数据的高效存储与处理方法总结

海量数据的高效存储与处理方法总结

海量数据的高效存储与处理方法总结随着科技的快速发展和互联网的普及,我们生活中产生的数据量呈现出爆炸性增长的趋势。

这些海量数据对于企业、科研机构以及个人来说,都是一种宝贵的财富。

然而,如何高效地存储和处理这些海量数据成为了亟待解决的难题。

本文将总结一些海量数据的高效存储与处理方法,希望能为读者提供有价值的参考和指导。

一、高效存储方法1. 分布式文件系统(DFS)分布式文件系统是针对海量数据存储问题提出的一种解决方案。

它将海量数据切分成多个小文件,并存储在不同的物理设备上。

通过这种方式,可以充分利用多台机器的存储能力,提高整体的存储效率。

分布式文件系统具有高可用性、高可靠性和高性能的特点,常用的分布式文件系统包括Hadoop Distributed File System (HDFS)和Google File System(GFS)等。

2. NoSQL数据库NoSQL数据库是非关系型数据库的一种,相对传统的关系型数据库具有更好的可扩展性和高性能。

它们适用于存储和处理海量数据,能够实现数据的快速读写和高并发访问。

常见的NoSQL数据库包括MongoDB、Cassandra和Redis等,它们采用键值对、文档存储或列族存储等方式,提供了灵活的数据模型和丰富的查询功能。

3. 数据压缩技术海量数据的存储离不开对数据进行压缩的技术支持。

数据压缩可以减少存储空间的占用,提高存储效率。

目前,常用的数据压缩算法包括Lempel-Ziv-Welch(LZW)算法、Gzip和Snappy等。

这些算法具有压缩率高、压缩速度快的优点,可以实现对海量数据的高效存储。

二、高效处理方法1. 并行计算并行计算是一种常用的处理海量数据的方法。

它通过将任务分解成多个子任务,并分配给不同的处理器或计算节点进行并行计算,从而加快数据处理的速度。

常见的并行计算框架包括MapReduce、Spark和MPI等。

它们能够将数据分布式地处理在各个计算节点上,充分利用计算资源,提高数据处理的效率。

[参考论文]海量小文件存储方法论文

[参考论文]海量小文件存储方法论文

海量小文件存储方法论文摘要:Hadoop目前还没有一个系统级的通用的解决HDFS小文件问题的方案。

第4章提到的Hadoop自带的解决方案各有优缺点,通用技术方案应用到不同环境时效果也不尽相同,针对具体应用场景提出的解决方案具有一定局限性,对其他应用系统具有借鉴意义但并不能搬用。

针对Hadoop中海量小文件存储优化的问题还值得进一步的深入研究。

1 引言Hadoop[1]是由Apache基金会研发的能够对海量数据进行分布式处理的基础框架,是海量数据存储与处理的理想平台。

然而由于Hadoop采用流式方式读写文件,对于大文件处理效率极高,但对小文件处理效果并不是很好。

当处理如气象数据这种海量小文件时,Hadoop的优势并不能展示出来,故需要对小文件的存储进行优化。

2 HDFS的系统架构HDFS是Hadoop的分布式文件系统,其具有高容错性的特点,设计用来部署在低廉硬件上,能够提供极高的数据吞吐量,适合那些有着超大数据集的应用程序[2],因而成为了云存储平台的代表性系统。

HDFS采用主从架构,由一个名称节点和多个数据节点组成。

名称节点是HDFS的主服务器,主要负责管理元数据和数据块、持久化元数据、处理请求及管理数据节点,数据节点主要负责数据块的读写、向名称节点报告状态及执行数据的流水线复制。

客户端通过与名称节点和数据节点的交互来访问整个文件系统。

3 HDFS处理海量小文件存在的问题HDFS设计用来对大文件进行流式存储,在处理小文件时会产生一些问题[3]。

小文件是指文件大小小于HDFS块大小(默认为64MB)的文件,大量的小文件会严重影响Hadoop的性能及其扩展性。

首先,海量小文件大量耗费名字节点的内存。

每个小文件作为一个块存储,海量数据块的元数据信息会占用大量内存,这样名称节点的内存容量会严重制约集群的扩展。

其次,海量小文件的存取效率低。

大量小文件写入HDFS时需频繁请求名称节点分配数据块,读取大量小文件时需频繁请求数据节点以获取文件,严重影响了名称节点和数据节点的I/O性能。

Hadoop中海量小文件的处理分析

Hadoop中海量小文件的处理分析

Hadoop中海量小文件的处理分析摘要:论文将通过具体设计,提出一个行之有效的处理分析hadoop中海量小文件的应用方法。

关键词:hadoop 海量小文件索引算法中图分类号:tp391 文献标识码:a 文章编号:1672-3791(2012)10(a)-0013-01目前,国内外很多大型企业和机构都采用hadoop技术处理规模巨大的数据,但是如何高效稳定地处理好伴随大数据而产生的各类海量小文件就成了一个决定系统稳定、数据可靠与否的重要依据。

本文将根据个人研究浅谈一下海量小文件的处理分析。

1 hadoop中海量小文件处理存在的问题1.1 海量的小文件堆积造成系统节点内存不足我们知道在hdfs整合数据时,是将数据分割成若干块存储在多个数据节点上的。

因此,hdfs存储的大文件都是被分成许多块分摊出去的。

由此,不可避免的就会产生很多尺寸小,甚至比hadoop应用中默认分块小很多的小文件,这些文件被认为是不可以分块的而被保留在了各个数据节点上。

当这些海量小文件达到一定规模后就会淹没数据节点的内存从而造成硬件内存供应不足的现象。

1.2 海量小文件的检索效率低由于hadoop的分布式存储对象是海量的廉价计算机,因此存储系统中数据节点的内存限制也对可存放的文件数量造成了制约,从而增加了系统管理的难度。

一但某一数据节点上出现了海量小文件,文件的检索效率就会急剧下降,当小文件的数量达到一定规模后,甚至可能导致数据节点崩溃。

2 hadoop中海量小文件的处理分析方法2.1 构建海量小文件分析处理架构文件→合并→建立索引→分布存储。

将数据节点中的数据分成两种块形式。

一种是存储小文件的文件块,一种是存储索引的检索块。

本架构的核心主要是处理分布式存储小文件的单位数据。

主要实现的一个过程是,先将数据节点上的海量小文件合并,写入数据节点,再利用map/reduce对存储在块中的小文件分类并创建索引,然后将索引分布式存储在数据节点上。

存储服务器解决方案

存储服务器解决方案

存储服务器解决方案引言随着数字化时代的到来,数据的存储需求不断增长。

无论是个人用户还是企业机构,都面临着海量数据的存储与管理的挑战。

为了满足这一需求,存储服务器解决方案应运而生。

本文将介绍存储服务器的概念、特点以及如何选择适合自己需求的存储服务器解决方案。

存储服务器概述存储服务器是一种专用的服务器设备,用于存储和管理大量的数据。

它通常采用硬盘阵列(RD)来提供高可靠性和高性能的存储服务。

存储服务器不仅可以作为文件服务器,提供文件共享服务,还可以作为数据库服务器、备份服务器等,满足不同应用场景下的存储需求。

存储服务器的特点1. 容量大存储服务器通常具有较大的容量,可以满足大规模数据的存储需求。

现代存储服务器支持热插拔硬盘,可以根据需求随时扩展存储容量。

2. 高可靠性存储服务器采用硬盘阵列(RD)技术来提供数据的冗余备份和快速恢复功能,从而提高数据的可靠性。

常见的RD级别包括RD 0、RD 1、RD 5等,用户可以根据需求选择适合自己的RD级别。

3. 高性能存储服务器通常配备多个硬盘,采用并行访问的方式提供高性能的数据存取速度。

此外,一些存储服务器还支持缓存技术,通过提供缓存加速存储操作,提高系统的响应速度。

4. 网络存储存储服务器一般支持网络存储协议,如NFS、SMB/CIFS等,可以方便地提供文件共享服务,实现多用户访问和文件传输。

5. 易于管理现代存储服务器通常配备管理工具,可以方便地进行存储空间的管理和监控。

管理员可以通过管理工具进行磁盘阵列的配置、监控磁盘状态、执行故障恢复等操作,提高管理效率。

选择存储服务器解决方案的因素1. 存储需求首先,需要明确自己的存储需求。

根据数据的容量、访问模式、性能要求等因素,选择适合自己需求的存储服务器。

如果需要高性能的存储解决方案,可以选择配备SSD(固态硬盘)的存储服务器。

2. 可扩展性其次,考虑存储服务器的可扩展性。

随着数据的不断增长,存储需求也会增加,因此存储服务器需要具备良好的可扩展性,可以随时扩展存储容量。

海量数据问题的处理-六种解决思路

海量数据问题的处理-六种解决思路

海量数据问题的处理-六种解决思路1. 处理海量数据问题的四板斧分治基本上处理海量数据的问题,分治思想都是能够解决的,只不过⼀般情况下不会是最优⽅案,但可以作为⼀个baseline,可以逐渐优化⼦问题来达到⼀个较优解。

传统的归并排序就是分治思想,涉及到⼤量⽆法加载到内存的⽂件、排序等问题都可以⽤这个⽅法解决。

适⽤场景:数据量⼤⽆法加载到内存技能链接:归并排序哈希(Hash)个⼈感觉Hash是最为粗暴的⼀种⽅式,但粗暴却⾼效,唯⼀的缺点是耗内存,需要将数据全部载⼊内存。

适⽤场景:快速查找,需要总数据量可以放⼊内存bit(位集或BitMap)位集这种思想其实简约⽽不简单,有很多扩展和技巧。

⽐如多位表⽰⼀个数据(能够表⽰存在和数量问题),BloomFilter(布隆过滤器就是⼀个典型的扩展),在实际⼯作中应⽤场景很多,⽐如消息过滤等,读者需要掌握,但对于布隆过滤器使⽤有⼀些误区和不清楚的地⽅,读者可以看下⾯这篇博客避免这些性能上的误区。

适⽤场景:可进⾏数据的快速查找,判重技能链接:布隆过滤器使⽤的性能误区堆(Heap)堆排序是⼀种⽐较通⽤的TopN问题解决⽅案,能够满⾜绝⼤部分的求最值的问题,读者需要掌握堆的基本操作和思想。

适⽤场景:处理海量数据中TopN的问题(最⼤或最⼩),要求N不⼤,使得堆可以放⼊内存技能链接:排序算法-Heap排序2. 常见场景题:谈⼀谈,分布式集群中如何保证线程安全?请你设计⼀种⽅案,给每个组分配不同的IP段,并且可以快速得知某个IP是哪个组的?如何将⼀个⽂件快速下发到100万个服务器这⾥有1000个任务,分给10个⼈做,你会怎样分配,先在纸上写个最简单的版本,然后优化。

全局队列,把1000任务放在⼀个队列⾥⾯,然后每个⼈都是取,完成任务。

分为10个队列,每个⼈分别到⾃⼰对应的队列中去取务。

如果让你来开发微信抢红包,说说你的思路是怎么样的?可能遇到什么问题,你会怎么解决悲观锁,乐观锁,存储过程放在mysql数据库中。

海量小文件的开源存储方案选型建议

海量小文件的开源存储方案选型建议

海量⼩⽂件的开源存储⽅案选型建议随着AI技术的发展,在智能安防、智能制造等众多领域,都⾯临着海量图⽚⽂件的存储问题。

开源领域为了解决海量⼩⽂件问题也是伤透了脑筋,这些年冒出了⼤量的开源分布式存储⽅案,都号称⾃⼰可以解决海量⽂件问题。

结果就是不少企业⽤户贸然上线,刚开始数据量不⼤好像还不错,⼀旦数据量上来,才发现真的只是“号称”。

然后⼜尝试其他⽅案,⽽存储⽅案的更换并不容易,上百TB数据的迁移动辄数⽉、⼯程浩⼤。

⽽各种开源⽅案之间⼜缺少必要的迁移⼿段,过程困难不必赘述,单说在迁移过程中数据是否会丢失都很难评估。

为帮助企业⽤户少⾛弯路,在这⾥我给⼤家介绍⼀下我所了解的⼏款开源分布式存储的优缺点,供参考。

由于并不是每个开源系统都充分了解,最新的状态也不⼀定能实时跟进,不当之处还请多多指正。

HDFSHDFS是Hadoop底层的分布式存储系统,NameNode负责⽂件元数据管理和⽂件分布管理,DataNode负责⽂件数据分⽚的存储。

⽂件按照固定⼤⼩切⽚(4MB)存储,NameNode负责每个数据切⽚的分配和位置管理。

HDFS在存储容量上可以很好地满⾜扩展性需求,对于语⾳或者视频等较⼤的⽂件存储也可以满⾜性能要求。

但所有⽂件的访问均需要通过NameNode进⾏查询,对于海量⼩图⽚场景,由于NameNode需要记录⼤量的数据存储信息,NameNode将成为整个系统的瓶颈。

HDFS设计之初完全是为了Hadoop⼤数据分析使⽤,并不是作为⼀个独⽴的存储系统考虑,所以HDFS⽆法脱离Hadoop环境单独部署。

接⼝上也采⽤了私有的接⼝设计,不具备通⽤性和标准性,未来商业产品⽀持HDFS接⼝作为存储的可能性⾮常⼩。

HDFS缺乏多租户、纠删码(据称2017年底特性提供,但稳定性待验证)、配额管理、数据快照、跨数据中⼼容灾等重要的存储特性,⽆法作为⼀个普适性的企业存储使⽤,仅适合专⽤于⼤数据分析存储。

FastDFSFastDFS是另⼀个开源分布式⽂件系统,由Tracker Server和Storage Server构成,Tracker Storage分成多个Group,每个Group有2-3台服务器,数据在⼀个Group的服务器之间做冗余策略。

思科-XSKY 海量数据解决方案

思科-XSKY 海量数据解决方案

什么是思科-XSKY海量数据解决方案:基于思科 UCS 服务器以及 XSKY 分布式软件定义存储架构建立的高性能弹性存储系统数据解决方案。

完美支持各种存储类型, 在同一个存储结构中提供基于块存储,文件存储以及对象存储的数据服务, 满足业务对结构化, 非结构化和半结构化数据服务的存储需求。

什么是SKY 软件定义分布式存储架构:X-SKY 是一家专注于软件定义基础架构(Software Defined Infrastructure)业务的中国信息科技企业。

XSKY,将大型互联网架构运维经验、主流的开源技术、企业关键业务的最佳实践相结合,为客户提供高性能、高可靠性的软件定义存储产品以及存储混合云解决方案。

方案架构:方案组成思科 UCS C240服务器/3S3260海量存储服务器基于 XSKY 的软件定义存储解决方案基于思科和 XSKY 的联合专业服务和技术支持方案特性基于思科 UCS 服务器,更高的数据传输性能更低的总体拥有成本(TCO)和更高的性能广泛的应用场景多节点模式易于横向扩展(Scale Out)易于管理数据服务层存储引擎层硬件设备层卷跨集群备份卷云端归档集群状态控制强一致性协议数据智能路由数据一致性校验数据并行恢复Block持久化X86标准服务器SAS/SATA/SSDPCl-e SSD10GE/InfiniBandFiber Channel延时删除资源恢复实时归并延时归并应用场景:硬件组成:2 x Nexus 9236C (管理交换机可选)2~10 x C3260(双节点) 作为存储节点2 x Intel® Xeon™ E5 2660128 GB DDR4 Memory 24 x 6 TB HDD 4 x 800 GB SATA SSD 2 x 240 GB Boot1 x 40 Gb QSPF28 双口 NIC 1 x 12G SAS HBA应用场景行业场景虚拟化支持:KVM、XEN、Hyper-V、VMware、Docker、Openstack(Cinder,Glance, Nova)数据库兼容性:Oracle、Oracle RAC、SQL Server、MySQL 2 x Intel® Xeon™ E5 2630或以上96GB DDR4 Memory 8 x 6TB SATA HDD 2 x 800 GB SATA SSD 2 x 240 GB Boot1 x 10 Gb mLOM VIC dual port 1 x UCSC-SAS12GHBA3~13 x C240 M4L(12 LFF)作为存储节点2 x Nexus 92160YC-X (管理交换机可选)配置48 x 10Gbps SFP+每节点每节点总结:思科 UCS 统一计算系统和 XSKY 分布式融合存储软件联合为客户提供满足不同存储结构和数据结构需求的海量数据服务,让用户集中关注数据服务带来的业务回报, 而不是数据管理本身。

海量小文件内容管理解决方案

海量小文件内容管理解决方案

海量小文件内容管理解决方案1.背景随着现代信息化技术的飞速发展,互联网及企业内部数据也在迅猛剧增,数据规模越来越大;其数据类型也多种多样,大致分为结构化数据、半结构化数据、准结构化数据、非结构化数据等类型,据统计,大部分企业内部非结构化数据和半结构化数据占该企业所有数据总量的80%-85%,其中大部分为文档、文本、图片、网页文件等小文件,这些小文件蕴含着巨大的价值,迫使企业对这些小文件进行收集、整理、清洗、抽取、存储、检索、挖掘等全生命周期的管理和深度利用。

传统企业对小文件的管理大多没有集中管理,仅零散存放在关系型数据库和文件系统中,其中关系型数据库存放非结构化数据的描述信息,而系统存放非结构化数据的原始文件;;直接以通过部署文档服务器来将企业重要文档文件存放在企业内部服务器中,无法对这些文件在文件内容层面上进行管理和挖掘分析。

2.面临问题目前传统企业对文档等小文件的存储和管理,主要面临如下问题:文档存储分散,无法将各业务系统的文档数据进行统一存放管理,产生了大量冗余数据;文档一般存储在企业内部系统中,无法保证跨地域访问的时效性;文档传输一般通过传统的FTP协议等方式进行网络传输,文档权限管理和权限划分繁琐;无法基于文档内容进行有效的管理和挖掘分析,无法形成行业化文档知识库;业务系统关系型数据库在处理大数据量查询和检索时系统效率低下,同时无法对文档数据进行实时的全文检索;对于日益增长的文档数据,管理难度越来越大,系统扩展性也越来越差。

3.解决方案XX公司针对目前企业对文档管理和使用上的痛点,自主研发出了海量文件内容管理系统dataFusion,可以很好的解决这一难题。

海量文件内容管理系统主要提供文档管理、文档预处理、全文检索、分享协同、安全/版权、流程管理等功能,实现了对非结构化数据管理和智能化应用。

该系统还提供灵活的文档分类管理功能,支持用户自定义组织方式,允许用户按照部门、主题等多个纬度来组织文档;支持灵活的文档共享,比如支持部门内和部门间的文档共享,而且支持基于项目、主题的共享协作。

GFS的名词解释

GFS的名词解释

GFS的名词解释近年来,随着大数据时代的到来,全球文件系统(Global File System,简称GFS)逐渐成为一个热门的话题。

它作为一种网络存储系统,被广泛应用于各个领域,包括科研、工业、商业等。

本文将对GFS进行详细解释,并探讨其在数据管理中的重要性。

GFS是一种分布式文件系统,其主要目标是提供高可用性、高性能、可扩展性和数据一致性的存储解决方案。

它不仅可以存储和管理海量的数据,还可以在多个服务器之间进行数据访问和共享。

与传统的本地文件系统相比,GFS更加适用于大规模的分布式计算环境。

在GFS中,数据被分割成固定大小的块,并存储在多个服务器上,以实现数据的冗余备份和故障恢复。

每个块都具有唯一的标识符,可以通过这个标识符在不同的服务器上进行访问和传输。

此外,GFS还采用了一种称为分布式锁的机制,以确保多个客户端对同一数据块的读写操作的一致性。

为了实现高性能和可扩展性,GFS采用了一种称为"切片(chunking)"的技术。

它将大文件分割成较小的数据块,并将这些块分布在多个服务器上。

当一个客户端需要访问这个文件时,它可以同时从多个服务器上获取不同的数据块,并在本地重新组装这些块,从而加快数据的读取速度。

此外,GFS还通过使用数据复制和删除等技术来提高系统的数据可靠性和性能。

在数据管理中,GFS的重要性不可忽视。

首先,GFS可以提供高可用性的存储服务,确保系统在硬件故障或网络中断时能够持续运行。

其次,GFS可以快速处理大量的数据,并支持并行计算和分布式处理。

这对于科学研究、工业生产和商业分析等领域来说,是非常关键的。

最后,GFS的数据一致性机制可以避免数据丢失或损坏,保证数据在多个服务器之间的一致性和完整性。

然而,虽然GFS具有许多优点,但也存在一些挑战和限制。

首先,管理和维护GFS需要一定的专业知识和技术支持。

其次,由于数据的分散存储和访问,数据的一致性和完整性可能面临一些挑战。

存储技术方案

存储技术方案

存储技术方案引言在当今信息化快速发展的时代,各种数据持续膨胀,大量企业和组织需要寻找合适的存储技术方案来存储和管理海量数据。

本文将介绍一些常用的存储技术方案,包括传统的存储方案和新兴的存储方案。

传统存储技术方案1. 本地存储本地存储是最基本的存储方式之一,它将数据存储在本地服务器或个人计算机上。

本地存储的优点是可靠性高,速度快,但容量有限,且容易受到硬件故障的影响。

一般适用于小规模组织和个人使用。

2. 网络附加存储(NAS)网络附加存储(NAS)是一种通过网络连接到计算机的存储设备。

NAS具有高容量、可靠性强和易于扩展等特点。

它可以通过网络提供文件共享和备份服务,适用于小型办公环境和家庭用户。

3. 存储区域网络(SAN)存储区域网络(SAN)是一种高速、高可靠性的存储技术方案。

它是通过专用网络连接服务器和存储设备,将存储设备映射成逻辑卷,并提供给服务器使用。

SAN可以提供高性能和可扩展性,适用于大型企业和数据中心使用。

新兴存储技术方案1. 云存储云存储是一种将数据存储在云平台上的存储技术方案。

云存储具有高可靠性、高可用性和高扩展性等特点。

它可以随时随地访问数据,无需担心硬件故障和数据丢失。

云存储适用于各种规模的企业和组织。

2. 对象存储对象存储是一种新兴的存储方式,它将数据存储为对象,并赋予每个对象唯一的标识符。

对象存储适合存储非结构化数据,如图片、视频和文档等。

它具有高可扩展性、低成本和数据冗余等特点,适用于大规模存储和分析场景。

3. 虚拟化存储虚拟化存储是一种将多个物理存储设备虚拟化为单个逻辑存储设备的技术方案。

它可以提供更好的存储利用率和灵活性,降低存储成本和管理复杂性。

虚拟化存储适合于虚拟化环境和私有云环境。

存储技术方案选择要考虑的因素选择合适的存储技术方案需要考虑许多因素,包括:1.容量需求:根据数据增长速度和预测的未来需求来选择合适的存储容量。

2.性能需求:根据工作负载和应用需求选择具有足够性能的存储方案。

一种海量小文件对象存储优化方案

一种海量小文件对象存储优化方案

收稿日期:2018-09-27 修回日期:2019-01-29 网络出版时间:2019-03-27基金项目:国家重点研发计划项目(2018YFB 1003300)作者简介:屠雪真(1998-),女,CCF 会员(98790G ),研究方向为云计算㊁分布式存储;黄震江,高级工程师,研究方向为分布式存储㊂网络出版地址:http :// /kcms /detail /61.1450.TP.20190327.1633.062.html一种海量小文件对象存储优化方案屠雪真1,黄震江2(1.河南大学计算机与信息工程学院,河南开封475001;2.南京中兴新软件公司,江苏南京210012)摘 要:在海量小文件存储场景下,传统分布式文件系统存在元数据服务器性能瓶颈㊁存储空间浪费严重㊁磁盘I /O 效率低等问题㊂业界主要采用小文件聚合的方法解决这个问题,但现有研究依赖于从聚合结构到小文件的二次映射和查表检索等传统方法㊂文中提出一种基于对象文件系统的海量小文件优化方案,根据局部性特征将小文件聚合为文件组,使用算法直接进行对象数据存储位置的分布与定位,将低效的查表检索方式改变为高效快捷的 计算检索”方式,这更加适合大规模分布式系统的设计;在客户端采用小文件数据大粒度预读技术,聚合小粒度I /O 为大粒度I /O ,提升了磁盘访问效率,使用页面热缓存和温缓存两级队列管理及识别热数据,并利用文件的局部性特征提升缓存命中率㊂实验结果表明,在海量小文件随机读写场景下性能提升50%左右㊂关键词:对象文件系统;小文件;元数据;聚合结构;查表索引;预读中图分类号:TP 31 文献标识码:A 文章编号:1673-629X (2019)08-0031-06doi :10.3969/j.issn.1673-629X.2019.08.006A Mass Small File Storage Optimization Scheme Based onObject File SystemTU Xue -zhen 1,HUANG Zhen -jiang 2(1.School of Computer and Information Engineering ,Henan University ,Kaifeng 475001,China ;2.ZTE Nanjing Corporation ,Nanjing 210012,China )Abstract :In the case of massive small file storage ,traditional distributed file system has problems such as metadata server performance bottleneck ,storage space waste and low disk I /O efficiency.The small file aggregation is mainly used to solve this problem in the industry ,but the existing research relies on traditional methods such as secondary mapping and table lookup retrieval from aggregation structure to small files.We propose a massive small file storage optimization scheme based on object file system.The small files are ag⁃gregated into file groups according to local features ,and the distribution and location of object data storage location are directly carried out by the algorithm ,which changes the inefficient look -up table search to an efficient and fast computation search ”.The method is more suitable for the design of large -scale distributed system.In the client ,the large -grained pre -ahead technology of small -file data is adopted to aggregate small -grained I /O into large -grained I /O ,which improves disk access efficiency.Queue management at both page hot cache and hot cache levels is used to identify hot data ,and cache hit ratio is improved by utilizing local feature of files.Experiment shows that the performance is improved by about 50%in the random reading and writing of small files.Key words :object file system ;small file ;meta data ;aggregate structure ;lookup table index ;read ahead0 引 言随着移动互联网和云计算技术的迅速发展,数字化信息呈爆炸式增长,特别是科学计算㊁高性能计算㊁Web 服务等应用领域中图片㊁邮件㊁文本㊁互联网档案㊁小视频等小文件正以指数级速度增长,使得存储系统面临着巨大挑战㊂传统的分布式文件系统是面向大文件数据存储与访问而设计的,在对海量小文件存储与访问时,存在元数据结构效率低㊁元数据服务器性能瓶颈㊁磁盘I /O 效率低㊁磁盘空间利用率低和网络通信延时高等一系列问题[1]㊂究其原因,主要是由元数据和数据两个方面造成的㊂(1)元数据占比高㊁访问频率高㊁耗时开销第29卷 第8期2019年8月 计算机技术与发展COMPUTER TECHNOLOGY AND DEVELOPMENT Vol.29 No.8Aug. 2019大㊂由元数据结构效率公式Pm=Sm/(Sm+Sd),其中Sm为元数据大小,Sd为有效数据大小,每个文件不论大小其元数据大小相同㊂显然,文件越小,元数据占比就越高,有效数据率就低㊂而且,依照pNFS的访问规则,读访问一个小文件会经历readdir㊁Open㊁layoutget㊁read和close五个步骤㊂其中read为数据访问,其余4个步骤均为元数据访问[2]㊂可见,当小文件数量巨大时,元数据处理就是系统性能瓶颈和存储效率低下的根本所在㊂(2)数据访问随机性强㊁I/O粒度小导致磁盘吞吐量低㊂磁盘仍是当前最主要的存储介质,由于磁盘访址的物理特性使得磁盘 善于顺序读,不善于随机读”和 善于大粒度IO,不善于小粒度IO”,这与海量小文件访问 大量随机小粒度I/O”的特点相对立,导致磁盘吞吐量低㊂虽然近年来SSD发展迅速,但是海量小文件场景的 大量随机小粒度I/O”依然会影响SSD的性能和寿命㊂因此,对海量小文件进行高效存储与访问支持,是存储系统必须面对的现实问题㊂文中介绍了近年来有关小文件优化的研究和系统实现,对基于对象文件系统的海量小文件优化方案的关键技术展开讨论,并给出实际运行结果及分析㊂1 相关工作业界对解决小文件存储访问的问题进行了大量研究,将小文件聚合成大文件再进行存储访问是主要思路㊂研究者也提出了其他一些优化小文件存储访问的技术,例如通过简化元数据结构减少元数据服务器负荷,利用缓存提高磁盘I/O效率并降低网络时延等㊂这些研究可分为两类:一类是针对特定问题的解决方案,根据特定的应用环境和存储需求,针对小文件带来的某个或某几个问题进行优化,侧重点各不相同,不具有通用性㊂例如Facebook的Haystacke[3]㊁淘宝的TFS(Taobao File-System)[4]等㊂另一类是通用解决方案,其中最广泛的就是文件合并技术㊂例如基于HDFS研制的海量小文件系统SMDFS[5],提供了基于目录聚合以及针对地理栅格数据金字塔结构局部优化的海量小文件存储方法㊂随着非结构化数据日益增长,具有高扩展性㊁数据存储位置灵活的基于对象接口的分布式文件系统(简称对象文件系统)应运而生㊂它以对象作为数据存储单元,将所有对象以扁平方式进行存储,元数据和数据一起下放至OSD(object storage device)管理,POSIX接口所涉及的元数据仍由MDS管理㊂对象文件系统摒弃了传统的集中式存储元数据寻址的方案,客户端只需通过哈希计算的方式即可完成oid到对象存储设备物理位置的映射㊂元数据服务器的功能被弱化,客户端更多地与均衡分布的OSD集群交互㊂典型的对象文件系统有:Inktank公司的Ceph系统[6]㊁Cluster File Systems公司的Lustre系统[7-8]㊁Rackspace公司的Swift系统等㊂其中,Ceph因其在数据访问和信息存储方面的灵活性以及得益于OpenStack的青睐,成为了当前最炙手可热的分布式存储系统㊂对象文件系统虽然解决了元数据访问瓶颈的问题,但是对小文件的支持仍是短板㊂例如,大小为128 KB的8个小文件,每个小文件所占用的存储空间为一个对象,假设对象大小为4MB,总量1MB的数据实际共占用了32MB的存储空间㊂这样,整个系统的存储空间利用率非常低,对象内大块的 碎片”空间没有得到有效使用㊂CephFS支持元数据和数据分离存储,但是对小文件的优化仍然局限在元数据层面㊂如果上层应用允许,优选RGW对象接口,对象接口天然具备更少的元数据,能支撑更大的容量㊂虽然CRUSH算法机制解决了元数据的问题,但是Ceph对于海量小文件带来的第二个问题尚不能很好地解决㊂Ceph社区曾对此问题进行了描述并提出了一种基于rgw的方案,不过在最新代码中,一直未找到方案的实现[9-10]㊂许艳艳等通过修改Ceph实现了一个基于可变长分块的文件系统VarFS[11],一个对象可以被多个文件包含㊂但是合并在同一对象中的小文件没有关联,不能发挥数据 预取”的优势;且VarFS额外的对象元数据服务器增加了内部消息交互负担和系统复杂性,新增的文件接口和Ceph原生接口不兼容㊂从这些研究来看,聚合后的小文件没有避开从聚合结构到具体文件的二次映射问题,无论是采用全局索引目录方式,还是聚合结构中的局部索引方式,都是属于 查表检索”的传统理念[12]㊂而 无中心结构”的对象存储系统更青睐于 计算检索”的设计理念,因此需要一种与对象存储系统设计理念相一致的小文件优化存储与访问方式㊂2 基于对象的海量小文件存储优化方案针对上述问题,文中提出了一种基于对象文件系统的海量小文件存储优化方案㊂采用 特征聚合㊁计算定位”的方法获得对象存储位置,根本改变元数据的查表索引方式,在客户端采用小文件数据大粒度预读技术将物理上和逻辑上连续的小文件数据批量预读到本地缓存,聚合小粒度I/O为大粒度I/O,提升了磁盘效率,并使用页面热缓存和温缓存两级队列管理和识别热数据,充分利用文件的局部特征提升后续读访问时缓存命中,降低访问时延㊂㊃23㊃ 计算机技术与发展 第29卷如图1所示,该系统由客户端㊁元数据服务器㊁对象存储集群三部分组成㊂图1 基于对象的海量小文件存储优化方案架构(1)客户端模块㊂该模块为上层应用提供对象存储接口,实现了读写处理函数,并处理与文件元数据服务器㊁对象存储集群之间的通讯㊂在读写数据时,首先需到MDS获取对应文件的元数据,主要包括ino和ono㊂ino用于全局标识每一个文件,ono是文件分片的编号,用于标识该文件所处的对象㊂然后通过计算的方式获得该文件的物理位置,即oid㊂最后直接读写访问OSD,并在读写结束后更新MDS中的元数据㊂(2)元数据服务器㊂该模块为文件接口提供元数据服务,管理的元数据信息主要包括访问权限信息和逻辑视图信息,如ino㊁ono㊁最后修改时间㊁访问权限㊁文件大小等㊂只有在需要提供Posix等文件接口时,才需要配置MDS模块㊂(3)对象存储集群㊂负责集群中所有数据与对象的存储,处理集群数据的复制㊁恢复㊁再均衡,监控集群状态并保证集群数据的一致性㊂对象的大小一般配置为2MB或4MB㊂每个对象对应一个Oid,由ino和ono根据算法生成㊂大文件和小文件的界限也可配置,本方案中设为1MB㊂在处理文件读写操作时,首先判断文件的大小㊂若该文件为小文件,则交由小文件聚合模块处理㊂若不是小文件,则继续判断文件是否小于一个对象大小,是则由ino直接计算oid,否则将该文件进行切片处理㊂编号为ino的大文件的第ono个对象的编号oid计算公式为:Oid=(ino≪32)|ono (1)小文件聚合模块负责小文件的特征聚合和计算定位管理㊂小文件写操作时,计算文件之间的局部性特征,并根据特征选取若干小文件聚合为文件组,将聚合后的文件组作为一个对象发起存储请求;文件读操作时,通过ino和ono计算出小文件所在的对象以及小文件在对象内的区域㊂2.1 小文件聚合管理文中小文件聚合算法的核心思想为 特征聚合,计算定位”,根据文件局部性特征将小文件聚合为文件组,通过条带化规则将一个文件组聚合在一个对象中,通过计算方式高效率地定位对象存储位置,而非低效的查表索引方式,同时能优化数据布局㊂被聚合的小文件同时拥有良好的时间局部性和空间局部性,使得系统读性能显著提升㊂根据对多个应用场景的统计分析,在应用的全生命周期内,小文件访问在整体上呈现出极强的规律性[13]㊂不仅不同用户的操作概率很不均衡,而且各操作之间也具有很强的相关性㊂表现为:刚刚被访问过的文件,极有可能在不久之后再次被访问到,即时间局部性[14];将被访问的下一个文件,极有可能就处于之前被访问过的某个文件的附近,即空间局部性㊂有的应用场景也可根据业务特征确定文件的相关性(例如,同一主题的邮件,本邮件的上一个邮件和下一个邮件,相互关联的图片文件,OTT视频文件的切片,同一文件夹的文件等等)㊂所以可以利用文件的空间局部性和时间局部性特征,将小文件聚合缓冲区中的文件,分别置于邻近时间特征队列和邻近空间特征队列中,可以根据特定应用场景特征来设置新的文件关联特征队列,并可调整各特征队列的权重㊂在小文件合并过程中,综合利用文件之间的空间局部性㊁时间局部性以及其他关联特征,尽量将可能连续访问的小文件聚合为文件组,一个文件组中各个文件的元数据和数据聚合在一个对象中连续存储,增强了小文件之间的数据局部性和聚合后存储对象内部的数据局部性㊂这又把磁盘上的随机I/O转换成了顺序I/O,提高了磁盘I/O效率,并为下一步的小文件数据大粒度预读提供了条件㊂本算法扩展了对象存储系统中ono的定义:当ono为正数,表明该文件不是小文件,其绝对值是ino 对应的文件被切片之后的顺序编号;当ono为负数,则表明该文件是小文件,其绝对值表示小文件聚合为文件组后,该小文件在文件组存储的对象内的区域编号㊂本算法采用的对象条带化规则为,每个小文件在聚合后的对象中单独占用1MB,单个对象最多可聚合的文件数量为:对象大小/小文件界限大小㊂其中对象大小㊁小文件界限大小都是可配置的㊂编号为ino的小文件被聚合于对象的Oid计算公式为:Oid=((ino+ono+1)≪32)|1 (2)该小文件在该对象的第-ono个区域中㊂这样,本算法可以将若干小文件聚合在同一个对象中,并通过计算获得读写位置㊂㊃33㊃ 第8期 屠雪真等:一种海量小文件对象存储优化方案如图2所示,小文件写聚合流程包括以下步骤: (1)客户端C1发起文件写请求㊂㊃客户端C1判断是否是小文件,是则放入小文件聚合缓存队列,否则进入正常文件处理流程㊂图2 小文件写聚合流程㊃按照规则根据聚合特征选取小文件组,阈值到,则客户端C1向元数据服务器MDS发出创建文件组内各小文件(B㊁C㊁D㊁E),(F㊁G㊁H㊁I)元数据的请求㊂(2)MDS按规则为小文件分配ino和ono,并创建相关元数据㊂㊃MDS按递增原则为文件组内各小文件逐一分配全局唯一编号ino,相连文件组内各小文件(B㊁C㊁D㊁E),(F㊁G㊁H㊁I)被分配的ino连续递增㊂㊃MDS为文件组内各小文件分配ono,规则为:B 为-1,C为-2,D为-3,E为-4;F为-1,G为-2,H为-3,I为-4㊂㊃元数据服务器逐一为上述小文件创建其他元数据,如文件创建时间㊁访问权限等㊂㊃元数据服务器将上述小文件的ino和ono回传给客户端C1㊂(3)客户端C1计算小文件聚合后对象存储的位置,并向该OSD的小文件聚合模块发起处理请求㊂㊃客户端C1收到元数据服务器传来的ino 和ono㊂㊃客户端C1根据式2逐个计算出小文件将写入到的对象编号oid㊂㊃客户端C1根据对象编号计算该对象所处的OSD㊂OSD编号的计算公式为:OSD_num=HASH(oid) (3) HASH包括但不限于:平方取中间值㊁模运算取余㊁DHT算法㊁CRUSH算法㊂㊃客户端C1根据OSD_num向对象存储设备发出小文件聚合写请求㊂(4)小文件聚合模块将小文件组(B㊁C㊁D㊁E), (F㊁G㊁H㊁I)分别聚合写入到相应对象中,OSD向客户端C1和MSD返回结果㊂㊃小文件聚合模块根据ono判定是否为小文件聚合写操作,非负数则报错㊂㊃小文件聚合模块将各文件组的小文件聚合写入同一对象中㊂每个小文件存放在相同大小的区域中,对象的第K个区域存放ono为-K的小文件㊂㊃通知客户端C1写入完成,通知MDS更新上述小文件的元数据信息,如最后访问时间等㊂如图3所示,读取小文件的流程包括以下步骤:图3 小文件读聚合流程(1)客户端C2发起请求读取单个小文件或者批量读取小文件㊂(2)客户端C2检查当前读取文件的数据是否存在于缓存㊂如果是,则在缓存中将数据返回给应用,进入步骤6;如果否,则C2向MDS发起请求获取待读取小文件的元数据㊂(3)MDS将当前待读取文件的ino和ono发送给客户端C2㊂㊃客户端C2向MDS获取待读取文件的元数据㊂㊃MDS判断访问权限㊂合法访问则MDS将当前读取文件的ino和ono返回给客户端C2㊂(4)客户端计算小文件聚合位置,交由小文件聚合模块处理㊂㊃客户端C2通过式2由ino和ono计算当前待读取小文件所在的对象编号oid㊂㊃客户端C2通过式3由oid计算该对象所存储于OSD的编号OSD_num㊂㊃客户端C2向OSD发出读请求㊂(5)小文件聚合模块将编号为oid的对象中的数据返回给客户端C2㊂客户端C2根据ono,将相应数据㊃43㊃ 计算机技术与发展 第29卷返回给上层应用㊂将该对象中其他区域的数据内容保存在缓存中,后续访问若在缓存命中,则省去了同步读取的时间开销㊂㊃小文件聚合模块将编号为oid的对象中的全部数据发送给客户端C2,同时通知MDS更新该文件的元数据,如最后访问时间等㊂㊃客户端C2收到该对象的数据㊂将第-ono个区域的数据从对象中取出,返回给上层应用㊂㊃客户端C2将该对象中的其他数据保存在缓存中㊂(6)客户端C2检查是否读取完毕,如果否,则读取下一个文件,进入步骤2;如果是,则结束㊂综上所述,与现有技术相比,文中提出的小文件聚合方法节省了 查表索引”的开销,根据特征聚合的文件组也提高了小文件间的关联性,可显著提升小文件的读写性能㊂2.2 小文件数据大粒度预读技术在小文件数据读取访问中,由于数据读取粒度小并且不同小文件之间的数据访问空间连续性差,难以发挥磁盘的大粒度顺序访问的性能优势,导致小文件的访问性能远远低于大文件的访问性能㊂预读是提升小文件读取访问性能的一个主要方法㊂针对数据访问时IO粒度小,磁盘吞吐量低的问题,文中采取一种客户端小文件数据大粒度预读技术㊂通过把将要访问的数据预先读取到客户端缓存,后续客户端访问时可以在缓存中获取数据,节省了同步从磁盘读取数据的开销㊂小文件数据大粒度预读通过页面热缓存㊁页面温缓存㊁同步预读㊁异步预读等技术来实现㊂页面热缓存:将空间连续的大粒度数据从磁盘预读到客户端缓存后,对于已经与具体要访问的文件相关联的页面直接放到页面热缓存中管理㊂页面温缓存:对于暂未关联到任何文件的数据页,记为匿名页,放入页面温缓存管理,每一个匿名页记录着该数据页面在磁盘中的物理位置标识㊂通过双向链表的方式组织在匿名页面,磁盘中位置连续的数据页面使用同一个匿名页链表管理,并在链表中记录该链表中页面的起始㊁数量㊁使用情况等信息㊂当后续访问发起读盘操作前,先检查页面温缓存,如果命中这个物理位置标识,则将该匿名页直接返回,同时把该页面从页面温缓存中摘除并放入到页面热缓存㊂异步预读:在访问过程中,随着匿名页面缓冲区的页面减少到一定程度,使用率达到异步预读触发点,则可认为该链表的预读页面使用情况好,访问局部性强,此时触发异步预读㊂异步预读技术使得数据在被使用前尽可能地准备好,大幅提升缓存命中率,减少同步IO等待的时延㊂同步预读:在客户端读取单个小文件时,不仅获取该小文件所需的小粒度数据,而且还把与该小文件数据空间连续的大粒度数据从磁盘预读到缓存㊂当后续访问其他小文件时,如果所需数据已存在于缓存,则避免了从磁盘再次读取的开销㊂采用 读则预读”的原则,预读的触发点固化在单一的页面中㊂优点是简单易行,缺点是过于死板,没有访问到该页面即便拥有良好的访问局部性也不会触发预读㊂客户端读取文件的流程如图4所示㊂图4 小文件数据大粒度预读流程先检查文件数据是否在本地页面缓存中,如果是则读取页面缓存并返回㊂否则检查是否在预读页面缓存中命中,如果是则将该匿名页放入到页面缓冲区,并检查匿名页使用率是否触发异步预读条件,是则触发异步预读,否则返回㊂如果没有在预读页面缓存中命中,则触发同步预读,从磁盘上读出文件所在对象的数据,并更新页面缓存和预读缓存㊂3 实验及应用本节将统一存储系统ZXDFS采用文中技术优化前后进行测试对比㊂测试环境配置为:CPU英特尔E56062.13GHz双路16核/内存8GB*7/SSD英特尔s3500220GB/万兆网卡,操作系统Suse11sp3V3.0.76㊂采用四种典型应用场景的现网数据,如表1所示㊂表1 测试应用案例应用来源访问特点文件大小1OTT互联网小视频海量大文件,顺序读1~16MB 2音乐库大小文件均布,读多写少64K~4MB 3邮箱系统海量小文件随机读写,有局部性规律4K~32KB 4日志话单海量小文件,随机读写,局部性规律弱4K~1MB㊃53㊃ 第8期 屠雪真等:一种海量小文件对象存储优化方案 对每种类型的应用场景,在相同的测试预置条件下,对比ZXDFS 在优化前和优化后的性能指标,优化后是指采用文中所述技术优化后的ZXDFS 系统㊂采用文件读写访问的时间延迟作为性能评价指标㊂为保证实验结果可靠,每种类型应用场景重复实验14次,去掉最小的2个值,去掉最大的2个值,对中间的10个值取平均㊂性能测试结果对比如图5所示㊂/k s图5 性能测试结果对比在测试的四种应用场景中,场景3性能提升的效果最佳,达到51%㊂场景1性能提升的效果最不明显,仅为3%㊂其他场景性能提升比例介于22%~30%之间,与各场景的平均性能提升水平26%较接近㊂场景1性能提升不明显,是由于该场景下文件比较大,并且主要是顺序读访问,文中优化方案难以发挥效果㊂场景3性能提升较大的原因是海量小文件访问,文件之间具有较强的局部性特征,优化效果得以充分发挥㊂4摇结束语在面对海量小文件场景时,传统分布式文件系统存在着 元数据结构效率低,访问频率高且开销大”和 IO 粒度小㊁磁盘吞吐量低”的难题㊂业界现有的小文件聚合方法不符合分布式系统的 通过计算检索”的设计理念㊂因此,文中提出了一种基于对象文件系统的小文件存储优化方法,核心设计思想概括为 特征聚合㊁计算定位㊁客户端预读”,解决了元数据 查表检索”的难题,提升了磁盘I /O 效率和缓存命中率㊂在小文件的典型应用场景中,总体性能提升50%以上㊂但是,该方案在使用简单对象条带化策略时,可能有存储空间浪费㊁删除文件操作无法立即回收存储空间的局限㊂对于存在大量删除和修改操作的应用场景还需进一步优化㊂参考文献:[1] 周国安,李 强,陈 新,等.云环境下海量小文件存储技 术研究综述[J ].信息网络安全,2014(6):11-17.[2] YANG Hongzhang ,ZHANG Junwei ,ZENG Xiangchao ,etal.Research of massive small files reading optimization based on parallel network file system [C ]//IEEE 17th internationalconference on high performance computing and communica⁃tions ,IEEE 7th international symposium on cyberspace safety and security ,and IEEE 12th international conference on em⁃bedded software and systems.New York ,NY ,USA :IEEE ,2015:204-212.[3] BEAVER D ,KUMAR S ,LI H C ,et al.Finding a needle inHaystack :Facebook ’s phot storage [C ]//Proceedings of the 9th USENIX conference on operating systems design and im⁃plementation.Vancouver ,BC ,Canada :USENIX Assocaition ,2010:47-60.[4] 赵 洋.淘宝TFS 深度剖析[J ].数字化用户,2013(3):58-59.[5] 严巍巍,何连跃,李三霞,等.SMDFS 分布式海量小文件系统的大空间聚合存储技术[J ].计算机研究与发展,2015,52:29-34.[6] WEIL S A ,BRANDT S A ,MILLER E L ,et al.Ceph :a scal⁃able ,high -performance distributed file system [C ]//7thUSENIX symposium on operating systems design and imple⁃mentation.Seattle ,WA ,USA :USENIX ,2006:307-320.[7] DONOVAN S ,SYMPOSIUM L ,KLEEN A ,et al.Lustre :building a file system for 1000-node clusters [C ]//Proceed⁃ings of Linux symposium.Washington D.C.,USA :IEEE ,2003:9-17.[8] 聂瑞华,谢文君,梁 军.一种改进的基于缓存池机制的小文件I /O 策略[J ].计算机工程与应用,2016,52(16):210-215.[9] 唐 蜜.基于客户端缓存与请求调度的的Ceph 文件系统读时延优化策略研究[D ].武汉:华中科技大学,2017.[10]詹 玲,方协云,李大平,等.基于Ceph 文件系统的元数据缓存备份[J ].计算机工程,2017,43(4):67-72.[11]许艳艳,雷迎春,龚奕利.基于可变长分块的分布式文件系统设计与实现[J ].计算机工程,2016,42(5):80-84.[12]马 灿,孟 丹,熊 劲,等.基于分布式索引和目录聚合的海量小文件存储研究[J ].高技术通讯,2012,22(10):1035-1040.[13]王 涛,姚世紅,徐正全,等.云存储中面向访问任务的小文件合并与预取策略[J ].武汉大学学报:信息科学版,2013,38(12):1504-1508.[14]CHE NJiahao ,DENG Yuhui ,HUANG Zhang.HDCat :effec⁃tively identifying hot data in large -scale I /O streams with enhanced temporal locality [C ]//International conference on algorithms and architectures for parallel processing.[s.l.]:[s.n.],2015:120-133.㊃63㊃ 计算机技术与发展 第29卷。

海量小文件的管理

海量小文件的管理

海量⼩⽂件的管理在单个⽬录存放超过上百万的⽂件时,对⼤部分的OS都是⼀个挑战,⽬录的浏览就是⼀个⾮常难以忍受的事情。

所以针对海量⼩⽂件的应⽤场景,能够使⽤nosql数据库时,尽量使⽤如redis之类的nosql数据库.在⾮使⽤⽂件系统来存储管理海量⼩⽂件的情况下,尽量使⽤以下原则来进⾏管理尽可能使⽤⽬录分批存储,避免单⽬录⽂件数量过万⽂件系统最好使⽤XFS,XFS的inode数量是ext4的10倍以上如果不⼩⼼遇到了单⽬录下⽂件数量过万甚⾄百万的情况,下⾯是⼀些处理建议##⽬录复制或者移动将单⽬录为百万以上的⽂件分⽬录批量存储⾸先获取⼀份⽬录⽂件列表,然后根据列表来使⽤脚本批量处理⽂件find /path/ -name "*" > filelist.txt#!/bin/shcd _Receivefor ((j=1;j<10000;j++)); do_dir=$jmkdir /u02/app/tomcat/files/temp/${_dir}for i in `head -n 10000 /u01/app/tomcat/files/flist.txt` ; domv $i /u02/app/tomcat/files/temp/${_dir}donesed -i '1,10000d' /u01/app/tomcat/files/flist.txtdone## 快速删除⽂件rsync -ap --delete-before /blank_dir/ /dest_dir经测试验证,使⽤rsync批量删除⽂件效率要⽐直接rm快10倍以上root# time rsync --delete-before -a b/ treal 2m6.463suser 0m3.150ssys 1m2.625sroot# time find t -name "*" -exec rm {} \;real 27m52.152suser 4m59.824ssys 22m50.166s。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
配合AD进行用户身份认证
▪配合AD服务器方式,实现用户身份统一认证管理;
存储空间的Quota管理
▪根据不同的用户类型的定义,分类设定磁盘空间限额。实现存储空间的统一管理;
快照功能
▪策略方式或人工出发方式的快照功能,实现用户数据的快速恢复。单卷快照可达255个;
NetApp 存储方案建议(一)- HA 双控制器高可用
▪采用Tiebreaker监控,任意Site设备故障,另一个Site设备自动 接管
▪通过万兆以太网,使用CIFS协议共享存储空间给前端Client
特点: ▪双份数据; ▪任意Site故障业务不中断;
DS 224 C
DS 224 C
SyncMirror DS224C
DS 224 C
DS 224 C
DS 224 C
NetApp 存储技术特点 - ONTAP 操作系统
ONTAP 操作系统
- 专为存储系统设计 - 不用担心病毒侵害 - 运行效率高
无中断运行
- 即使是工作时间,也可以完成硬件扩展/维护、软件升级等操作
可扩展性
- 支持横向和纵向扩展 (ONTAP 被认为是横向扩展NAS的领导者1 )
NetApp 存储技术特点 - RAID DP
FAS 8200 Single x 2 配置: 单存储控制器; 64GB Cache; 1TB Flash Cache CIFS、NFS使用许可; 前端接口:2个10Gb 网络接口 后端接口:4个12Gbps Mini SAS接口 磁盘容量:8块960GB SSD,60块1.8TB SAS
FAS8200
双重奇偶校验
- 防止两块硬盘同时故障 - 安全性是普通RAID的2,000 到 4,0000 倍
固定校验盘
- 性能比RAID - 5更好 - 可以随时添加磁盘而无需重建
NetApp 存储技术特点 - 重复数据删除
▪ 满足ROI(投资回报率,Return On Investment)/TCO(总持有成本, Total Cost of Ownership)需求;
配置:
▪采用2节点MCC 双活方案,每个Site配置一个FAS 8200控制器, 每个Site配置8块960GB SSD,60块1.8TB SAS磁盘,通过 SyncMirror技术,实现两个Site之间数据实时同步
个人数据
Home Directories
部门共享
Clients
▪使用SSD与SAS的数据分层来提升性能访问
广州盈融信息科技有限公司 海量小文件共享存储方案
NetApp 存储方案建议(一)- HA 双控制器高可用
配置: ▪采用 FAS 8200 HA 双控制器,配置4块960GB SSD,60块1.8TB SAS磁盘 ▪使用SSD与SAS的数据分层来提升性能访问 ▪通过万兆以太网,使用CIFS协议共享存储空间给前端Client
特点: ▪HA 双控制器,任意控制器故障,另一存活控制器自动接管业务;
Primary Data Center
个人数据
Home Directories
部门共享
Clients
万兆以太网 交换机
FAS 8200 (4x960GB SSD 60x1.8TB SAS)
NetApp 存储方案建议(二)- 双活数据中心
NetApp 存储技术特点 - 容灾技术
▪ 数据保护:支持远程复制,以实现基于存储的异地容 灾,同时减少对生产存储设备的性能损耗;
▪ NetApp全系列存储均支持异步方式的数据容灾。基 于异步方式,可以实现基于数据增量方式的传输及基 于应用的一致性数据传输,并支持传输的数据压缩及 重删。
NetApp SnapMirror容灾灵活性 结合重复数据删除和压缩
FAS 8200 HA 配置: 双存储控制器; 128GB Cache; 2TB Flash Cache CIFS、NFS使用许可; 前端接口:4个10Gb 网络接口 后端接口:8个12Gbps Mini SAS接口 磁盘容量:4块960GB SSD,60块1.8TB SAS
FAS8200
NetApp 存储方案建议(二)- 双活数据中心
NetApp 存储技术特点 - 图形化管理
▪ 配置基本管理软件:图形化管理及监控软件;
▪ NetApp的全系列产品均使用同一个图形化管理软件 System Manager。通过该软件,可以实现SAN/NAS 功能的实施部署。
客户成功就是我们的成功
谢谢!Байду номын сангаас
▪ 可以有效控制数据的急剧增长;
▪ 增加有效存储空间,提高存储效率; ▪ 节省存储总成本和管理成本;
Before
After
▪ 节省数据传输的网络带宽;
▪ 节省空间、电力供应、冷却等运维成本。
NetApp 存储技术特点 - 快照技术
▪ 秒级完成创建完成副本 ▪ 每个卷支持高达255份的快照副本 ▪ 快速恢复 ▪ 稳定可靠 ▪ 不影响系统性能
FAS 8200 Single Node (8x960GB SSD 60x1.8TB SAS)
Site A
FAS 8200 Single Node (8x960GB SSD 60x1.8TB SAS)
Site B
Tiebreaker
IP链路
NetApp 存储方案建议
网络方式的数据保存
▪采用NAS方式进行数据存取,采用windows CIFS协议; ▪区别传统的文件共享方式,无需文件服务器。减少设备数量,降低管理成本,无需担忧病毒; ▪实现个人数据的独立存取及部门数据的共享读取; ▪支持现有的万兆网络环境,支持网络端口聚合,提升网络性能;
相关文档
最新文档