CN103544156B - 文件存储方法及装置 - Google Patents

文件存储方法及装置 Download PDF

Info

Publication number
CN103544156B
CN103544156B CN201210238427.6A CN201210238427A CN103544156B CN 103544156 B CN103544156 B CN 103544156B CN 201210238427 A CN201210238427 A CN 201210238427A CN 103544156 B CN103544156 B CN 103544156B
Authority
CN
China
Prior art keywords
folder
key
file
data
sub
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
Application number
CN201210238427.6A
Other languages
English (en)
Other versions
CN103544156A (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.)
Tencent Technology Shenzhen Co Ltd
Tencent Cloud Computing Beijing Co Ltd
Original Assignee
Tencent Technology Shenzhen 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 Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201210238427.6A priority Critical patent/CN103544156B/zh
Priority to PCT/CN2013/079084 priority patent/WO2014008856A1/en
Priority to US13/963,434 priority patent/US9146930B2/en
Publication of CN103544156A publication Critical patent/CN103544156A/zh
Priority to PH12014501762A priority patent/PH12014501762A1/en
Application granted granted Critical
Publication of CN103544156B publication Critical patent/CN103544156B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/17—Details of further file system functions
    • G06F16/172—Caching, prefetching or hoarding of files
    • 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/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G06F16/162—Delete operations
    • 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
    • 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/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开一种文件存储方法及装置，其方法包括：记录父文件夹的元信息，保存在主key中；当父文件夹下包括至少一子文件夹列表和/或文件列表时，将父文件夹下的至少一子文件夹列表和/或文件列表的内容保存至基于主key的副key中。本发明实现了数据的无限扩展，且在数据累积变大的情况下，可避免来自底层数据存储的瓶颈，达到无限制文件夹系统目录树存储的目的。相比现有技术，本发明将大数据分拆成多个key来保存，使得数据均匀，提高了系统数据库的数据存储稳定性，更利于数据的扩容以及系统业务运营。

Description

文件存储方法及装置
技术领域
本发明涉及计算机数据存储技术领域，尤其涉及一种文件存储方法及装置。
背景技术
传统的PC系统通常采用目录树文件夹+文件的存储模式来对文件进行存储，其数据存储结构如图1所示。其中，最顶层的文件夹称为根目录，根目录下的文件夹列表称为子目录。每个文件夹都可以保存子文件夹和文件列表，各文件夹、子文件夹和文件列表构成一种递归的数据结构。
在上述树形结构存储模式中，采用key-value数据库来保存数据，即，每个文件夹作为一个key保存，value则作为当前文件夹的子目录列表和文件名。其存储记录关系如图2所示。在图2中，椭圆圈内表示以其左边的folderkey保存一条记录的value。
现有的这种树形结构中，在每次读取目录树时，需要逐层拉取数据。即首先必须拉取根目录，然后再拉取下一层的目录，不能越级拉取目录信息。而且，对于一般的key-value数据库来说，每层文件夹和文件列表的数据不能太大，数据过大则会影响系统性能。
因此，当某个用户的文件夹或者文件增多时，则可能遇到来自底层的数据访问性能瓶颈，尤其是在现有的网络文件系统中，比如QQ相册、网盘，云存储等应用，采用现有的数据存储结构，则会遭遇存储与访问上的性能瓶颈，因为大数据将导致存储和访问上的困难，当数据大到系统支撑的阀值时，则需要采用更为复杂的系统来解决大数据问题；此外，现有的数据存储结构中，数据的分布无法控制，对于key-value数据库，则是依据key来路由，因此，不同的Folderkey需要写到不同的网络存储块，而网络存储块采用固定的规则分配，无法考虑到数据存储的扩容以及特定的需求等问题。
发明内容
本发明的主要目的在于提供一种文件存储方法及装置，旨在提高数据存储稳定性及可扩展性，达到无限制文件夹系统目录树的存储目的。
为了达到上述目的，本发明提出一种文件存储方法，包括以下步骤：
记录父文件夹的元信息，保存在主key中；
当所述父文件夹下包括至少一子文件夹列表和/或文件列表时，将所述父文件夹下的所述至少一子文件夹列表和/或文件列表的内容保存至基于所述主key的副key中。
优选地，所述副key为多个，每个所述副key分别独立保存相应的子文件夹列表和/或文件列表的内容。
优选地，该方法还包括：
在相应的副key中添加、删除或重命名所述父文件夹下的子文件夹列表和/或文件列表。
优选地，所述在相应的副key中添加、删除或重命名所述父文件夹下的子文件夹列表和/或文件列表的步骤之后还包括：
更新所述主key中的元信息。
优选地，所述记录父目录下文件夹的元信息，保存在主key中的步骤之前还包括：
基于所述主key生成所述副key。
优选地，所述主key保存的元信息至少包括：当前最大文件标识、当前数据所在set、文件删除信息和/或文件夹及文件的写入时间。
本发明还提出一种文件存储装置，包括：
主存储模块，用于记录父文件夹的元信息，保存在主key中；
副存储模块，用于当所述父文件夹下包括至少一子文件夹列表和/或文件列表时，将所述父文件夹下的所述至少一子文件夹列表和/或文件列表的内容保存至基于所述主key的副key中。
优选地，所述副key为多个，每个所述副key分别独立保存相应的子文件夹列表和/或文件列表的内容。
优选地，该装置还包括：
处理模块，用于在相应的副key中添加、删除或重命名所述父文件夹下的子文件夹列表和/或文件列表；
更新模块，用于更新所述主key中的元信息。
优选地，该装置还包括：
生成模块，用于基于所述主key生成所述副key。
本发明提出的一种文件存储方法及装置，改变现有的目录树数据的存储模式，采用父文件夹以主key写一条元信息，其文件夹列表和文件列表以多个副key的方式写入数据，从而实现了数据的无限扩展，且在数据累积变大的情况下，可避免来自底层数据存储的瓶颈，达到无限制文件夹系统目录树存储的目的。相比现有技术，本发明将大数据分拆成多个key来保存，使得数据均匀，提高了系统数据库的数据存储稳定性，更利于数据的扩容以及系统业务运营。
附图说明
图1是现有技术中目录树式的数据存储结构示意图；
图2是图1所示的数据存储结构中的存储记录关系示意图；
图3是本发明文件存储方法第一实施例的流程示意图；
图4是本发明中父文件夹的主key保存的元信息结构示意图；
图5是本发明中以主key以及其副key构成的数据存储结构示意图；
图6是本发明文件存储方法第二实施例的流程示意图；
图7是本发明文件存储方法第三实施例的流程示意图；
图8是本发明文件存储装置第一实施例的结构示意图；
图9是本发明文件存储装置第二实施例的结构示意图；
图10是本发明文件存储装置第三实施例的结构示意图。
为了使本发明的技术方案更加清楚、明了，下面将结合附图作进一步详述。
具体实施方式
本发明实施例解决方案主要是：不使用唯一的一个key保存某个文件夹的文件夹列表和文件列表，而是采用以主key保存父文件夹的元信息，以多个副key的形式保存父文件夹下的多个子文件夹列表和文件列表，以实现数据的无限扩展，避免数据累积变大时遭遇来自底层存储的瓶颈。
如图3所示，本发明第一实施例提出一种文件存储方法，包括：
步骤S101，记录父文件夹的元信息，保存在主key中；
步骤S102，当所述父文件夹下包括至少一子文件夹列表和/或文件列表时，将所述父文件夹下的所述至少一子文件夹列表和/或文件列表的内容保存至基于所述主key的副key中。
本实施例针对现有的目录树数据存储结构，将原来的某个父目录的数据(包括文件夹列表和文件列表)采用一个parentkey保存一条数据的方式，改变为以父目录的parentkey作为主key写入一条元信息，该父目录的文件夹列表和文件夹列表则采用多个副key的方式，写入多条数据，达到无限制文件夹系统目录树存储的目的。
上述父目录可以为目录树结构中的根目录。
本实施例设定父目录所在文件夹为父文件夹，父目录下的各文件夹列表和文件列表为子文件夹列表和文件列表，其中，每个父文件夹作为一条主数据，具有独立性，每个父文件夹有一个主key对应，其子文件夹和文件列表保存在基于上述主key的副key中。
所述父文件夹下可以有数据，也可以没有数据，即父文件夹下可以包括至少一子文件夹列表和/或文件列表；也可以为空文件夹，没有文件夹列表和文件列表。当父文件夹为空文件夹时，则仅将父文件夹的元信息写入主key中。
如图4所示，图4为本实施例中父文件夹的主key保存的元信息结构示意图，该元信息包括：Key、Parentkey、FolderNum、MaxFileID、Setid、Delinfo、TimeStamp1以及TimeStamp2，其中：
Key即为父文件夹的主key，该主key为整个文件系统的核心数据结构，用于标识父文件夹的关键字；在整个系统中，主key是唯一的，其所有的副key均与主key关联，而各副key之间又相互独立，因此，整个系统的主key和副key不会重复。
Parentkey为当前父文件夹的上一级的父文件夹的主key；FolderNum表示目前总的子文件夹的数量，用于记录每个父文件夹的子文件夹的个数，这样当子文件夹数量增多时，用于处理子文件夹列表存储的逻辑，如果子文件夹列表多到无法在一档数据中存储时，则可以根据次FolderNum计算其所在副key，即对文件夹列表数据也进行分档，达到无限制存储子文件夹内容的目的。
当增加子文件夹时，FolderNum+1，当删除子文件夹时，FolderNum的值不改变，其作用是根据一定的逻辑，计算子文件夹数据由哪些副key来存储，由此，再根据这些副key拉取子文件夹列表。
MaxFileID用于标识当前的最大的文件id(标识)；
Setid表示当前数据所在的set。根据Setid将子文件夹列表和文件的数据写在不同的set。在网络文件系统中，通常由很多机器组成一个集群，这样的一个集群可以称为一个set。在大型的存储架构中，一个set通常是一个管理单元，包括扩容、迁移、上架以及下架等。简单的说，一个set是一组机器(通常为10-30台，或者更多)，在这组机器上部署了一个存储系统完成工作所必须的模块，比如，接入模块、逻辑处理模块、数据库模块等。因此，一个set可以独立运营，是一个逻辑完备的存储系统。
DelInfo用于保存删除的文件信息，文件夹删除则不需要记录删除信息；
TimeStamp1，TimeStamp2表示最近所写子文件夹和文件的时间。
上述副key可以设置为多个，每个所述副key分别独立保存相应的子文件夹列表和/或文件列表的内容。该副key基于主key而生成，比如可以采用主key+数字的方式生成副key，当然也可以采用其他方式生成副key。
本实施例以主key以及其副key构成的数据存储结构如图5所示。
其中，主key记录并保存父文件夹的元信息，主key下包含多个副key，用于分别记录父文件夹下各个子文件夹列表和文件列表；每个副key可以保存多个子文件夹列表和/或文件列表。
多个副key可以按照0-N档的顺序依次编号，若文件夹列表太大，则可以从-1档开始存储，此时元信息中所述的Foldernum在拉取文件夹列表时则起着很重要的作用。如前所述，FolderNum表示目前总的子文件夹的数量，当子文件夹数量增多时，用于处理子文件夹列表存储的逻辑，如果子文件夹列表多到无法在一档数据中存储时，则可以根据次FolderNum计算其所在副key；当增加子文件夹时，FolderNum+1，当删除子文件夹时，FolderNum的值不改变，其作用是根据一定的逻辑，计算子文件夹数据由哪些副key来存储，由此，再根据这些副key拉取子文件夹列表。其中，每个档的数据条数一定，在系统初始化时配置，后续不再改变。
由上述数据存储结构可以看出，由于每个父文件夹具有一个主key对应，其子文件夹列表和文件列表通过副key保存，每个文件夹和文件数据存储相对独立，由此，使得文件夹具有递归性，数据存储可以无限扩展，且在数据累积变大的情况下，可避免来自底层数据存储的瓶颈，达到无限制文件夹系统目录树存储的目的。尤其是针对网络文件系统中，比如若将上述数据存储方案应用到QQ空间相册的图片存储，用户创建了很多相册，相册中有很多相片。这里相册对应文件夹，相片则对应文件。采用上述无限制的文件目录存储方案，则可以使存储用户存储上万张图片和多个相册的需求得到了满足。因为相对于用户的数据增长来说，不会遇到数据存储和访问上的瓶颈。此外，本实施例方案还可以应用其他方面，比如网盘，云存储等。
此外，本实施例改进了数据的扩展属性，能够平衡数据的大小，将大数据分拆成多个key来保存，使得数据分布均匀，数据库保存数据的性能更好，进而提高了系统数据服务的稳定性；由于数据存储结构得到扩充，同时引进了setid概念，从而改进了数据的扩容性，更利于系统长期稳定运营。当然，本实施例上述数据存储结构，为数据的读写操作提供了更大的方便。
需要说明的是，作为本实施例的扩展，对于每一个子文件夹之下还可以设置多个子文件夹列表和/或文件列表，并对应设置相应的副key来进行数据保存。
如图6所示，本发明第二实施例提出一种文件存储方法，在上述第一实施例的基础上，在上述步骤S102之后还包括：
步骤S103，在相应的副key中添加、删除或重命名所述父文件夹下的子文件夹列表和/或文件列表。
步骤S104，更新所述主key中的元信息。
本实施例与上述第一实施例的区别在于，本实施例还包括对后续文件夹内容的添加、删除或重命名等操作。
具体地，在后续文件处理过程中，若有需要添加、删除或重命名文件夹或文件，则采用以下操作方式：
对于文件夹的处理
若需要新建一子文件夹，则在父文件夹中相应的副key中保存该子文件夹的内容，同时更新父文件夹主key的元信息；或者根据实际需要，在父文件夹中添加一副key，在该副key中保存该子文件夹的内容，同时更新父文件夹主key的元信息。
若需要删除某一子文件夹keyfolder，则修改父文件夹的相关信息，删除该子文件夹的所有信息，同时更新父文件夹主key的元信息。
若需要重命名某子文件夹，则将原来的子文件夹的所有内容读出，被采用新的子文件夹来写一份数据，以新的子文件夹的副key写入数据，并把原来的子文件夹的副key中保存的数据删除。
对于文件的处理：
若需要添加一个文件，则修改其父文件夹的属性，并且在父文件夹parentkey的副key中写一条数据，并保存文件名；同时更新父文件夹主key的元信息。
若需要删除文件，则直接删除其父文件夹parentkey的副key中的某个数据，并且修改该父文件夹的元信息。
若需要重命名文件，直接修改其父文件夹parentkey的副key中的某个数据，并且修改该父文件夹的元信息。
本实施例不仅实现了数据的无限扩展，在数据累积变大的情况下，可避免来自底层数据存储的瓶颈，达到无限制文件夹系统目录树存储的目的。而且将大数据分拆成多个key来保存，使得数据均匀，对数据的读写操作更加方便，提高了系统数据库的数据存储稳定性，更利于数据的扩容以及系统业务运营。
图7所示，本发明第三实施例提出一种文件存储方法，在上述第一实施例的基础上，在上述步骤S101记录父目录下文件夹的元信息，保存在主key中的步骤之前还包括：
步骤S100，基于所述主key生成所述副key。
本实施例与上述第一实施例的区别在于，本实施例还包括生成副key的过程。具体地，该副key采用主key+数字的方式生成，由此，使得副key与主key相关联，达到无限制文件夹系统目录树存储的目的，提高数据存储的可扩展性。
需要说明的是，上述第二实施例与第三实施例还可以组合实施。
如图8所示，本发明第一实施例提出一种文件存储装置，包括：主存储模块801以及副存储模块802，其中：
主存储模块801，用于记录父文件夹的元信息，保存在主key中；
副存储模块802，用于当所述父文件夹下包括至少一子文件夹列表和/或文件列表时，将所述父文件夹下的所述至少一子文件夹列表和/或文件列表的内容保存至基于所述主key的副key中。
本实施例针对现有的目录树数据存储结构，将原来的某个父目录的数据(包括文件夹列表和文件列表)采用一个parentkey保存一条数据的方式，改变为以父目录的parentkey作为主key写入一条元信息，该父目录的文件夹列表和文件夹列表则采用多个副key的方式，写入多条数据，达到无限制文件夹系统目录树存储的目的。
上述父目录可以为目录树结构中的根目录。
具体地，通过主存储模块801记录父文件夹的元信息并保存在主key中；通过副存储模块802将父文件夹下的子文件夹列表和文件列表的内容保存至基于主key的副key中。
本实施例设定父目录所在文件夹为父文件夹，父目录下的各文件夹列表和文件列表为子文件夹列表和文件列表，其中，每个父文件夹作为一条主数据，具有独立性，每个父文件夹有一个主key对应，其子文件夹和文件列表保存在基于上述主key的副key中。
所述父文件夹下可以有数据，也可以没有数据，即父文件夹下可以包括至少一子文件夹列表和/或文件列表；也可以为空文件夹，没有文件夹列表和文件列表。当父文件夹为空文件夹时，则仅将父文件夹的元信息写入主key中。
如图4所示，图4为本实施例中父文件夹的主key保存的元信息结构示意图，该元信息包括：Key、Parentkey、FolderNum、MaxFileID、Setid、Delinfo、TimeStamp1以及TimeStamp2，其中：
Key即为父文件夹的主key，该主key为整个文件系统的核心数据结构，用于标识父文件夹的关键字；在整个系统中，主key是唯一的，其所有的副key均与主key关联，而各副key之间又相互独立，因此，整个系统的主key和副key不会重复。
Parentkey为当前父文件夹的上一级的父文件夹的主key；FolderNum表示目前总的子文件夹的数量，用于记录每个父文件夹的子文件夹的个数，这样当子文件夹数量增多时，用于处理子文件夹列表存储的逻辑，如果子文件夹列表多到无法在一档数据中存储时，则可以根据次FolderNum计算其所在副key，即对文件夹列表数据也进行分档，达到无限制存储子文件夹内容的目的。
当增加子文件夹时，FolderNum+1，当删除子文件夹时，FolderNum的值不改变，其作用是根据一定的逻辑，计算子文件夹数据由哪些副key来存储，由此，再根据这些副key拉取子文件夹列表。
MaxFileID标识当前的最大的文件id(标识)；
Setid表示当前数据所在的set。根据Setid将子文件夹列表和文件的数据写在不同的set。在网络文件系统中，通常由很多机器组成一个集群，这样的一个集群可以称为一个set。在大型的存储架构中，一个set通常是一个管理单元，包括扩容、迁移、上架以及下架等。简单的说，一个set是一组机器(通常为10-30台，或者更多)，在这组机器上部署了一个存储系统完成工作所必须的模块，比如，接入模块、逻辑处理模块、数据库模块等。因此，一个set可以独立运营，是一个逻辑完备的存储系统。
DelInfo用于保存删除的文件信息，文件夹删除则不需要记录删除信息；
TimeStamp1，TimeStamp2表示最近所写子文件夹和文件的时间。
上述副key可以设置为多个，每个所述副key分别独立保存相应的子文件夹列表和/或文件列表的内容。该副key基于主key而生成，比如可以采用主key+数字的方式生成副key，当然也可以采用其他方式生成副key。
本实施例以主key以及其副key构成的数据存储结构如图5所示。
其中，主key记录并保存父文件夹的元信息，主key下包含多个副key，用于分别记录父文件夹下各个子文件夹列表和文件列表；每个副key可以保存多个子文件夹列表和/或文件列表。
多个副key可以按照0-N档的顺序依次编号，若文件夹列表太大，则可以从-1档开始存储。此时元信息中所述的Foldernum在拉取文件夹列表时则起着很重要的作用。如前所述，FolderNum表示目前总的子文件夹的数量，当子文件夹数量增多时，用于处理子文件夹列表存储的逻辑，如果子文件夹列表多到无法在一档数据中存储时，则可以根据次FolderNum计算其所在副key；当增加子文件夹时，FolderNum+1，当删除子文件夹时，FolderNum的值不改变，其作用是根据一定的逻辑，计算子文件夹数据由哪些副key来存储，由此，再根据这些副key拉取子文件夹列表。其中，每个档的数据条数一定，在系统初始化时配置，后续不再改变。
由上述数据存储结构可以看出，由于每个父文件夹具有一个主key对应，其子文件夹列表和文件列表通过副key保存，每个文件夹和文件数据存储相对独立，由此，使得文件夹具有递归性，数据存储可以无限扩展，且在数据累积变大的情况下，可避免来自底层数据存储的瓶颈，达到无限制文件夹系统目录树存储的目的。尤其是针对网络文件系统中，比如若将上述数据存储方案应用到QQ空间相册的图片存储，用户创建了很多相册，相册中有很多相片。这里相册对应文件夹，相片则对应文件。采用上述无限制的文件目录存储方案，则可以使存储用户存储上万张图片和多个相册的需求得到了满足。因为相对于用户的数据增长来说，不会遇到数据存储和访问上的瓶颈。此外，本实施例方案还可以应用其他方面，比如网盘，云存储等。
此外，本实施例改进了数据的扩展属性，能够平衡数据的大小，将大数据分拆成多个key来保存，使得数据分布均匀，数据库保存数据的性能更好，进而提高了系统数据服务的稳定性；由于数据存储结构得到扩充，同时引进了setid概念，从而改进了数据的扩容性，更利于系统长期稳定运营。当然，本实施例上述数据存储结构，为数据的读写操作提供了更大的方便。
如图9所示，本发明第二实施例提出一种文件存储装置，在上述第一实施例的基础上，还包括：
处理模块803，用于在相应的副key中添加、删除或重命名所述父文件夹下的子文件夹列表和/或文件列表；
更新模块804，用于更新所述主key中的元信息。
本实施例与上述第一实施例的区别在于，本实施例还包括对后续文件夹内容的添加、删除或重命名等操作。
具体地，在后续文件处理过程中，若有需要添加、删除或重命名文件夹或文件，则采用以下操作方式：
对于文件夹的处理
若需要新建一子文件夹，处理模块803则在父文件夹中相应的副key中保存该子文件夹的内容，同时更新父文件夹主key的元信息；或者根据实际需要，在父文件夹中添加一副key，在该副key中保存该子文件夹的内容，同时通过更新模块804更新父文件夹主key的元信息。
若需要删除某一子文件夹keyfolder，处理模块803则修改父文件夹的相关信息，删除该子文件夹的所有信息，同时通过更新模块804更新父文件夹主key的元信息。
若需要重命名某子文件夹，处理模块803则将原来的子文件夹的所有内容读出，被采用新的子文件夹来写一份数据，以新的子文件夹的副key写入数据，并把原来的子文件夹的副key中保存的数据删除。同时通过更新模块804更新父文件夹主key的元信息。
对于文件的处理：
若需要添加一个文件，处理模块803则修改其父文件夹的属性，并且在父文件夹parentkey的副key中写一条数据，并保存文件名；同时通过更新模块804更新父文件夹主key的元信息。
若需要删除文件，处理模块803则直接删除其父文件夹parentkey的副key中的某个数据，并通过更新模块804修改该父文件夹的元信息。
若需要重命名文件，则处理模块803直接修改其父文件夹parentkey的副key中的某个数据，并通过更新模块804修改该父文件夹的元信息。
本实施例不仅实现了数据的无限扩展，在数据累积变大的情况下，可避免来自底层数据存储的瓶颈，达到无限制文件夹系统目录树存储的目的。而且将大数据分拆成多个key来保存，使得数据均匀，对数据的读写操作更加方便，提高了系统数据库的数据存储稳定性，更利于数据的扩容以及系统业务运营。
如图10所示，本发明第三实施例提出一种文件存储装置，在上述第一实施例的基础上，还包括：
生成模块800，用于基于所述主key生成所述副key。
本实施例与上述第一实施例的区别在于，本实施例还包括生成副key的过程。具体地，生成模块800采用主key+数字的方式生成该副key，由此，使得副key与主key相关联，达到无限制文件夹系统目录树存储的目的，提高数据存储的可扩展性。
需要说明的是，上述第二实施例与第三实施例还可以组合实施。
本实施例文件存储方法及装置，改变现有的目录树数据的存储模式，采用父文件夹以主key写一条元信息，其文件夹列表和文件列表以多个副key的方式写入数据，从而实现了数据的无限扩展，且在数据累积变大的情况下，可避免来自底层数据存储的瓶颈，达到无限制文件夹系统目录树存储的目的。相比现有技术，本发明将大数据分拆成多个key来保存，使得数据均匀，提高了系统数据库的数据存储稳定性，更利于数据的扩容以及系统业务运营。
以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (9)

1.一种文件存储方法，其特征在于，包括以下步骤：
记录父文件夹的元信息，保存在主key中，其中，所述主key用于标识父文件夹的关键字，所述主key保存的元信息至少包括：当前最大的文件标识、当前数据所在set、文件删除信息和/或文件夹及文件的写入时间，其中，set用于表示集群；
当所述父文件夹下包括至少一子文件夹列表和/或文件列表时，将所述父文件夹下的所述至少一子文件夹列表和/或文件列表的内容保存至基于所述主key的副key中，其中，所述副key是基于所述主key生成的。
2.根据权利要求1所述的方法，其特征在于，所述副key为多个，每个所述副key分别独立保存相应的子文件夹列表和/或文件列表的内容。
3.根据权利要求1所述的方法，其特征在于，还包括：
在相应的副key中添加、删除或重命名所述父文件夹下的子文件夹列表和/或文件列表。
4.根据权利要求3所述的方法，其特征在于，所述在相应的副key中添加、删除或重命名所述父文件夹下的子文件夹列表和/或文件列表的步骤之后还包括：
更新所述主key中的元信息。
5.根据权利要求1-4中任一项所述的方法，其特征在于，所述记录父目录下文件夹的元信息，保存在主key中的步骤之前还包括：
基于所述主key生成所述副key。
6.一种文件存储装置，其特征在于，包括：
主存储模块，用于记录父文件夹的元信息，保存在主key中，其中，所述主key用于标识父文件夹的关键字，所述主key保存的元信息至少包括：当前最大的文件标识、当前数据所在set、文件删除信息和/或文件夹及文件的写入时间，其中，set用于表示集群；
副存储模块，用于当所述父文件夹下包括至少一子文件夹列表和/或文件列表时，将所述父文件夹下的所述至少一子文件夹列表和/或文件列表的内容保存至基于所述主key的副key中，其中，所述副key是基于所述主key生成的。
7.根据权利要求6所述的装置，其特征在于，所述副key为多个，每个所述副key分别独立保存相应的子文件夹列表和/或文件列表的内容。
8.根据权利要求6所述的装置，其特征在于，还包括：
处理模块，用于在相应的副key中添加、删除或重命名所述父文件夹下的子文件夹列表和/或文件列表；
更新模块，用于更新所述主key中的元信息。
9.根据权利要求6、7或8所述的装置，其特征在于，还包括：
生成模块，用于基于所述主key生成所述副key。
CN201210238427.6A 2012-07-10 2012-07-10 文件存储方法及装置 Active CN103544156B (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201210238427.6A CN103544156B (zh) 2012-07-10 2012-07-10 文件存储方法及装置
PCT/CN2013/079084 WO2014008856A1 (en) 2012-07-10 2013-07-09 Method and apparatus for file storage
US13/963,434 US9146930B2 (en) 2012-07-10 2013-08-09 Method and apparatus for file storage
PH12014501762A PH12014501762A1 (en) 2012-07-10 2014-08-05 Method and apparatus for file storage

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201210238427.6A CN103544156B (zh) 2012-07-10 2012-07-10 文件存储方法及装置

Publications (2)

Publication Number Publication Date
CN103544156A CN103544156A (zh) 2014-01-29
CN103544156B true CN103544156B (zh) 2019-04-09

Family

ID=49915415

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201210238427.6A Active CN103544156B (zh) 2012-07-10 2012-07-10 文件存储方法及装置

Country Status (4)

Country Link
US (1) US9146930B2 (zh)
CN (1) CN103544156B (zh)
PH (1) PH12014501762A1 (zh)
WO (1) WO2014008856A1 (zh)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105022743A (zh) * 2014-04-24 2015-11-04 中兴通讯股份有限公司 一种管理索引的方法及装置
CN105446965A (zh) * 2014-05-30 2016-03-30 北大方正集团有限公司 一种存储数据的方法及服务器
CN104268280B (zh) * 2014-10-17 2017-07-07 中国人民解放军国防科学技术大学 一种基于键值数据库的层次化存储与查询方法
US9727742B2 (en) 2015-03-30 2017-08-08 Airbnb, Inc. Database encryption to provide write protection
US9760591B2 (en) 2015-05-14 2017-09-12 Walleye Software, LLC Dynamic code loading
CN105117489B (zh) * 2015-09-21 2018-10-19 北京金山安全软件有限公司 一种数据库管理方法、装置及电子设备
CN105677746A (zh) * 2015-12-29 2016-06-15 上海爱数信息技术股份有限公司 一种基于数据库事务操作的重复文档归并系统及方法
US10198469B1 (en) 2017-08-24 2019-02-05 Deephaven Data Labs Llc Computer data system data source refreshing using an update propagation graph having a merged join listener
US11023419B2 (en) * 2018-08-13 2021-06-01 Sap Se Folder key management
CN109299043A (zh) * 2018-12-13 2019-02-01 浪潮电子信息产业股份有限公司 分布式集群系统大文件删除方法、装置、设备及存储介质
US11281634B2 (en) 2019-01-11 2022-03-22 Red Hat, Inc. Management of volume files in a distributed file system
CN112347053B (zh) * 2020-11-08 2024-03-26 北京工业大学 一种基于递归提取的复杂文件数据包差异性比对方法
US20230014029A1 (en) * 2021-07-06 2023-01-19 Sap Se Local indexing for metadata repository objects
US12019587B2 (en) * 2022-03-23 2024-06-25 Procore Technologies, Inc. Metadata-based recommendations of file names
US20240168752A1 (en) * 2022-11-18 2024-05-23 Microsoft Technology Licensing, Llc Multi-mode in-context service integration
CN116303267A (zh) * 2023-03-06 2023-06-23 北京百度网讯科技有限公司 数据访问方法、装置、设备以及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101446984A (zh) * 2009-01-09 2009-06-03 成都市华为赛门铁克科技有限公司 一种文件存储方法、装置及文件删除方法和装置
CN102110146A (zh) * 2011-02-16 2011-06-29 清华大学 基于键值key-value存储的分布式文件系统元数据管理方法
CN102158546A (zh) * 2011-02-28 2011-08-17 中国科学院计算技术研究所 一种集群文件系统及其文件服务方法
CN102169497A (zh) * 2011-04-13 2011-08-31 浪潮(北京)电子信息产业有限公司 一种通过位图方式管理元数据的方法及装置
CN102411637A (zh) * 2011-12-30 2012-04-11 创新科软件技术（深圳）有限公司 分布式文件系统的元数据管理方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8229985B2 (en) * 2005-02-07 2012-07-24 Cisco Technology, Inc. Arrangement for a distributed file system having data objects mapped independent of any data object attribute
KR100667827B1 (ko) * 2005-11-02 2007-01-11 삼성전자주식회사 컨텐츠 파일 정보 관리 방법, 장치와 그 방법을 수행하는프로그램이 기록된 기록 매체
US8353012B2 (en) * 2008-02-26 2013-01-08 Alejandro Emilio Del Real Internet-based group website technology for content management and exchange (system and methods)
US20100257218A1 (en) * 2009-04-03 2010-10-07 Konstantin Iliev Vassilev Merging multiple heterogeneous file systems into a single virtual unified file system
AU2010263721A1 (en) * 2009-06-25 2012-02-16 Shuhei Nishiyama Database management device using key-value store with attributes, and key-value-store structure caching-device therefor
CN101719141B (zh) * 2009-12-24 2011-09-07 成都市华为赛门铁克科技有限公司 基于目录对象的文件处理方法和系统
CN102033938B (zh) * 2010-12-10 2012-06-06 天津神舟通用数据技术有限公司 基于二级映射的集群动态扩展方法
US8332357B1 (en) * 2011-06-10 2012-12-11 Microsoft Corporation Identification of moved or renamed files in file synchronization
US8849777B1 (en) * 2011-06-30 2014-09-30 Emc Corporation File deletion detection in key value databases for virtual backups
US8700683B2 (en) * 2011-10-24 2014-04-15 Nokia Corporation Method and apparatus for providing a key-value based storage interface
US8819090B2 (en) * 2012-04-23 2014-08-26 Citrix Systems, Inc. Trusted file indirection

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101446984A (zh) * 2009-01-09 2009-06-03 成都市华为赛门铁克科技有限公司 一种文件存储方法、装置及文件删除方法和装置
CN102110146A (zh) * 2011-02-16 2011-06-29 清华大学 基于键值key-value存储的分布式文件系统元数据管理方法
CN102158546A (zh) * 2011-02-28 2011-08-17 中国科学院计算技术研究所 一种集群文件系统及其文件服务方法
CN102169497A (zh) * 2011-04-13 2011-08-31 浪潮(北京)电子信息产业有限公司 一种通过位图方式管理元数据的方法及装置
CN102411637A (zh) * 2011-12-30 2012-04-11 创新科软件技术（深圳）有限公司 分布式文件系统的元数据管理方法

Also Published As

Publication number Publication date
WO2014008856A1 (en) 2014-01-16
CN103544156A (zh) 2014-01-29
PH12014501762B1 (en) 2014-11-10
US20140019494A1 (en) 2014-01-16
PH12014501762A1 (en) 2014-11-10
US9146930B2 (en) 2015-09-29

Similar Documents

Publication Publication Date Title
CN103544156B (zh) 文件存储方法及装置
CN104866497B (zh) 分布式文件系统列式存储的元数据更新方法、装置、主机
CN102184211B (zh) 文件系统和检索、写入、修改或删除文件的方法与装置
CN105574093B (zh) 一种在基于HDFS的spark-sql大数据处理系统上建立索引的方法
CN100468402C (zh) 一种数据存储及查询方法
CN105787093B (zh) 一种基于LSM-Tree结构的日志文件系统的构建方法
CN104881466B (zh) 数据分片的处理以及垃圾文件的删除方法和装置
CN103064639A (zh) 数据存储方法及装置
CN102915278A (zh) 重复数据删除方法
CN105900093B (zh) 一种KeyValue数据库的数据表的更新方法与表数据更新装置
CN111427847B (zh) 面向用户自定义元数据的索引与查询方法和系统
CN105718507A (zh) 一种数据迁移方法和装置
JP2005302038A (ja) Ｂツリー中の連続キーの名前を変更する方法およびシステム
CN106960020B (zh) 一种创建索引表的方法及设备
CN107239569A (zh) 一种分布式文件系统子树存储方法及装置
CN107506477A (zh) 一种档案管理系统
DE112021000945T5 (de) Auf einem Dateisystem-Verzeichnisbaum oder Objekt-Speicherbucket beruhende Übernahme von benutzerspezifischen Metadatentags
CN103942301B (zh) 一种面向多数据类型访问应用的分布式文件系统
CN104536908B (zh) 一种面向单机的海量小记录高效存储管理方法
CN102024019A (zh) 一种分布式文件系统中基于后缀树的目录组织方法
CN105512325B (zh) 多版本数据索引的更新、删除与建立方法及装置
CN104408128B (zh) 一种基于b+树异步更新索引的读优化方法
TW201021027A (en) Disk layout method for object-based storage device
CN106708911A (zh) 一种云环境下数据文件同步的方法和装置
CN102955808A (zh) 一种数据获取方法和分布式文件系统

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20190805

Address after: 518000 Nanshan District science and technology zone, Guangdong, Zhejiang Province, science and technology in the Tencent Building on the 1st floor of the 35 layer

Co-patentee after: Tencent cloud computing (Beijing) limited liability company

Patentee after: Tencent Technology (Shenzhen) Co., Ltd.

Address before: Shenzhen Futian District City, Guangdong province 518044 Zhenxing Road, SEG Science Park 2 East Room 403

Patentee before: Tencent Technology (Shenzhen) Co., Ltd.

TR01 Transfer of patent right