CN106874348B - 文件存储和索引方法、装置及读取文件的方法 - Google Patents
文件存储和索引方法、装置及读取文件的方法 Download PDFInfo
- Publication number
- CN106874348B CN106874348B CN201611221215.1A CN201611221215A CN106874348B CN 106874348 B CN106874348 B CN 106874348B CN 201611221215 A CN201611221215 A CN 201611221215A CN 106874348 B CN106874348 B CN 106874348B
- Authority
- CN
- China
- Prior art keywords
- file
- key value
- index
- files
- value
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
Abstract
本发明提供了一种文件存储和索引方法、装置及读取文件的方法,其中,该文件存储和索引方法包括:按照文件的实际key值的字母顺序存储各文件,得到数据文件;生成用于索引数据文件中各文件的索引文件,其中,索引文件中的索引使用各文件的实际key值的前N字节作为key值,每个索引指向数据文件中的一个或者多个文件,key值对应的offset值为key值指向的一个或者多个文件中首个文件的offset值,key值对应的size值为key值指向的一个或者多个文件中首个文件的size值。通过本发明,解决了Haystack系统采用的索引方案对内存资源消耗大的问题,降低了索引系统对内存资源的消耗。
Description
技术领域
本发明涉及文件存储及索引领域,具体而言,涉及一种文件存储和索引方法、装置及读取文件的方法。
背景技术
当今互联网,数据呈现爆炸式增长,社交网络、移动通信、网络视频、电子商务等各种应用往往能产生亿级甚至十亿、百亿级的海量小文件。由于在元数据管理、访问性能、存储效率等方面面临巨大的挑战,海量小文件问题成为了业界公认的难题。
业界的一些知名互联网公司,也对海量小文件提出了解决方案,例如:著名的社交网站Facebook,存储了超过600亿张图片,专门推出了Haystack系统,针对海量小图片进行定制优化的存储。其他的小文件处理方案还有淘宝的TFS等,这些系统的核心思想都是将小文件追加到一个数据文件中,同时生成索引文件,通过索引文件来定位小文件的位置。
下面介绍Facebook采用的Haystack的解决方案:
Facebook的Haystack对小文件的解决办法是,把小文件合起来。将一些小文件的数据依次追加到数据文件中,并且生成索引文件,通过索引来查找小文件在数据文件中的offset和size,对文件进行读取。
(1)Haystack的数据文件部分:Haystack的数据文件,将每个小文件封装成一个needle,包含文件的key、size、data等数据信息。所有小文件按写入的先后顺序追加到数据文件中。
(2)Haystack的索引文件部分:Haystack的索引文件保存每个needle的key,以及该needle在数据文件中的offset、size等信息。程序启动时会将索引加载到内存中,在内存中通过查找索引,来定位在数据文件中的偏移量和大小。
(3)读请求使用索引:将索引文件载入内存,通过查找索引,来定位要读取文件的offset、size,将数据读取出来。
(4)写请求使用索引:写文件每次添加一个文件,将文件的数据添加到末尾的Needle n。生成索引添加到Needle n index record。
由上述的描述可以看出,Facebook的Haystack特点是将文件的完整key都加载到内存中,进行文件定位。机器内存足够大的情况下,Facebook完整的8字节key可以全部加载到内存中。但是现实环境下存在两个问题:
(1)存储服务器内存不会太大,一般为32G至64G;
(2)小文件对应的key大小难控制,一般选择文件内容的MD5或SHA1作为该文件的key。
假设一台存储服务器有12块4T磁盘,内存为32GB左右。服务器上现需存储大小约为4K的头像、缩略图等文件,约为10亿个。文件的key使用MD5,加上offset和size字段,平均一个小文件对应的索引信息占用28字节。在这种情况下,索引占用内存接近30GB,磁盘仅占用4TB。内存消耗近100%,磁盘消耗只有8%。
由此可见,Haystack系统采用的索引方案对内存资源消耗巨大,并且内存资源限制了磁盘资源的利用率,因此,想要获得更大的磁盘资源的利用率需要额外增加内存资源的大量投入。
发明内容
本发明提供了一种文件存储和索引方法、装置及读取文件的方法,以至少解决Haystack系统采用的索引方案对内存资源消耗大的问题。
根据本发明的一个方面,提供了一种文件存储和索引方法,包括:按照文件的实际key值的字母顺序存储各文件,得到数据文件;生成用于索引所述数据文件中各文件的索引文件,其中,所述索引文件中的索引使用各文件的实际key值的前N字节作为key值,每个索引指向所述数据文件中的一个或者多个文件,所述key值对应的offset值为所述key值指向的一个或者多个文件中首个文件的offset值,所述key值对应的size值为所述key值指向的一个或者多个文件中首个文件的size值,N为正整数。
可选地,所述索引文件中的offset字段和size字段是通过512字节对齐的。
可选地,生成用于索引所述数据文件中各文件的索引文件还包括:按照key值前缀分层存储所述索引文件的索引,其中,所述key值前缀对应的分层中存储的索引的key值为截去所述key值前缀的简短key值,其中,所述key值前缀的字节长度小于N。
可选地,所述索引文件的索引的offset值是以所述索引所在分层为偏移范围的层内offset值,所述层内offset值的字节数是根据分层的最大层地址空间确定的。
可选地,所述方法还包括:将所述数据文件中的所有文件映射到bloomfilter中,以使读取所述数据文件中的文件时通过快速搜索所述bloomfilter来判断将要读取的文件是否可能存在。
根据本发明的另一个方面,还提供了一种文件存储和索引装置,包括:数据文件存储模块,用于存储数据文件,其中,所述数据文件是按照文件的实际key值的字母顺序存储各文件所得到的;索引文件生成模块,用于生成用于索引所述数据文件中各文件的索引文件,其中,所述索引文件中的索引使用各文件的实际key值的前N字节作为key值,每个索引指向所述数据文件中的一个或者多个文件,所述key值对应的offset值为所述key值指向的一个或者多个文件中首个文件的offset值,所述key值对应的size值为所述key值指向的一个或者多个文件中首个文件的size值,N为正整数。
可选地,所述索引文件生成模块,还用于按照key值前缀分层存储所述索引文件的索引,其中,所述key值前缀对应的分层中存储的索引的key值为截去所述key值前缀的简短key值,其中,所述key值前缀的字节长度小于N。
可选地,所述索引文件的索引的offset值是以所述索引所在分层为偏移范围的层内offset值,所述层内offset值的字节数是根据分层的最大层地址空间确定的。
可选地,所述装置还包括:映射模块,用于将所述数据文件中的所有文件映射到bloom filter中,以使读取所述数据文件中的文件时通过搜索所述bloom filter来判断将要读取的文件是否可能存在。
根据本发明的另一个方面,还提供了一种在上述的文件存储和索引装置中读取文件的方法,包括:根据将要读取的文件的实际key值的前N字节查询所述索引文件中所述实际key值的前N字节对应的索引;根据所述实际key值,在所述实际key值的前N字节对应的索引指向的一个或者多个文件中匹配文件;在匹配到key值与所述实际key值一致的文件时,读取该文件。
可选地,根据将要读取的文件的实际key值的前N字节查询所述索引文件中所述实际key值的前N字节对应的索引包括:根据所述bloom filter判断将要读取的文件是否可能存在;在判断结果为可能存在的情况下,根据将要读取的文件的实际key值的前N字节查询所述索引文件中所述实际key值的前N字节对应的索引,否则终止读取文件。
通过本发明,采用按照文件的实际key值的字母顺序存储各文件,得到数据文件;生成用于索引数据文件中各文件的索引文件,其中,索引文件中的索引使用各文件的实际key值的前N字节作为key值,每个索引指向数据文件中的一个或者多个文件,key值对应的offset值为key值指向的一个或者多个文件中首个文件的offset值,key值对应的size值为key值指向的一个或者多个文件中首个文件的size值的方式,解决了Haystack系统采用的索引方案对内存资源消耗大的问题,降低了索引系统对内存资源的消耗。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是根据本发明实施例的文件存储和索引方法的流程图;
图2是根据本发明实施例的文件存储和索引装置的结构框图;
图3是根据本发明实施例的在文件存储和索引装置中读取文件的方法的流程图;
图4是根据本发明优选实施例的文件存储和索引结构的示意图;
图5是根据本发明优选实施例的读取文件的方法的流程图;
图6、图7和图8是根据本发明优选实施例的索引分层示意图;
图9和图10是根据本发明优选实施例与相关技术的索引方案的内存消耗对比示意图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。
需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。
实施例1
在本实施例中提供了一种文件存储和索引方法,图1是根据本发明实施例的文件存储和索引方法的流程图。如图1所示,该流程包括如下步骤:
步骤S101,按照文件的实际key值的字母顺序存储各文件,得到数据文件;
步骤S102,生成用于索引数据文件中各文件的索引文件,其中,索引文件中的索引使用各文件的实际key值的前N字节作为key值,每个索引指向数据文件中的一个或者多个文件,key值对应的offset值为key值指向的一个或者多个文件中首个文件的offset值,key值对应的size值为key值指向的一个或者多个文件中首个文件的size值,N为正整数。
在上述步骤中,由于在索引中不再保存文件实际key值,而是仅保存实际key值的前N字节,减少了索引文件的大小;同时,这样的索引不再指向一个文件,而会指向实际key值的前N字节相同的一个或者多个文件;为了能够根据索引中的offset值定位到文件的位置,在存储文件时把文件按照实际key值的字母顺序依次存储到数据文件中,使得实际key值的前N字节相同的一个或者多个文件集中存储在一片连续的位置上,得以使用一个offset值来指示它们的存储位置。可见,在将步骤S102中生成的索引文件加载到内存中之后,相对于相关技术的Haystack系统而言,将会占用更少的内存资源,解决了Haystack系统采用的索引方案对内存资源消耗大的问题,降低了索引系统对内存资源的消耗。
在采用步骤S102生成的索引文件索引某一个文件时,根据索引不再能直接索引到某一个确定的文件,而将会索引到一个连续的文件集合;在需要精确读取某一个文件时,只要根据这个文件的实际key值,在文件集合中逐一匹配文件就可能读取到想要的文件。
可选地,上述索引文件中的offset字段和size字段是通过512字节对齐的;即如果一个文件是1024字节大小,按照512字节对齐,1024/512=2,则文件大小可以用2表示,当在索引中得到size是2,用2乘以512字节就可以得到文件的大小是1024字节;之前需要保存的是1024,现在只需要保存2这个数字,至少节省一个字节。并且还可以根据整个数据文件的实际大小计算offset字段和size字段所需使用的字节数,从而可以进一步减小索引所占用的字节数。
为了能够进一步减小索引所占用的字节数,考虑到索引文件中存储的key值仍有key值前缀重复的可能行,因此,还可以考虑对索引文件中的索引按照key值前缀进行分层存储,其中,key值前缀对应的分层中存储的索引的key值为截去key值前缀的简短key值,key值前缀的字节长度小于N。在该分层中索引数量越多的情况下,分层后的索引文件占用的字节数相对于原来的索引文件将会更小。
在索引文件采用分层存储之后,各分层内的索引的offset值可以进一步优化以减少字节数。可选地,索引文件的索引的offset值是以索引所在分层为偏移范围的层内offset值,该层内offset值的字节数是根据分层的最大层地址空间确定的。由于最大层地址空间必然小于整个数据文件的大小,因此,层内offset值占用的字节数也将小于按照整个数据文件为偏移范围的原始offset值占用的字节数。
bloom filter是一种二进制向量数据结构,它具有很好的空间和时间效率,被用来检测一个元素是不是集合中的一个成员。如果检测结果为是,该元素不一定在集合中;但如果检测结果为否,该元素一定不在集合中。Bloom filter优点是它的插入和查询时间都是常数,另外它查询元素却不保存元素本身,具有良好的安全性。在本发明中,由于一个索引指向多个文件,因此有必要利用bloom filter,以通过快速搜索文件是否可能存在来避免对不存在文件的查询所造成的资源和时间浪费。可选地,本实施例中还将数据文件中的所有文件映射到bloom filter中,以使读取数据文件中的文件时通过快速搜索bloomfilter来判断将要读取的文件是否可能存在。
本发明实施例中N的取值优选为4。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
实施例2
在本实施例中还提供了一种文件存储和索引装置,该装置用于实现上述实施例及优选实施方式,已经进行过说明的不再赘述。如以下所使用的,术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现,但是硬件,或者软件和硬件的组合的实现也是可能并被构想的。
图2是根据本发明实施例的文件存储和索引装置的结构框图,如图2所示,该装置包括:数据文件存储模块21和索引文件生成模块22,其中,
数据文件存储模块21,用于存储数据文件,其中,数据文件是按照文件的实际key值的字母顺序存储各文件所得到的;索引文件生成模块22,耦合至数据文件存储模块21,用于生成用于索引数据文件中各文件的索引文件,其中,索引文件中的索引使用各文件的实际key值的前N字节作为key值,每个索引指向数据文件中的一个或者多个文件,key值对应的offset值为key值指向的一个或者多个文件中首个文件的offset值,key值对应的size值为key值指向的一个或者多个文件中首个文件的size值,N为正整数。
可选地,索引文件生成模块还用于按照key值前缀分层存储索引文件的索引,其中,key值前缀对应的分层中存储的索引的key值为截去key值前缀的简短key值,其中,key值前缀的字节长度小于N。
可选地,索引文件的索引的offset值是以索引所在分层为偏移范围的层内offset值,层内offset值的字节数是根据分层的最大层地址空间确定的。
可选地,上述文件存储和索引装置还包括:映射模块,用于将数据文件中的所有文件映射到bloom filter中,以使读取数据文件中的文件时通过搜索bloom filter来判断将要读取的文件是否可能存在。
需要说明的是,上述各个模块是可以通过软件或硬件来实现的,对于后者,可以通过以下方式实现,但不限于此:上述模块均位于同一处理器中;或者,上述模块分别位于多个处理器中。
本发明实施例中N的取值优选为4。
实施例3
在本实施例中提供了一种在上述的文件存储和索引装置中读取文件的方法,图3是根据本发明实施例的在文件存储和索引装置中读取文件的方法的流程图,如图3所示,该流程包括如下步骤:
步骤S301,根据将要读取的文件的实际key值的前N字节查询索引文件中实际key值的前N字节对应的索引;
步骤S302,根据实际key值,在实际key值的前N字节对应的索引指向的一个或者多个文件中匹配文件;
步骤S303,在匹配到key值与实际key值一致的文件时,读取该文件。
可选地,在步骤S301中,在查询索引之前,还可以根据bloom filter判断将要读取的文件是否可能存在;在判断结果为可能存在的情况下,根据将要读取的文件的实际key值的前N字节查询索引文件中实际key值的前N字节对应的索引,否则终止读取文件。
本发明实施例中N的取值优选为4。
实施例4
为了使本发明实施例的描述更加清楚,下面结合优选实施例进行描述和说明。
在本优选实施例中提供了一种文件存储和索引结构和方法,图4是根据本发明优选实施例的文件存储和索引结构的示意图,如图4所示,其中,layer是分层文件,将相同的key前缀分为一层。Index是索引文件,对小文件进行定位。data是数据文件,其中的每个needle都是一个小文件。
图5是根据本发明优选实施例的读取文件的方法的流程图,在图5中示出了通过匹配索引前缀,定位小文件的具体位置,然后通过读取完整的key,来查看文件的key是否匹配,如果不匹配再继续顺序查找下一个needle的详细流程。
本优选实施例提供的文件存储和索引方案包括下列步骤:
步骤1:压缩前缀优化,减少key、offset、size占用空间;
(1)数据文件组织:
与Facebook的Haystack类似,该系统将多个小文件写入到一个数据文件中,每个needle保存key、size、data等信息。
(2)索引文件组织:
1)索引文件只保存key的前四字节,而非完整的key;
2)索引文件中的offset和size字段,通过512字节对齐,节省1个字节;并根据整个数据文件实际大小计算offset和size使用的字节数。
步骤2:needle顺序存放,定位小文件位置;
数据文件中的needle按照key的字母顺序存放。
由于索引文件的key,只保存前四字节,如果小文件key的前四字节相同,不顺序存放needle,则无法根据一个offset找到分散存放的全部needle的具体位置。例如:用户读取的文件key是0x ab cd ef ac ee,但由于索引文件中的key只保存前四字节,只能匹配0xab cd ef ac这个前缀,此时无法定位到具体要读取的offset。
在本优选实施例中,通过needle顺序存放,来解决上述问题:例如:用户读取文件的key是0x ab cd ef ac bb,匹配到0x ab cd ef ac这个前缀,此时offset指向0x ab cdef ac aa这个needle,第一次匹配未命中。
通过存放在needle的header(文件头)中的size,我们可以定位0x abcdef ac bb位置,匹配到正确needle,并将数据读取给用户。
步骤3:索引分层优化;
(1)分层方案
参考图6,可以将索引中key值前缀相同的索引分为一层。分层原则是每个分层中的needle数尽量控制在64个左右,并且根据分层要存放的needle数量,选择分层级别。分层级别可以根据需要确定,例如下面给出了一种分层级别的示例:
0级:不进行分层;
1级:选择needle key第一字节进行分层;
2级:选择needle key的前两字节进行分层;
分层所用的key值前缀的字节数小于索引中key值的字节长度。
(2)分层减少Key的占用字节数
参考图7,通过分层,只保存一份重复的前缀,节省key的字节数。
(3)分层减少offset的占用字节数
参考图8,优化前的offset,偏移范围为整个数据文件的地址空间。优化后,layer的offset在整个数据文件中进行偏移,而分层下的索引的offset只需在数据文件中的层内进行偏移,根据最大的层地址空间可以计算所需字节数。
此外,在本优选实施例中,还通过bloomfilter避免不存在文件的访问。
在内存中,将存在的文件映射到bloom filter中,只需要通过快速搜索,就可以排除掉不存在文件。时间复杂度为O(k),k为一个元素需要的bit位数。经验表明,当k为9.6时,误报率为1%,如果k再增加4.8,误报率会降低到0.1%。
下面将以Haystack为参考说明本发明优选实施例的有益效果。
(1)通过前缀压缩,带来的内存节省对比
参考图9,横轴表示文件数,纵轴表示索引文件需要的内存大小,短虚线表示传统的Haystack的内存消耗量,长虚线表示通过本发明实施例进行前缀压缩后的内存消耗量。从图9可以看出在文件数量为10亿的情况下,使用facabook的Haystack消耗的内存为26G多,使用本优选实施例提供的压缩前缀的索引方案消耗的内存为9G多,内存使用降低了2/3。
(2)再次通过索引分层,带来的内存节省对比
参考图10,横轴表示文件数,纵轴表示索引文件需要的内存大小,短虚线表示传统的Haystack的内存消耗量,长虚线表示通过本发明实施例进行前缀压缩后的内存消耗量,实线表示通过本发明实施例进行前缀压缩并索引分层后的内存消耗量。从图10可以看出,在进行索引分层后,从优化之前的9G多内存消耗,进一步降低到4G多,又节省了1半的内存消耗。
在试验本优选实施例提供的文件存储和索引方案后,小文件的整体性能有显著提高,每秒请求数(RequestPerSecond,简称为RPS)提升一倍多,机器的输入输出(Input/Output,简称为IO)使用率减少了将近一倍。同时,因为优化了最小存储单元,碎片降低80%。使用该系统我们可以为用户提供更快速地读写服务,并且节省了集群的资源消耗。
实施例5
在本实施例中提供了一种软件,该软件用于执行上述实施例及优选实施方式中描述的技术方案。
实施例6
本发明的实施例还提供了一种存储介质。在本实施例中,上述存储介质可以被设置为存储用于执行以下步骤的程序代码:
步骤S101,按照文件的实际key值的字母顺序存储各文件,得到数据文件;
步骤S102,生成用于索引数据文件中各文件的索引文件,其中,索引文件中的索引使用各文件的实际key值的前N字节作为key值,每个索引指向数据文件中的一个或者多个文件,key值对应的offset值为key值指向的一个或者多个文件中首个文件的offset值,key值对应的size值为key值指向的一个或者多个文件中首个文件的size值,N为正整数。
可选地,在本实施例中,上述存储介质可以包括但不限于:U盘、只读存储器(Read-Only Memory,简称为ROM)、随机存取存储器(Random Access Memory,简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
可选地,本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例,本实施例在此不再赘述。
实施例7
本发明的实施例还提供了一种存储介质。在本实施例中,上述存储介质可以被设置为存储用于执行以下步骤的程序代码:
步骤S301,根据将要读取的文件的实际key值的前N字节查询索引文件中实际key值的前N字节对应的索引;
步骤S302,根据实际key值,在实际key值的前N字节对应的索引指向的一个或者多个文件中匹配文件;
步骤S303,在匹配到key值与实际key值一致的文件时,读取该文件。
可选地,在本实施例中,上述存储介质可以包括但不限于:U盘、只读存储器(Read-Only Memory,简称为ROM)、随机存取存储器(Random Access Memory,简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
可选地,本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例,本实施例在此不再赘述。
显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (9)
1.一种文件存储和索引方法,其特征在于包括:
按照文件的实际key值的字母顺序存储各文件,得到数据文件;
生成用于索引所述数据文件中各文件的索引文件,其中,所述索引文件中的索引使用各文件的实际key值的前N字节作为key值,每个索引指向所述数据文件中的一个或者多个文件,所述key值对应的offset值为所述key值指向的一个或者多个文件中首个文件的offset值,所述key值对应的size值为所述key值指向的一个或者多个文件中首个文件的size值,N为正整数;
按照key值前缀分层存储所述索引文件的索引,其中,所述key值前缀对应的分层中存储的索引的key值为截去所述key值前缀的简短key值,其中,所述key值前缀的字节长度小于N。
2.根据权利要求1所述的方法,其特征在于,所述索引文件中的offset字段和size字段是通过512字节对齐的。
3.根据权利要求1所述的方法,其特征在于,
所述索引文件的索引的offset值是以所述索引所在分层为偏移范围的层内offset值,所述层内offset值的字节数是根据分层的最大层地址空间确定的。
4.根据权利要求1至3中任一项所述的方法,其特征在于,所述方法还包括:
将所述数据文件中的所有文件映射到bloomfilter中,以使读取所述数据文件中的文件时通过快速搜索所述bloomfilter来判断将要读取的文件是否可能存在。
5.一种文件存储和索引装置,其特征在于包括:
数据文件存储模块,用于存储数据文件,其中,所述数据文件是按照文件的实际key值的字母顺序存储各文件所得到的;
索引文件生成模块,用于生成用于索引所述数据文件中各文件的索引文件,其中,所述索引文件中的索引使用各文件的实际key值的前N字节作为key值,每个索引指向所述数据文件中的一个或者多个文件,所述key值对应的offset值为所述key值指向的一个或者多个文件中首个文件的offset值,所述key值对应的size值为所述key值指向的一个或者多个文件中首个文件的size值,N为正整数;所述索引文件生成模块,还用于按照key值前缀分层存储所述索引文件的索引,其中,所述key值前缀对应的分层中存储的索引的key值为截去所述key值前缀的简短key值,其中,所述key值前缀的字节长度小于N。
6.根据权利要求5所述的装置,其特征在于,
所述索引文件的索引的offset值是以所述索引所在分层为偏移范围的层内offset值,所述层内offset值的字节数是根据分层的最大层地址空间确定的。
7.根据权利要求5或6中任一项所述的装置,其特征在于,所述装置还包括:
映射模块,用于将所述数据文件中的所有文件映射到bloomfilter中,以使读取所述数据文件中的文件时通过搜索所述bloomfilter来判断将要读取的文件是否可能存在。
8.一种在权利要求5至7中任一项所述的文件存储和索引装置中读取文件的方法,其特征在于包括:
根据将要读取的文件的实际key值的前N字节查询所述索引文件中所述实际key值的前N字节对应的索引;
根据所述实际key值,在所述实际key值的前N字节对应的索引指向的一个或者多个文件中匹配文件;
在匹配到key值与所述实际key值一致的文件时,读取该文件。
9.根据权利要求8所述的方法,其特征在于,根据将要读取的文件的实际key值的前N字节查询所述索引文件中所述实际key值的前N字节对应的索引包括:
根据所述bloom filter判断将要读取的文件是否可能存在;
在判断结果为可能存在的情况下,根据将要读取的文件的实际key值的前N字节查询所述索引文件中所述实际key值的前N字节对应的索引,否则终止读取文件。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201611221215.1A CN106874348B (zh) | 2016-12-26 | 2016-12-26 | 文件存储和索引方法、装置及读取文件的方法 |
PCT/CN2017/117967 WO2018121430A1 (zh) | 2016-12-26 | 2017-12-22 | 文件存储和索引方法、装置、介质、设备及读取文件的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201611221215.1A CN106874348B (zh) | 2016-12-26 | 2016-12-26 | 文件存储和索引方法、装置及读取文件的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN106874348A CN106874348A (zh) | 2017-06-20 |
CN106874348B true CN106874348B (zh) | 2020-06-16 |
Family
ID=59164487
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201611221215.1A Active CN106874348B (zh) | 2016-12-26 | 2016-12-26 | 文件存储和索引方法、装置及读取文件的方法 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN106874348B (zh) |
WO (1) | WO2018121430A1 (zh) |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106874348B (zh) * | 2016-12-26 | 2020-06-16 | 贵州白山云科技股份有限公司 | 文件存储和索引方法、装置及读取文件的方法 |
CN110209489B (zh) * | 2018-02-28 | 2020-07-31 | 贵州白山云科技股份有限公司 | 一种适用于内存页结构的内存管理方法及装置 |
CN109614411B (zh) * | 2018-11-19 | 2022-03-04 | 杭州复杂美科技有限公司 | 数据存储方法、设备和存储介质 |
CN110502472A (zh) * | 2019-08-09 | 2019-11-26 | 西藏宁算科技集团有限公司 | 一种大量小文件的云存储优化方法及其系统 |
CN110825940B (zh) * | 2019-09-24 | 2023-08-22 | 武汉智美互联科技有限公司 | 网络数据包存储和查询方法 |
CN112748866A (zh) * | 2019-10-31 | 2021-05-04 | 北京沃东天骏信息技术有限公司 | 一种增量索引数据的处理方法和装置 |
CN111639076B (zh) * | 2020-05-14 | 2023-12-22 | 民生科技有限责任公司 | 一种跨平台高效键值存储方法 |
CN113312313B (zh) * | 2021-01-29 | 2023-09-29 | 淘宝(中国)软件有限公司 | 数据查询方法、非易失性存储介质及电子设备 |
CN112765113B (zh) * | 2021-01-31 | 2024-04-09 | 云知声智能科技股份有限公司 | 索引压缩方法、装置、计算机可读存储介质及电子设备 |
CN115827573B (zh) * | 2023-02-16 | 2023-06-02 | 麒麟软件有限公司 | 基于Linux的key-value形数据存储和使用方法 |
CN117271440B (zh) * | 2023-11-21 | 2024-02-06 | 深圳市云希谷科技有限公司 | 一种基于freeRTOS文件信息存储方法、读取方法及相关设备 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103870492A (zh) * | 2012-12-14 | 2014-06-18 | 腾讯科技(深圳)有限公司 | 一种基于键排序的数据存储方法和装置 |
US8862555B1 (en) * | 2011-05-16 | 2014-10-14 | Trend Micro Incorporated | Methods and apparatus for generating difference files |
CN105117417A (zh) * | 2015-07-30 | 2015-12-02 | 西安交通大学 | 一种读优化的内存数据库Trie树索引方法 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1227413A1 (en) * | 2001-01-25 | 2002-07-31 | Telefonaktiebolaget L M Ericsson (Publ) | Method for optimised locating of indexed records of static data with different length |
CN102779180B (zh) * | 2012-06-29 | 2015-09-09 | 华为技术有限公司 | 数据存储系统的操作处理方法,数据存储系统 |
CN103914483B (zh) * | 2013-01-07 | 2018-09-25 | 深圳市腾讯计算机系统有限公司 | 文件存储方法、装置及文件读取方法、装置 |
CN104572670B (zh) * | 2013-10-15 | 2019-07-23 | 方正国际软件(北京)有限公司 | 一种小文件的存储、查询及删除方法和系统 |
CN103810246B (zh) * | 2013-12-27 | 2017-10-13 | 北京天融信软件有限公司 | 一种索引创建方法和装置以及索引查询方法和装置 |
CN105069048A (zh) * | 2015-07-23 | 2015-11-18 | 东方网力科技股份有限公司 | 一种小文件存储方法、查询方法和装置 |
CN106874348B (zh) * | 2016-12-26 | 2020-06-16 | 贵州白山云科技股份有限公司 | 文件存储和索引方法、装置及读取文件的方法 |
-
2016
- 2016-12-26 CN CN201611221215.1A patent/CN106874348B/zh active Active
-
2017
- 2017-12-22 WO PCT/CN2017/117967 patent/WO2018121430A1/zh active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8862555B1 (en) * | 2011-05-16 | 2014-10-14 | Trend Micro Incorporated | Methods and apparatus for generating difference files |
CN103870492A (zh) * | 2012-12-14 | 2014-06-18 | 腾讯科技(深圳)有限公司 | 一种基于键排序的数据存储方法和装置 |
CN105117417A (zh) * | 2015-07-30 | 2015-12-02 | 西安交通大学 | 一种读优化的内存数据库Trie树索引方法 |
Also Published As
Publication number | Publication date |
---|---|
WO2018121430A1 (zh) | 2018-07-05 |
CN106874348A (zh) | 2017-06-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106874348B (zh) | 文件存储和索引方法、装置及读取文件的方法 | |
CN105468642A (zh) | 数据的存储方法及装置 | |
CN107704202B (zh) | 一种数据快速读写的方法和装置 | |
CN110888837B (zh) | 对象存储小文件归并方法及装置 | |
CN103399823A (zh) | 业务数据的存储方法、设备和系统 | |
CN109240607B (zh) | 一种文件读取方法和装置 | |
CN105117351A (zh) | 向缓存写入数据的方法及装置 | |
CN105677904B (zh) | 基于分布式文件系统的小文件存储方法及装置 | |
CN114138193A (zh) | 一种分区命名空间固态硬盘的数据写入方法、装置及设备 | |
CN107798063B (zh) | 快照处理方法和快照处理装置 | |
CN112416880A (zh) | 一种基于实时归并的海量小文件存储性能优化方法及装置 | |
CN107423321B (zh) | 适用大批量小文件云存储的方法及其装置 | |
CN108399175B (zh) | 一种数据存储、查询方法及其装置 | |
CN107423425B (zh) | 一种对k/v格式的数据快速存储和查询方法 | |
CN109460406A (zh) | 一种数据处理方法及装置 | |
US20170083537A1 (en) | Mapping logical identifiers using multiple identifier spaces | |
CN114721594A (zh) | 一种分布式存储方法、装置、设备及机器可读存储介质 | |
CN103970844A (zh) | 大数据的写入方法和装置、读取方法和装置及处理系统 | |
CN116842012A (zh) | 一种Redis集群的分片存储方法、装置、设备及存储介质 | |
EP3343395B1 (en) | Data storage method and apparatus for mobile terminal | |
CN107844483B (zh) | 文件管理方法及装置 | |
CN110221778A (zh) | 酒店数据的处理方法、系统、存储介质以及电子设备 | |
US20130218851A1 (en) | Storage system, data management device, method and program | |
CN111258955B (zh) | 一种文件读取方法和系统、存储介质、计算机设备 | |
CN115221360A (zh) | 树形结构配置方法和系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
CB02 | Change of applicant information | ||
CB02 | Change of applicant information |
Address after: 100015 5 floor, block E, 201 IT tower, electronic city, 10 Jiuxianqiao Road, Chaoyang District, Beijing. Applicant after: Guizhou Baishan cloud Polytron Technologies Inc Address before: 100015 5 floor, block E, 201 IT tower, electronic city, 10 Jiuxianqiao Road, Chaoyang District, Beijing. Applicant before: Guizhou white cloud Technology Co., Ltd. |
|
GR01 | Patent grant | ||
GR01 | Patent grant |