CN110928835A - 基于海量存储的新型文件存储系统和方法 - Google Patents
基于海量存储的新型文件存储系统和方法 Download PDFInfo
- Publication number
- CN110928835A CN110928835A CN201910970109.0A CN201910970109A CN110928835A CN 110928835 A CN110928835 A CN 110928835A CN 201910970109 A CN201910970109 A CN 201910970109A CN 110928835 A CN110928835 A CN 110928835A
- Authority
- CN
- China
- Prior art keywords
- file
- storage
- store
- files
- node
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 47
- 230000007246 mechanism Effects 0.000 claims abstract description 11
- 230000008859 change Effects 0.000 claims abstract description 4
- 230000002776 aggregation Effects 0.000 claims description 31
- 238000004220 aggregation Methods 0.000 claims description 31
- 230000008569 process Effects 0.000 claims description 23
- 238000012217 deletion Methods 0.000 claims description 13
- 230000037430 deletion Effects 0.000 claims description 13
- 238000007906 compression Methods 0.000 claims description 9
- 238000013507 mapping Methods 0.000 claims description 8
- 238000004806 packaging method and process Methods 0.000 claims description 6
- 230000006835 compression Effects 0.000 claims description 4
- 230000003993 interaction Effects 0.000 abstract description 2
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 238000000638 solvent extraction Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
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/11—File system administration, e.g. details of archiving or snapshots
-
- 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
- G06F16/134—Distributed indices
-
- 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/14—Details of searching files based on file metadata
Abstract
一种基于海量存储的新型文件存储系统和方法,包含master组件和store节点,所述store节点存储在所述master组件中;master组件负责管理集群的元数据,包括集群中存在的store节点以及每个store节点的状态信息,store节点负责存储具体的数据;store节点周期性的向master组件汇报自身的状态信息,而master组件则实时的向其他store节点通知某个store节点的状态变更信息,确保所有的master组件和store节点都有统一的集群元数据信息,解决了海量小文件访问效率低下的问题,同时提供了一种良好的用户交互方式,对于海量小文件和大文件共存的场景,也提出了一种高效的存储机制。
Description
技术领域
本发明涉及存储领域,具体涉及一种基于海量存储的新型文件存储系统和方法。
背景技术
现有的大部分存储系统都是将用户文件直接存储在后端文件系统中,这样对于海量小文件会产生大量的inode等元数据,后续的读操作访问元数据需要额外消耗大量的磁盘io,导致性能低下;典型的如ceph、hdfs等。
针对上述问题,也有一些知名的存储系统提出了一些解决方案,比如Haystack,采用了小文件合并的方式来解决海量小文件带来的海量元数据问题。但是这类系统也存在一些问题。第一,小文件合并存储后,如何确定其位置信息,用户后续访问时应该从哪里读取?为了解决这个问题,这类系统都会在小文件存储后返回一个特定的文件名,文件名中包含了位置信息,但是这样又需要使用者额外的记住这些信息,造成使用不便;第二,这类系统假设所有的文件都是小文件,全部采用合并存储的方式,但是实际使用过程中,也有可能存在少量大文件的情形。由于合并存储导致删除和更新不方便,容易导致存储空间浪费。如果将大文件也采用合并存储的方式,显然加剧了这个问题;
发明内容
本发明针对现有技术的不足,提出种海量存储的新型文件存储系统和方法,其中,一种基于海量存储的新型文件存储系统,具体技术方案如下:
一种基于海量存储的新型文件存储系统,其特征在于:包含master组件和store节点,所述store节点存储在所述master组件中;
master组件负责管理集群的元数据,包括集群中存在的store节点以及每个store节点的状态信息,store节点负责存储具体的数据;
store节点周期性的向master组件汇报自身的状态信息,而master组件则实时的向其他store节点通知某个store节点的状态变更信息,确保所有的master组件和store节点都有统一的集群元数据信息;
每个store存储节点按照存储空间划分策略划分为多个bucket,具体为,由用户为集群设定一个bucket大小参数,一个store节点上的bucket数量=节点总容量/bucket大小。比如用户设定的bucket大小为100G,如果节点空间为10T,则该节点的bucket数量=10T/100G=100;
其他划分策略包括:用户可以直接设置某个store节点的bucket数量。如果用户设置了当前store节点的bucket数量,则当前store节点最终的bucket数量即为该参数设定的值;如果用户未对当前store节点设置bucket数量,则该store节点最终的bucket数量根据前述的按照存储空间划分的策略计算而来;
每个bucket可以直接对应为当前节点的一个目录,但也可以包含其他映射方式,数据实际存储到对应的bucket中;所述划分策略包含但不仅限于存储空间;假设按存储空间来划分,每1T存储空间对应一个bucket,那么一个具有10T存储空间的store节点将会被划分为10个bucket;
设定文件存储机制、划分文件内存索引,该文件存储机制为,设置判定文件大小的阈值,设定参考值size1,大于等于size1的文件为大文件,小于size1的文件为小文件;
大文件和小文件均存储在其bucket中,
对于小文件,在每个bucket下设置有一个聚合文件,所有小文件都合并存储到聚合文件里面;
对于大文件,单独存放在bucket下独立的文件中;
其中,包括内存索引流程,该内存索引为:
S21:针对每个bucket下的小文件,在内存中为其建立一个索引,索引内容为文件名到文件系统元数据的映射;
S22:每次store重启时,根据聚合文件中的信息重建内存索引。
进一步的,包括文件上传流程,该文件上传流程为:
S31:用户请求上传文件时,找到文件的存储位置,假设为bucket1,并将请求发送给对应的store节点;
S32:将上传文件的大小与参考值size1进行比较,如果上传文件大于参考值size1,上传文件为大文件,进入步骤S3,否则,上传文件为小文件,进入步骤S4;
S33:直接在bucket1下存储为同名文件;
S34:采用合并存储的方式,对接收到的小文件内容按照自定义的格式进行封装;
封装信息包括其原始内容、长度、状态、文件名,这里将封装后的内容叫做needle,然后将needle整体追加到相应的聚合文件中,同时在内存中按照内存索引流程为其新增索引。
进一步的,包括删除文件流程,该删除文件流程为:
S41:找到需要删除文件的位置并将删除请求发给相应store节点;
S42:store节点首先在其所在的bucket的内存索引中寻找对应的文件,判断是否有需要删除文件的内存索引,如果有,则判断为小文件,进入步骤S3,否则,判断为大文件,进入步骤S4;
S43:,对小文件进行删除,操作为将内存索引映射和聚合文件中相应的状态标志设置为已删除,该删除为软删除机制,此刻不会删除needle的磁盘数据;
S44:直接删除对应的大文件。
进一步的,包括读文件工作流程,读文件的工作流程为:
S51:store节点接收到读请求,利用内存中索引快速的查找相关的元数据,判断文件是否找到,如果在内存索引中找到,且文件没有被删除,则进入步骤S2,否则,进入步骤S3;
S52:store节点则在聚合文件中查询到相应的偏移量,从磁盘上读取数据;
S53:考虑读取的文件为大文件,尝试读取对应的大文件,判断是否找到大文件,如果是,则进入步骤S4,否则,进入步骤S5;
S54:并将内容返回给用户;
S55:如果本地大文件也没有找到,则说明用户请求了一个不存在的文件,返回错误信息。
进一步的包括更新文件流程,更新文件的流程为:
S61:定位文件位置并将删除请求发给相应store节点,store机器接收到更新请求;
S62:利用内存中索引快速的查找相关的元数据,判断在内存索引中是否找到文件,如果找到文件,则进入步骤S3,否则,进入步骤S4;
S63:判断需要更新的文件为小文件,通过添加一个新needle,将其追加到相同的聚合文件末尾,追加完成后,将以前小文件对应的needle设置为删除状态,同时将内存索引中的文件元数据更新;
S64:如果内存索引中未找到对应的文件,则考虑为大文件,此时可以直接对本地大文件进行更新。
进一步的包括压缩流程,该压缩流程为:
S71:逐个复制needle到一个新的聚合文件,并跳过任何重复项、已删除项。
S72:在压缩时如果接收到删除操作,两个聚合文件都需处理,一旦复制过程执行到原聚合文件末尾,所有对此聚合文件的修改操作将被阻塞,新聚合文件和新内存索引将对前任执行原子替换,随后恢复正常工作。
本发明的有益效果为:本发明提出了一种高性能的海量小文件存储方案,解决了海量小文件访问效率低下的问题,同时提供了一种良好的用户交互方式,对于海量小文件和大文件共存的场景,也提出了一种高效的存储机制。
附图说明
图1为本发明的结构图;
图2为聚合文件结构示意图。
具体实施方式
下面结合附图对本发明的较佳实施例进行详细阐述,以使本发明的优点和特征能更易于被本领域技术人员理解,从而对本发明的保护范围做出更为清楚明确的界定。
如图1所示,一种基于海量存储的新型文件存储系统的具体实施方式如下:
一种基于海量存储的新型文件存储系统,包含master组件和store节点,所述store节点存储在所述master组件中;master组件负责管理集群的元数据,包括集群中存在的store节点以及每个store节点的状态信息,store节点负责存储具体的数据;
store节点周期性的向master组件汇报自身的状态信息,而master组件则实时的向其他store节点通知某个store节点的状态变更信息,确保所有的master组件和store节点都有统一的集群元数据信息;
每个store存储节点按照特定的策略划分为多个bucket,每个bucket可以直接对应为当前节点的一个目录,但也可以包含其他映射方式,所述划分策略包含但不仅限于存储空间;
按照存储空间划分的策略:由用户为集群设定一个bucket大小参数,一个store节点上的bucket数量=节点总容量/bucket大小。比如用户设定的bucket大小为100G,如果节点空间为10T,则该节点的bucket数量=10T/100G=100
其他划分策略包括:用户可以直接设置某个store节点的bucket数量,如果用户设置了当前store节点的bucket数量,则当前store节点最终的bucket数量即为该参数设定的值;如果用户未对当前store节点设置bucket数量,则该store节点最终的bucket数量根据前述的按照存储空间划分的策略计算而来假设按存储空间来划分,每1T存储空间对应一个bucket,那么一个具有10T存储空间的store节点将会被划分为10个bucket。
设定文件存储机制、划分文件内存索引,该文件存储机制为,设置判定文件大小的阈值,设定参考值size1,大于等于size1的文件为大文件,小于size1的文件为小文件;
大文件和小文件均存储在其bucket中,对于小文件,在每个bucket下设置有一个聚合文件,所有小文件都合并存储到聚合文件里面;
对于大文件,单独存放在bucket下独立的文件中。
一种用于高性能海量文件存储系统的工作方法具体实施例为:
一种用于高性能海量文件存储系统的工作方法,包括数据分布算法、内存索引流程、文件上传流程、删除文件流程、读文件工作流程、更新文件流程和压缩流程。
其中,本发明采用的数据算法为使用一致性哈希算法来定位文件位置,首先将每个bucket根据特定的hash算法hash为一个特定长度的值,比如bucket_key=hash(bucketname,hostname…),这些hash参数可以包含自定义的bucket名字、主机名或主机ip等;
然后将这些bucket_key分布在整个哈希环上;当用户请求一个文件时,对文件名,也可以增加用户名等其他组合参数,后面统称为文件名,做一次类似的hash并得到一个key值file_key,在得到file_key后,找到比file_key大且与file_key最接近的一个bucket_key,该bucket_key指向的bucket即为文件存储位置。
其中,该内存索引流程为,
S21:针对每个bucket下的小文件,在内存中为其建立一个索引,索引内容为文件名到文件系统元数据的映射;
S22:每次store重启时,根据聚合文件中的信息重建内存索引。
包括文件上传流程,该文件上传流程为,
S31:用户请求上传文件时,找到文件的存储位置,假设为bucket1,并将请求发送给对应的store节点;
S32:将上传文件的大小与参考值size1进行比较,如果上传文件大于参考值size1,上传文件为大文件,进入步骤S3,否则,上传文件为小文件,进入步骤S4;
S33:直接在bucket1下存储为同名文件;
S34:采用合并存储的方式,对接收到的小文件内容按照自定义的格式进行封装;
封装信息包括其原始内容、长度、状态、文件名,这里将封装后的内容叫做needle,然后将needle整体追加到相应的聚合文件中,同时在内存中按照内存索引流程为其新增索引。
删除文件流程为:
S41:找到需要删除文件的位置并将删除请求发给相应store节点;
S42:store节点首先在其所在的bucket的内存索引中寻找对应的文件,判断是否有需要删除文件的内存索引,如果有,则判断为小文件,进入步骤S3,否则,判断为大文件,进入步骤S4;
S43:,对小文件进行删除,操作为将内存索引映射和聚合文件中相应的状态标志设置为已删除,该删除为软删除机制,此刻不会删除needle的磁盘数据;
S44:直接删除对应的大文件。
读文件的工作流程为:
S51:store节点接收到读请求,利用内存中索引快速的查找相关的元数据,判断文件是否找到,如果在内存索引中找到,且文件没有被删除,则进入步骤S2,否则,进入步骤S3;
S52:store节点则在聚合文件中查询到相应的偏移量,从磁盘上读取数据;
S53:考虑读取的文件为大文件,尝试读取对应的大文件,判断是否找到大文件,如果是,则进入步骤S4,否则,进入步骤S5;
S54:并将内容返回给用户;
S55:如果本地大文件也没有找到,则说明用户请求了一个不存在的文件,返回错误信息。
更新文件的流程为:
S61:定位文件位置并将删除请求发给相应store节点,store机器接收到更新请求;
S62:利用内存中索引快速的查找相关的元数据,判断在内存索引中是否找到文件,如果找到文件,则进入步骤S3,否则,进入步骤S4;
S63:判断需要更新的文件为小文件,通过添加一个新needle,将其追加到相同的聚合文件末尾,追加完成后,将以前小文件对应的needle设置为删除状态,同时将内存索引中的文件元数据更新;
S64:如果内存索引中未找到对应的文件,则考虑为大文件,此时可以直接对本地大文件进行更新。
压缩流程为:
S71:逐个复制needle到一个新的聚合文件,并跳过任何重复项、已删除项。
S72:在压缩时如果接收到删除操作,两个聚合文件都需处理,一旦复制过程执行到原聚合文件末尾,所有对此聚合文件的修改操作将被阻塞,新聚合文件和新内存索引将对前任执行原子替换,该原子替换的流程为:阻塞对当前聚合文件的所有修改操作,删除旧的聚合文件,将新的聚合文件重新命名为旧的聚合文件名;恢复对当前聚合文件的所有修改操作;随后恢复正常工作。
Claims (7)
1.一种基于海量存储的新型文件存储系统,其特征在于:包含master组件和store节点,所述store节点存储在所述master组件中;
master组件负责管理集群的元数据,包括集群中存在的store节点以及每个store节点的状态信息,store节点负责存储具体的数据;
store节点周期性的向master组件汇报自身的状态信息,而master组件则实时的向其他store节点通知某个store节点的状态变更信息,确保所有的master组件和store节点都有统一的集群元数据信息;
每个store存储节划分为多个bucket,每个bucket直接对应为当前节点的一个目录,数据实际存储到对应的bucket中;
设定文件存储机制,该文件存储机制为,设置判定文件大小的阈值,设定参考值size1,大于等于size1的文件为大文件,小于size1的文件为小文件;
大文件和小文件均存储在其bucket中,
对于小文件,在每个bucket下设置有一个聚合文件,所有小文件都合并存储到聚合文件里面;
对于大文件,单独存放在bucket下独立的文件中。
2.一种用于权利要求1所述高性能海量文件存储系统的工作方法,其特征在于:
包括内存索引流程,该内存索引为:
S21:针对每个bucket下的小文件,在内存中为其建立一个索引,索引内容为文件名到文件系统元数据的映射;
S22:每次store重启时,根据聚合文件中的信息重建内存索引。
3.根据权利要求2所述一种基于海量存储的新型文件存储系统工作方法,其特征在于:包括文件上传流程,该文件上传流程为:
S31:用户请求上传文件时,找到文件的存储位置,假设为bucket1,并将请求发送给对应的store节点;
S32:将上传文件的大小与参考值size1进行比较,如果上传文件大于参考值size1,上传文件为大文件,进入步骤S3,否则,上传文件为小文件,进入步骤S4;
S33:直接在bucket1下存储为同名文件;
S34:采用合并存储的方式,对接收到的小文件内容按照自定义的格式进行封装;
封装信息包括其原始内容、长度、状态、文件名,这里将封装后的内容叫做needle,然后将needle整体追加到相应的聚合文件中,同时在内存中按照内存索引流程为其新增索引。
4.根据权利要求2所述一种基于海量存储的新型文件存储系统工作方法,其特征在于:包括删除文件流程,该删除文件流程为:
S41:找到需要删除文件的位置并将删除请求发给相应store节点;
S42:store节点首先在其所在的bucket的内存索引中寻找对应的文件,判断是否有需要删除文件的内存索引,如果有,则判断为小文件,进入步骤S3,否则,判断为大文件,进入步骤S4;
S43:对小文件进行删除,操作为将内存索引映射和聚合文件中相应的状态标志设置为已删除,该删除为软删除机制,此刻不会删除needle的磁盘数据;
S44:直接删除对应的大文件。
5.根据权利要求2所述一种基于海量存储的新型文件存储系统工作方法,其特征在于:
包括读文件工作流程,读文件的工作流程为:
S51:store节点接收到读请求,利用内存中索引快速的查找相关的元数据,判断文件是否找到,如果在内存索引中找到,且文件没有被删除,则进入步骤S2,否则,进入步骤S3;
S52:store节点则在聚合文件中查询到相应的偏移量,从磁盘上读取数据;
S53:考虑为大文件,尝试读取对应的大文件,判断是否找到大文件,如果是,则进入步骤S4,否则,进入步骤S5;
S54:并将内容返回给用户;
S55:如果本地大文件也没有找到,则说明用户请求了一个不存在的文件,返回错误信息。
6.根据权利要求2所述一种基于海量存储的新型文件存储系统工作方法,其特征在于:
包括更新文件流程,更新文件的流程为:
S61:定位文件位置并将删除请求发给相应store节点,store机器接收到更新请求;
S62:利用内存中索引快速的查找相关的元数据,判断在内存索引中是否找到文件,如果找到文件,则进入步骤S3,否则,进入步骤S4;
S63:判断需要更新的文件为小文件,通过添加一个新needle,将其追加到相同的聚合文件末尾,追加完成后,将以前小文件对应的needle设置为删除状态,同时将内存索引中的文件元数据更新;
S64:如果内存索引中未找到对应的文件,则考虑为大文件,此时可以直接对本地大文件进行更新。
7.根据权利要求2所述一种基于海量存储的新型文件存储系统工作方法,其特征在于:包括压缩流程,该压缩流程为:
S71:逐个复制needle到一个新的聚合文件,并跳过任何重复项和已删除项;
S72:在压缩时如果接收到删除操作,两个聚合文件都需处理,一旦复制过程执行到原聚合文件末尾,所有对此聚合文件的修改操作将被阻塞,新聚合文件和新内存索引将对前任执行原子替换,随后恢复正常工作。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910970109.0A CN110928835A (zh) | 2019-10-12 | 2019-10-12 | 基于海量存储的新型文件存储系统和方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910970109.0A CN110928835A (zh) | 2019-10-12 | 2019-10-12 | 基于海量存储的新型文件存储系统和方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN110928835A true CN110928835A (zh) | 2020-03-27 |
Family
ID=69848912
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910970109.0A Pending CN110928835A (zh) | 2019-10-12 | 2019-10-12 | 基于海量存储的新型文件存储系统和方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110928835A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112181309A (zh) * | 2020-10-14 | 2021-01-05 | 上海德拓信息技术股份有限公司 | 一种海量对象存储的在线扩容方法 |
CN115981570A (zh) * | 2023-01-10 | 2023-04-18 | 创云融达信息技术(天津)股份有限公司 | 一种基于kv数据库的分布式对象存储方法和系统 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106776967A (zh) * | 2016-12-05 | 2017-05-31 | 哈尔滨工业大学(威海) | 基于时序聚合算法的海量小文件实时存储方法及装置 |
WO2017096939A1 (zh) * | 2015-12-10 | 2017-06-15 | 深圳市华讯方舟软件技术有限公司 | 一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法 |
CN109063192A (zh) * | 2018-08-29 | 2018-12-21 | 广州洪荒智能科技有限公司 | 一种高性能海量文件存储系统工作方法 |
-
2019
- 2019-10-12 CN CN201910970109.0A patent/CN110928835A/zh active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2017096939A1 (zh) * | 2015-12-10 | 2017-06-15 | 深圳市华讯方舟软件技术有限公司 | 一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法 |
CN106776967A (zh) * | 2016-12-05 | 2017-05-31 | 哈尔滨工业大学(威海) | 基于时序聚合算法的海量小文件实时存储方法及装置 |
CN109063192A (zh) * | 2018-08-29 | 2018-12-21 | 广州洪荒智能科技有限公司 | 一种高性能海量文件存储系统工作方法 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112181309A (zh) * | 2020-10-14 | 2021-01-05 | 上海德拓信息技术股份有限公司 | 一种海量对象存储的在线扩容方法 |
CN115981570A (zh) * | 2023-01-10 | 2023-04-18 | 创云融达信息技术(天津)股份有限公司 | 一种基于kv数据库的分布式对象存储方法和系统 |
CN115981570B (zh) * | 2023-01-10 | 2023-12-29 | 创云融达信息技术(天津)股份有限公司 | 一种基于kv数据库的分布式对象存储方法和系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109063192B (zh) | 一种高性能海量文件存储系统工作方法 | |
US7725437B2 (en) | Providing an index for a data store | |
US7856437B2 (en) | Storing nodes representing respective chunks of files in a data store | |
US8868926B2 (en) | Cryptographic hash database | |
US20220215002A1 (en) | Image File Management Method, Apparatus, and System, Computer Device, and Storage Medium | |
CN110647497A (zh) | 一种基于hdfs的高性能文件存储与管理系统 | |
CN109522283B (zh) | 一种重复数据删除方法及系统 | |
CN103595797B (zh) | 一种分布式存储系统中的缓存方法 | |
US10997153B2 (en) | Transaction encoding and transaction persistence according to type of persistent storage | |
US20200034340A1 (en) | Flash file system and data management method therof | |
CN107817946B (zh) | 用于混合存储设备读写数据的方法以及装置 | |
US10678817B2 (en) | Systems and methods of scalable distributed databases | |
CN112307263B (zh) | 一种文件存储方法、装置、设备及介质 | |
CN110928835A (zh) | 基于海量存储的新型文件存储系统和方法 | |
JP2021092950A (ja) | データ処理装置およびデータ処理プログラム | |
CN113704217A (zh) | 一种分布式持久性内存文件系统中元数据及数据组织架构方法 | |
US8612717B2 (en) | Storage system | |
CN107798063A (zh) | 快照处理方法和快照处理装置 | |
CN104516945A (zh) | 一种基于关系数据库的hdfs元数据存储方法 | |
CN113867627A (zh) | 一种存储系统性能优化方法及系统 | |
US11860840B2 (en) | Update of deduplication fingerprint index in a cache memory | |
CN116955278A (zh) | 分布式文件系统快照的聚合访问方法、装置及计算机设备 | |
CN116204130A (zh) | 一种键值存储系统和键值存储系统的管理方法 | |
US20060090042A1 (en) | Storage system | |
CN115061630A (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 | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200327 |