FastDFS文件名策略及对小文件的优化

0.简介

FastDFS是一个应用级分布式文件存储服务,其采用中心型结构(类似GFS、HDFS、TFS等),主要用于大中型网站存储资源文件。FastDFS具有轻量级,支持高并发放访问,负载均衡,可扩展等优点。而FastDFS最大的亮点就是对小文件的存储性能较好,这主要来自于其文件名策略。

1.小文件存储性能优化

小文件的性能瓶颈主要来自于对元数据服务器(如FastDFS中的TrackerServer或TFS中的NameServer)的访问,因为当文件本身大小很小时,元数据存储所占空间与文件内容存储所占空间的比例就变得较大,访问元数据所消耗资源与访问文件内容所消耗资源的比例也变得较大。因此,通常对小文件存储的优化方法主要有两大类思路:一是减少访问元数据的次数,比如Cache预取;二是减少元数据所占的存储空间,比如FastDFS使用的文件名策略。

2. FastDFS文件名策略

FastDFS中的文件名是在向StorageServer存储文件时由系统指定的,文件名中包含了VolumeID和FileID。也就是说,当客户要读取某个文件时,通过在客户端对文件名进行解析,就可以知道该文件存储在哪个Volume上和它在StorageServer中的FileID。但是此时用户还不能读取文件,因为他不知道Volume内各个StorageServer的ip地址,也不知道应该从Volume内的哪个StorageServer中读取。所以用户需手持欲访问的文件的VolumeID向TrackerServer询问,TrackerServe会均衡当前各StorageServer的IO负载状况,返回一个最佳的StorageServer的ip地址。最后用户与该StorageServer连接,出示欲访问文件的FileID,StorageServer上会维持一个FileID对应偏移量的表,从而得到欲访问文件的偏移量。

可见,FastDFS的文件名策略将文件存储位置信息隐含在文件名中,从而减少了元数据量,达到了优化小文件存储性能的作用。

时间: 2024-10-13 23:53:54

FastDFS文件名策略及对小文件的优化的相关文章

LOSF 海量小文件问题综述

1.LOSF问题概述 在互联网(尤其是移动互联网).物联网.云计算.大数据等高速发展的大背景下,数据呈现爆炸式地增长.根据IDC的预测,到2020年产生的数据量 将达到40ZB,而之前2011年6月的预测是35ZB.然而,社会化网络.移动通信.网络视频音频.电子商务.传感器网络.科学实验等各种应用产生的数 据,不仅存储容量巨大,而且还具有数据类型繁多.数据大小变化大.流动快等显著特点,往往能够产生千万级.亿级甚至十亿.百亿级的海量小文件,而且更多地 是海量大小文件混合存储.由于在元数据管理.访问

大数据技术之_05_Hadoop学习_04_MapReduce_Hadoop企业优化(重中之重)+HDFS小文件优化方法+MapReduce扩展案例+倒排索引案例(多job串联)+TopN案例+找博客共同粉丝案例+常见错误及解决方案

第6章 Hadoop企业优化(重中之重)6.1 MapReduce 跑的慢的原因6.2 MapReduce优化方法6.2.1 数据输入6.2.2 Map阶段6.2.3 Reduce阶段6.2.4 I/O传输6.2.5 数据倾斜问题6.2.6 常用的调优参数6.3 HDFS小文件优化方法6.3.1 HDFS小文件弊端6.3.2 HDFS小文件解决方案第7章 MapReduce扩展案例7.1 倒排索引案例(多job串联)7.2 TopN案例7.3 找博客共同粉丝案例第8章 常见错误及解决方案 第6章

HDFS小文件合并问题的优化:copyMerge的改进

1.问题分析 用fsck命令统计 查看HDFS上在某一天日志的大小,分块情况以及平均的块大小,即 [[email protected] jar]$ hadoop fsck /wcc/da/kafka/report/2015-01-11 DEPRECATED: Use of this script to execute hdfs command is deprecated. Instead use the hdfs command for it. 15/01/13 18:57:23 WARN ut

海量小文件存储与Ceph实践

海量小文件存储(简称LOSF,lots of small files)出现后,就一直是业界的难题,众多博文(如[1])对此问题进行了阐述与分析,许多互联网公司也针对自己的具体场景研发了自己的存储方案(如taobao开源的TFS,facebook自主研发的Haystack),还有一些公司在现有开源项目(如hbase,fastdfs,mfs等)基础上做针对性改造优化以满足业务存储需求: 一. 通过对若干分布式存储系统的调研.测试与使用,与其它分布式系统相比,海量小文件存储更侧重于解决两个问题: 1.

Hadoop对小文件的解决方案

小文件指的是那些size比HDFS的block size(默认64M)小的多的文件.任何一个文件,目录和block,在HDFS中都会被表示为一个object存储在namenode的内存中, 每一个object占用150 bytes的内存空间.所以,如果有10million个文件, 每一个文件对应一个block,那么就将要消耗namenode 3G的内存来保存这些block的信息.如果规模再大一些,那么将会超出现阶段计算机硬件所能满足的极限. 控制小文件的方法有: 1.应用程序自己控制 2.arc

Hadoop小文件解决之道之一 Hadoop archive

简介 hdfs并不擅长存储小文件,因为每个文件最少一个block,每个block的元数据都会在namenode节点占用内存,如果存在这样大量的小文件,它们会吃掉namenode节点的大量内存. hadoop Archives可以有效的处理以上问题,他可以把多个文件归档成为一个文件,归档成一个文件后还可以透明的访问每一个文件,并且可以做为mapreduce任务的输入. 用法 hadoop Archives可以使用archive工具创建,同上一篇讲的distcp一样,archive也是一个mapre

hadoop-Archives har归档历史文件(小文件)

应用场景 我们的hdfs中保存大量小文件(当然不产生小文件是最佳实践),这样会把namenode的namespace搞的很大.namespace保存着hdfs文件的inode信息,文件越多需要的namenode内存越大,但内存毕竟是有限的(这个是目前hadoop的硬伤). 下面图片展示了,har文档的结构.har文件是通过mapreduce生成的,job结束后源文件不会删除. har命令说明 1.archive命令 (1).什么是Hadoop archives?Hadoop archives是特

[iOS 多线程 & 网络 - 2.5] - 小文件上传

A.文件上传 思路: 发送文件数据给服务器 使用post请求 必须手动设置请求头: 内容大小Content-Length & 内容类型 Content-Type 请求体:文件数据 文件上传的格式要求十分严格,必须严格遵守 由于是一次性加载文件到内存上传,所以只能用于小文件上传 B.实现 1.设置POST请求 (1)使用POST请求方法 (2)设置请求头 设置内容长度.内容类型.分割线 (3)设置请求体 NSMutableData *body = [NSMutableData data]; 分割线

[Hadoop]大量小文件问题及解决方案

1. HDFS上的小文件问题 小文件是指文件大小明显小于HDFS上块(block)大小(默认64MB)的文件.如果存储小文件,必定会有大量这样的小文件,否则你也不会使用Hadoop(If you're storing small files, then you probably have lots of them (otherwise you wouldn't turn to Hadoop)),这样的文件给hadoop的扩展性和性能带来严重问题.当一个文件的大小小于HDFS的块大小(默认64MB