CN114398324A - 一种适用于分布式存储系统的文件名编码方法 - Google Patents

一种适用于分布式存储系统的文件名编码方法 Download PDF

Info

Publication number
CN114398324A
CN114398324A CN202210013505.6A CN202210013505A CN114398324A CN 114398324 A CN114398324 A CN 114398324A CN 202210013505 A CN202210013505 A CN 202210013505A CN 114398324 A CN114398324 A CN 114398324A
Authority
CN
China
Prior art keywords
key
directory
file
file name
storage system
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.)
Granted
Application number
CN202210013505.6A
Other languages
English (en)
Other versions
CN114398324B (zh
Inventor
叶靖
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Upyun Technology Co ltd
Original Assignee
Hangzhou Upyun Technology Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hangzhou Upyun Technology Co ltd filed Critical Hangzhou Upyun Technology Co ltd
Priority to CN202210013505.6A priority Critical patent/CN114398324B/zh
Publication of CN114398324A publication Critical patent/CN114398324A/zh
Application granted granted Critical
Publication of CN114398324B publication Critical patent/CN114398324B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/16File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G06F16/164File meta data generation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/182Distributed file systems

Abstract

本发明公开了一种适用于分布式存储系统的文件名编码方法,包括:分布式存储系统的文件名进行编码具体包括:根据文件名的最后一个字符判断文件名的类型,得到Key’;根据目录分隔符进行切分,得到A。取路径列表A的第一个元素到倒数第二个元素,将这些路径以/~符号进行连接,记为B;如果文件名的类型为目录,则加@~符号,得到C;取获取的B和C以/符号进行连接,获取最终编码后的Key’’,即Key’’=B/C。本发明通过对文件Key进行合理的编码,在不损失文件查找效率的同时,可以非常高效地进行列目录操作。本发明不需要额外的目录系统,就可以实现高效地列超大目录的操作,还可以支持仅列文件或仅列子目录操作。

Description

一种适用于分布式存储系统的文件名编码方法
技术领域
本发明涉及文件名编码方法领域,具体涉及一种适用于分布式存储系统的文件名编码方法。
背景技术
随着企业数据字化改造的不断推进,拥有PB级甚至几十PB级文件存储量的企业越来越多。传统的单机存储系统已经无法承受庞大且不断增长的存储规模,构建分布式存储系统来存储图片、音视频、文档等文件成了大多数据企业在数字化改造进程中的强烈需求。分布式存储系统软件通过网络对多台机器的磁盘进行统一管理和使用,以突破单机存储容量的限制。分布式存储系统通常以Key-Value的形式存储文件,文件的文件名(一般为绝对路径)作为Key(如:/a/b/c.jpg,/表示目录分隔符),文件的内容作为Value,多个文件按Key的字典顺序进行存储。Key-Value方式存储的特点是可以快速地根据文件Key定位到具体文件,或者快速地进行前缀匹配(找出Key前缀相同的文件)操作。在根据Key查找文件时,由于文件的Key是按字典序存放的,可以利用二分法等方法快速定位到文件的具体存储位置。在做前缀匹配操作时,可以先定位到前缀第一个key 的位置,顺序往后做遍历,就能找出所有相同前缀的Key。这种Key-Value形式的存储方法在已知文件的Key时可以非常高效地定位到具体文件,但是这种存储方法无法快速地进行列目录操作。以下是一个具体的例子:
a/1.jpg;
a/b/2.jpg;
a/b/c/3.jpg;
a/c/4.jpg;
a/d.jpg。
以上5个文件按Key的字典序进行存储,假如我们需要列a/目录下的所有文件和目录,结果应该是1.jpg、b/、c/、d.jpg,其中b/,c/是子目录,1.jpg和d.jpg是文件。列目录操作不能简单地用前缀匹配操作来替代,在上列中,a/目录的前缀匹配结果是1.jpg、b/2.jpg、b/c/3.jpg、c/4.jpg、c/4.jpg、d.jpg。可以看到,前缀匹配与列目录的结果不一致,会列出目录的子目录下所有文件。
一种改进的使用前缀匹配的方式来列目录的方法需要遍历从a/开始的所有Key,然后提取出所有属于a/目录的一级子目录或文件。在上例中,a/b/是a/目录的一级子目录,而a/b/c/不是,因而只需要列出a/b/,不应该列出a/b/c/。这种方法在所列目录的子目录下文件数量较少时是可以使用的,但是当所列目录的子目录下文件数量非常多的时候,就会有非常严重的性能问题。例如在上例中,假如a/b/目录下有几百万上千万个文件时,遍历所有这些Key将会消费非常多的时间和资源,极大地影响用户体验。
另外一种常见的实现列目录操作的方法是将文件操作与目录操作分开,为目录操作单独准备一套目录系统,存储目录下所有的子目录和文件的信息。例如在上例中存储a/目录的子目录为1.jpg、b/、c/、d.jpg。这种方式有以下缺点:
1)需要多维护一套目录系统,带来更大的硬件成本和维护成本;
2)会引起文件存储系统握目录系统的不一致。例如a/1.jpg文件在文件系统中写入成功,而由于硬件或软件故障写入目录系统失败了,这时候列目录就无法列出1.jpg,但是a/1.jpg这个文件又是能读到的,从而有可能造成业务逻辑错乱;
3)更新目录系统时开销比较大。有新文件产生或旧文件删除时都需要更新目录系统,一方在增加了整体操作的响应时间,另一方面,当更新层级很深的目录时,需要逐级对目录系统中所有父目录进行更新,进一步增加了响应时间。例如在增加a/b/c/d/e/f/g.jpg文件时,不仅需要更新a/b/c/d/e/f/目录的文件信息,还需要逐级更新a/b/c/d/e/、a/b/c/d/、a/b/c/、a/b/、a/目录的子目录信息。
列目录操作是在单机文件系统中的常用操作,然而由于Key-Value存储结构在列大目录时潜在的性能问题,大多数据分布式存系统甚至一些公有云厂商都仅支持了列前缀的操作而不支持列目录的操作,或者只支持列部分目录的操作(例如只能列包含子文件数量少于10000个的目录),这使得用户在使用时感到非常不方便。
发明内容
本发明提出了一种适用于分布式存储系统的文件名编码方法,通过对文件Key进行合理的编码,在不损失文件查找效率的同时,可以非常高效地进行列目录操作。本发明不需要额外的目录系统,就可以实现高效地列超大目录的操作,还可以支持仅列文件或仅列子目录操作。
一种适用于分布式存储系统的文件名编码方法,包括以下步骤:
先对需要存储的文件的文件名进行编码,再将编码后的文件上传到分布式存储系统;
所述的文件名进行编码具体包括:
1)根据文件名(Key)的最后一个字符判断文件名(Key)的类型,得到Key’;
2)对步骤1)得到的Key’根据目录分隔符进行切分,得到切分后的路径列表,记为A;
3)取步骤2)中切分的路径列表A的第一个元素到倒数第二个元素,将这些路径以/~符号进行连接,记为B;
如果步骤2)中切分的路径列表A只包含一个元素,则跳过此步骤,进入步骤5);
4)取步骤2)中切分的路径列表A的最后一个元素,记为x;
如果文件名(Key)的类型为文件,则在x前加@#符号;
如果文件名(Key)的类型为目录,则在x前加@~符号,得到C;
5)取步骤3)和步骤4)获取的B和C以/符号进行连接,获取最终编码后的Key’’,即Key’’=B/C;
如果步骤2)中获得的路径列表A只包含一个元素,则Key’’=C。
以下作为本发明的优选技术方案,以下进行进一步说明。
步骤1)中,具体包括:
1.1)获取文件名(Key)的最后一个字符;
1.2)如果最后一个字符为/,则记录该文件名(Key)的类型为目录,并去掉最后的/,得到Key’;
1.3)如果最后一个字符不为/,则记录该文件名(Key)的类型为文件,得到Key’。
步骤2)中,所述的目录分隔符为/或\。具体包括:/为预定的目录分隔符,在Linux操作系统或URL中一般以/作为目录分隔符,在Windows操作系统中一般以\作为目录分隔符。
相比于之前的Key-value,假如a/b/目录下有几百万上千万个文件时,遍历所有这些Key将会消费非常多的时间和资源,极大地影响用户体验。另外一种常见的实现列目录操作的方法是将文件操作与目录操作分开,为目录操作单独准备一套目录系统,存储目录下所有的子目录和文件的信息。
本发明通过步骤1)~5)将Key进行编码,从而使列目录操作转化为前缀匹配操作,在Key-Value类型分布式存储系统中实现了高效列目录的功能,解决了Key在未编码时只能做前缀匹配的缺点,本发明通过多次批量返回结果,可以支持列超大目录的操作,支持几百万、几千万以上的目录的操作。
与现有技术相比,本发明具有如下优点。
(1)本发明通过将Key进行编码,从而使列目录操作转化为前缀匹配操作,在Key-Value类型分布式存储系统中实现了高效列目录的功能,解决了Key在未编码时只能做前缀匹配的缺点。
(2) 本发明在实现高效列目录的同时,保留了前缀匹配的能力。
(3)本发明只需要一个分布式存储系统,不需要额外的目录系统,大大减少了硬件成本和维护成本,也避免了两套系统带来的不一致问题。
(4)本发明只需要对原始的Key进行少量的字符串修改,保留了Key的结构和可读性,存储占用量小,并且具有非常高的编解码效率。
(5)本发明在创建多级目录时采用异步操作方式,减小了请求的响应时间,提升了用户体验。
(6)本发明支持仅列目录或仅列文件操作,并且结果不需要二次过滤,非常高效,可以实现类似本地文件系统的优先显示目录或优先显示文件的功能。
(7)本发明通过批量返回结果,可以支持列超大目录的操作。
附图说明
图1为本发明适用于分布式存储系统的文件名编码方法的流程示意图。
具体实施方式
如图1所示,以下为Key的编码方法:Key的编码步骤涉及到/、~、@、#这4个特定的Ascii字符,4个字符的Ascii值大小关系(或字典序)为:#</<@<~,并且~为Ascii码表最后一个字符。
以下为Key的编码步骤,进行进一步说明。
1)根据Key的最后一个字符判断Key的类型。获取Key的最后一个字符,如果最后一个字符为/,则记录该Key的类型为目录,并去掉最后的/;如果最后一个字符不为/,则记录该Key的类型为文件。记该步骤新得到的新的Key为Key’。
例如Key=/a/b/ 表示目录,去掉最后的/之后得到Key’=/a/b;Key=/a/c/1.jpg表示文件,得到Key’=/a/c/1.jpg。
2)对步骤1)得到的Key’根据/进行切分,得到切分后的路径列表,记为A。
/为预定的目录分隔符,在Linux操作系统或URL中一般以/作为目录分隔符,在Windows操作系统中一般以\作为目录分隔符。例如:将a/b切分成a、b,得到路径列表A=[a,b];将a/c/1.jpg切分成a、c、1.jpg,得到路径列表A=[a,c,1.jpg]。
3)取步骤2)中切分的路径列表A的第一个元素到倒数第二个元素,将这些路径以/~进行连接,记为B。如果路径列表A只包含一个元素,则跳过此步骤。
例如步骤2)中切分a/b形成的A=[a,b]路径列表,形成B=a;切分a/c/1.jpg获得的A=[a、c、1.jpg]路径列表,形成B=a/~c。
4)取步骤2)中切分的路径列表A的最后一个元素,记为x。如果Key的类型为文件,则在x前加@#;如果Key的类型为目录,则在x前加@~,得到C。
例如A=[a, b]时(b表示目录),C=@~b;A=[a,c,1.jpg]时(1.jpg表示文件),C=@#1.jpg。
5)取步骤3)和步骤4)获取的B和C以/进行连接,获取最终编码后的Key”,即Key”=B/C;如果步骤2)中获得的A只包含一个元素,则Key”=C。
例如B=a,C=@~b时,Key”=a/@~b;B=a/~c,C=@#1.jpg时,Key”=a/~c/@#1.jpg。
以下为Key’’解码方法,进行进一步说明。
1)如果Key’’不包括/,则去掉Key’’开头的@#或@~(由编码过程可知,Key’’如果不包含/则肯定以@#或@~开头),获取Key,解码过程结束。否则跳到步骤2);例如Key’’=@#1.jpg,去掉开头的@#后,得到Key=1.jpg。
2)将Key’’按/~或/@进行分割,得到分割后的路径列表L。例如Key’’=a/~b/@#2.jpg,则L=[a,b,#2.jpg];Key’’=a/~b/@~c,则L=[a,b,~c]。
3)取步骤2)中获得的L的最后一个元素,记为x,如果x以#开头,记录Key类型为文件;如果x以~开头,记录Key类型为目录。去掉x开头的#或~,记为x’,替换L的最后一个元素为x’;例如L=[a,b,#2.jpg]时,替换最后一个元素后的L=[a,b,2.jpg];L=[a,b,~c]时,替换最后一个元素后的L=[a,b,c]。
4)将步骤3)中L中的元素通过/连接,获得Key,解码过程结束。例如L=[a,b,2.jpg]时,Key=a/b/2.jpg;L=[a,b,~c]时,Key=a/b/c/。
以下根据请求的类型做相应的操作,进行进一步说明。
1.上传文件或新建目录。
1)将编码过程中步骤5)中获得的Key’’和Key对应的Value写入分布式存储系统。如果Key的类型为文件,则Value为文件的内容和元数据信息;如果Key的类型为目录,则Value为元数据信息。元数据信息为Key的写入时间、大小、修改时间、权限、所属用户等一些需要存储的信息。
2)将Key以异步的方式发送给目录创建服务,由目录创建服务自动创建Key的各级父目录并写入分布式存储系统。
例如Key为/a/b/c/d/1.jpg时,需要自动创建Key1=/a/,Key2=/a/b/,Key3=/a/b/c/,Key4=/a/b/c/d/这4级父目录,Key1,Key2,Key3,Key4也需要经过步骤1)到步骤5)的编码。
一般情况下,客户端在上传Key=/a/b/c/d/1.jpg文件时,会事先发送/a/、/a/b/、/a/b/c/、/a/b/c/d/这4个目录的创建请求,在这种情况下,各级父目录都已经创建好,可以不用将Key异步发送给目录创建服务。
2.下载文件。
根据编码过程中步骤5)中获得的Key’’从分布式存储系统中找到对应的文件元数据和文件内容,请结果返回给客户端。
3.删除文件或删除空目录。
根据编码过程中步骤5)中获得的Key’’从分布式存储系统中找到对应的文件或目录元数据和文件内容(当删除文件时),将两者删除。
4. 列目录下所有文件和目录。
将需要列目录的Key经过编码过程中步骤1)到步骤3)得到B,设置prefix=B/@,如果步骤3)被跳过,则prefix=@。从分布式存储系统中遍历前缀为prefix的所有Key’’,取出Key’’对应的文件或目录元数据(列目录操作不需要返回文件或目录内容),并和解码后的Key列表一起返回给客户端。
由于Key目录的所有二级以上子目录的前缀经过步1)到3)编码后都是以B/~开头,而B/~的字典序大于B/@,因此,前缀为prefix的所有Key’’均为Key目录下的文件或一级子目录。
如果目录下面有非常多的文件和子目录,为了控制响应大小,一次请求无法将数据完全返回给客户端。这种情况下可以返回本次响应最后一条数据的Key’’记为lastKey给客户端,客户端将再发起一次请求,并带上上一次请求获得的lastKey值。时此服务端从lastKey开始,列前缀为prefix的所有Key’’,再将结果返回给客户端。如此循环直到列完所有前缀为prefix的Key’’。
5. 仅列目录下所有文件。
将需要列目录的Key经过编码过程中步骤1)到步骤3)得到B,设置prefix=B/@#,如果步骤3)被跳过,则prefix=@#。从分布式存储系统中遍历前缀为prefix的所有Key’’,取出Key’’对应的文件元数据(列目录操作不需要返回文件内容),并和解码后的Key列表一起返回给客户端。
6. 仅列目录下所有目录。
将需要列目录的Key经过编码过程中步骤1)到步骤3)得到B,设置prefix=B/@~,如果步骤3)被跳过,则prefix=@~。从分布式存储系统中遍历前缀为prefix的所有Key’’,取出Key’’对应的目录元数据(列目录操作不需要返回目录内容),并和解码后的Key列表一起返回给客户端。
7.删除非空目录。
需要先删除非空目录和子目录下所有文件和子目录,最后删除目录。
8.遍历目录下所有子目录和文件。
将需要列前缀的Key经过编码过程中步骤1)到步骤3)得到B,设置prefix=B/,如果步骤3)被跳过,则prefix=’’(空字符串)。从分布式存储系统中遍历前缀为prefix的所有Key’’,取出Key’’对应的文件或目录元数据(遍历目录操作不需要返回文件或目录内容),并返回给客户端。
以下为具体的例子:
假设要写入的5个Key分别是
a/1.jpg
a/b/2.jpg
a/b/c/3.jpg
a/c/4.jpg
a/d.jpg
编码后Key和存储顺序(从上到下表示字典序)分别为:
a/@#1.jpg
a/@#d.jpg
a/@~b
a/@~c
a/~b/@#2.jpg
a/~b/@~c
a/~b/~c/@#3.jpg
a/~c/@#4.jpg
1. 列a/目录需要遍历a/@开始的所有Key’’,得到a/@#1.jpg、a/@#d.jpg、a/@~b、a/@~c,解码Key’’后得到a/1.jpg、a/d.jpg、a/b/、a/c/;
2. 列a/b/目录需要遍历a/~b/@开头的所有Key’’,得到a/~b/@#2.jpg、a/~b/@~c,解码Key’’后得到a/b/2.jpg、a/b/c/;
3. 列a/b/前缀需要遍历从a/~b/的所有Key’’,得到a/~b/@#2.jpg、a/~b/@~c、a/~b/~c/@#3.jpg,解码Key’’后得到a/b/2.jpg、a/b/c/、a/b/c/3.jpg;
4. 仅列a/b/目录下的文件需要遍历a/~b/@#开头的所有Key’’,得到a/~b/@#2.jpg,解码Key’’后得到a/b/2.jpg;
5. 仅列a/b/目录下的目录需要遍历a/~b/@~开头的所有Key’’,得到a/~b/@~c,解码Key’’后得到a/b/c/。
相比于之前的Key-value,假如a/b/目录下有几百万上千万个文件时,遍历所有这些Key将会消费非常多的时间和资源,极大地影响用户体验。另外一种常见的实现列目录操作的方法是将文件操作与目录操作分开,为目录操作单独准备一套目录系统,存储目录下所有的子目录和文件的信息。
本发明通过将Key进行编码,从而使列目录操作转化为前缀匹配操作,在Key-Value类型分布式存储系统中实现了高效列目录的功能,解决了Key在未编码时只能做前缀匹配的缺点,本发明通过多次批量返回结果,可以支持列超大目录的操作,支持几百万、几千万以上的目录的操作。

Claims (5)

1.一种适用于分布式存储系统的文件名编码方法,其特征在于,包括以下步骤:
先对需要存储的文件的文件名进行编码,再将编码后的文件上传到分布式存储系统;
所述的文件名进行编码具体包括:
1)根据文件名的最后一个字符判断文件名的类型,得到Key’;
2)对步骤1)得到的Key’根据目录分隔符进行切分,得到切分后的路径列表,记为A;
3)取步骤2)中切分的路径列表A的第一个元素到倒数第二个元素,将这些路径以/~符号进行连接,记为B;
4)取步骤2)中切分的路径列表A的最后一个元素,记为x;
如果文件名的类型为文件,则在x前加@#符号;
如果文件名的类型为目录,则在x前加@~符号,得到C;
5)取步骤3)和步骤4)获取的B和C以/符号进行连接,获取最终编码后的Key’’,即Key’’=B/C。
2.根据权利要求1所述的适用于分布式存储系统的文件名编码方法,其特征在于,步骤1)中,具体包括:
1.1)获取文件名的最后一个字符;
1.2)如果最后一个字符为/,则记录该文件名的类型为目录,并去掉最后的/,得到Key’;
1.3)如果最后一个字符不为/,则记录该文件名的类型为文件,得到Key’。
3.根据权利要求1所述的适用于分布式存储系统的文件名编码方法,其特征在于,步骤2)中,所述的目录分隔符为/或\。
4.根据权利要求1所述的适用于分布式存储系统的文件名编码方法,其特征在于,步骤3)中,还包括:
如果步骤2)中切分的路径列表A只包含一个元素,则跳过此步骤,进入步骤5)。
5.根据权利要求1所述的适用于分布式存储系统的文件名编码方法,其特征在于,步骤5)中,还包括:
如果步骤2)中获得的路径列表A只包含一个元素,则Key’’=C。
CN202210013505.6A 2022-01-07 2022-01-07 一种适用于分布式存储系统的文件名编码方法 Active CN114398324B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210013505.6A CN114398324B (zh) 2022-01-07 2022-01-07 一种适用于分布式存储系统的文件名编码方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210013505.6A CN114398324B (zh) 2022-01-07 2022-01-07 一种适用于分布式存储系统的文件名编码方法

Publications (2)

Publication Number Publication Date
CN114398324A true CN114398324A (zh) 2022-04-26
CN114398324B CN114398324B (zh) 2023-04-11

Family

ID=81228230

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210013505.6A Active CN114398324B (zh) 2022-01-07 2022-01-07 一种适用于分布式存储系统的文件名编码方法

Country Status (1)

Country Link
CN (1) CN114398324B (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101447937A (zh) * 2009-02-27 2009-06-03 北京理工大学 一种基于路径划分与多分布目录的快速数据定位方法
US20120284317A1 (en) * 2011-04-26 2012-11-08 Dalton Michael W Scalable Distributed Metadata File System using Key-Value Stores
CN106446001A (zh) * 2016-07-29 2017-02-22 北京北信源软件股份有限公司 一种在计算机存储介质上存储文件的方法及系统
CN109558082A (zh) * 2018-11-26 2019-04-02 深圳天源迪科信息技术股份有限公司 分布式文件系统
US20200045010A1 (en) * 2018-08-02 2020-02-06 MemVerge, Inc Naming Service in a Distributed Memory Object Architecture

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101447937A (zh) * 2009-02-27 2009-06-03 北京理工大学 一种基于路径划分与多分布目录的快速数据定位方法
US20120284317A1 (en) * 2011-04-26 2012-11-08 Dalton Michael W Scalable Distributed Metadata File System using Key-Value Stores
CN106446001A (zh) * 2016-07-29 2017-02-22 北京北信源软件股份有限公司 一种在计算机存储介质上存储文件的方法及系统
US20200045010A1 (en) * 2018-08-02 2020-02-06 MemVerge, Inc Naming Service in a Distributed Memory Object Architecture
CN109558082A (zh) * 2018-11-26 2019-04-02 深圳天源迪科信息技术股份有限公司 分布式文件系统

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
YANG ZHAN等: "The Full Path to Full-Path Indexing", 《16TH USENIX CONFERENCE ON FILE AND STORAGE TECHNOLOGIES》 *
董豪宇等: "纯用户态的网络文件系统——RUFS", 《计算机应用》 *

Also Published As

Publication number Publication date
CN114398324B (zh) 2023-04-11

Similar Documents

Publication Publication Date Title
US11573938B2 (en) Systems and methods for indexing source code in a search engine
US8255398B2 (en) Compression of sorted value indexes using common prefixes
US8175875B1 (en) Efficient indexing of documents with similar content
US7548928B1 (en) Data compression of large scale data stored in sparse tables
US5742817A (en) Method and apparatus for file server addressing
CN111259006A (zh) 一种通用的分布式异构数据一体化物理汇聚、组织、发布与服务方法及系统
US7574457B2 (en) Non-mutating tree-structured file identifiers
CN107851118A (zh) 下一代测序数据的存储、传输和压缩
WO2021237467A1 (zh) 文件上传方法、文件下载方法和文件管理装置
CN103299297A (zh) 文件目录存储方法、检索方法和设备
CN111046041A (zh) 数据处理方法和装置、存储介质及处理器
JP2004536481A (ja) 構造化文書の木構造におけるパスの符号化および復号化方法
CN114398324B (zh) 一种适用于分布式存储系统的文件名编码方法
EP1311978A1 (en) Focal point compression method and apparatus
CN104750815A (zh) 一种基于HBase的Lob数据的存储方法及装置
US6714950B1 (en) Methods for reproducing and recreating original data
CN109803022B (zh) 一种数字化资源共享系统及其服务方法
EP4002143A1 (en) Storage of file system items related to a versioned snapshot of a directory-based file system onto a key-object storage system
JPH10261969A (ja) データ圧縮方法および装置
CN111125129A (zh) 数据处理方法和装置、存储介质及处理器
CN115794861A (zh) 基于特征摘要的离线数据查询复用方法及其应用
CN107291574B (zh) 基于解释系统的备份数据恢复主键生成方法
US10956440B2 (en) Compressing a plurality of documents
JP4510041B2 (ja) 文書検索システム及びプログラム
JP7377915B2 (ja) 個別データ検索サービスを提供する方法、コンピュータ装置、およびコンピュータプログラム

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
GR01 Patent grant
GR01 Patent grant