CN102855284B - 一种集群存储系统的数据管理方法及系统 - Google Patents
一种集群存储系统的数据管理方法及系统 Download PDFInfo
- Publication number
- CN102855284B CN102855284B CN201210276461.2A CN201210276461A CN102855284B CN 102855284 B CN102855284 B CN 102855284B CN 201210276461 A CN201210276461 A CN 201210276461A CN 102855284 B CN102855284 B CN 102855284B
- Authority
- CN
- China
- Prior art keywords
- data
- file
- node
- distributed
- module
- 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
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种集群存储系统的数据管理方法及系统,属于集群存储技术领域,该方法利用磁盘文件系统存储和管理元数据,数据布局以目录为基本单位进行分布;客户端对数据布局信息进行感知并发出数据访问指令,存储服务器根据客户端的数据访问指令判断查找路径是否为根目录,如是,则选定特定的活动节点作为目标节点进行数据访问;如否,根据路径输入参数计算Hash值,获取数据布局信息,查找目标节点并进行数据访问。本发明的方法和系统消除了元数据管理的性能瓶颈、单点故障、数据一致性等一系列相关问题,系统扩展性显著提高,系统并发性和性能将实现线性扩展增长。
Description
技术领域
本发明涉及集群存储技术领域,尤其涉及一种集群存储系统的数据管理方法及系统。
背景技术
云存储和大数据背景下,非结构化数据呈现爆炸式的增长,面对海量的存储系统,高效的元数据管理和数据定位是个巨大的挑战,直接影响系统的扩展性、性能、可靠性和稳定性等。
现有技术方案主要是采用专用元数据服务来管理元数据,包括集中式和分布式两种模型,数据定位通过向元数据服务器进行查询实现。图1为现有技术中元数据服务模型示意图,如图1所示,图1(a)为集中式元数据服务模型,该模型提供一个中央元数据服务器负责元数据的存储和客户端查询请求,它提供统一的文件系统命名空间,并处理名字解析和数据定位等访问控制功能。传统的NAS系统中,I/O数据流需要经过服务器,而分布式文件系统中,I/O数据流不需要经过元数据服务器,由客户端与存储节点直接交互。这个架构上的变革,使得控制流与数据流分离开来,元数据服务器和存储服务器各司其职,系统扩展性和性能上获得了极大的提升。显而易见,集中式元数据服务模型的最大优点就是设计实现简单,本质上相当于设计一个单机应用程序,对外提供网络访问接口即可,如Socket,RPC,HTTP REST或SOAP等。元数据服务设计实现的关键是OPS吞吐量,即单位时间处理的操作数,这对集中式元数据服务模型尤其关键,因为会受到系统Scale-Up方面的限制。为了优化OPS,该模型对CPU、内存、磁盘要求较高,条件允许的情况下尽量使用高性能CPU、大内存和高速磁盘,甚至后端存储可考虑使用高端磁盘阵列或SSD。在软件架构方面设计,应该考虑多进程/线程(池)、异步通信、Cache、事件驱动等实现机制。但集中式元数据服务模型存在性能瓶颈和单点故障问题。
性能瓶颈,这种模型下元数据服务器在负载不断增大时将很快成为整个系统性能的瓶颈。根据Amdahl定律,系统性能加速比最终受制于串行部分的比重,这决定了系统使用并行手段所能改进性能的潜力。这里,元数据服务器就是串行的部分,它直接决定着系统的扩展规模和性能。文件元数据的基本特性要求它必须同步地进行维护和更新,任何时候对文件数据或元数据进行操作时,都需要同步更新元数据。客户端访问分布式文件系统时,都需要先与元数据服务器进行交互,这包括命名空间解析、数据定位、访问控制等,然后才直接与存储节点进行I/O交互。随着系统规模不断扩大,存储节点、磁盘数量、文件数量、客户端数据、文件操作数量等都将急剧增加,而运行元数据服务器的物理服务器性能毕竟终究有限,因此集中式元数据服务器将最终成为性能瓶颈。
单点故障(SPOF,Single Point of Failure),这个问题比性能瓶颈更加严重。整个系统严重依赖于元数据服务器,一旦出现问题,系统将变得完全不可用,直接导致应用中断并影响业务连续性。物理服务器所涉及的网络、计算和存储部件以及软件都有可能发生故障,因此单点故障问题潜在的,采用更优的硬件和软件只能降低发生的概率而无法避免。目前,SPOF问题主要是采用HA机制来解决,根据可用性要求的高低,镜像一个或多个元数据服务器(逻辑的或物理的均可),构成一个元数据服务HA集群。集群中一台作为主元数据服务器,接受和处理来自客户端的请求,并与其他服务器保持同步。当主元数据服务器发生问题时,自动选择一台可用服务器作为新的主服务器,这一过程对上层应用是透明的,不会产生业务中断。HA机制能够解决SPOF问题,但同时增加了成本开销,只有主服务器是活动的,其他服务器均处于非活动状态,对性能提升没有任何帮助。
图1(b)为分布式元数据服务模型,即使用多台服务器构成集群协同为分布式文件系统提供元数据服务,从而消除集中式元数据服务模型的性能瓶颈和单点故障问题。这种模型可以细分为两类,一为全对等模式,即集群中的每个元数据服务器是完全对等的,每个都可以独立对外提供元数据服务,然后集群内部进行元数据同步,保持数据一致性,比如ISILON、LoongStore、CZSS等。另一类为全分布模式,集群中的每个元数据服务器负责部分元数据服务(分区可以重叠),共同构成完整的元数据服务,比如PanFS,GPFS,Ceph等。分布式元数据服务模型,将负载分散到多台服务器解决了性能瓶颈问题,利用对等的服务器或冗余元数据服务分区解决了单点故障问题。分布式看似非常完善,然而它大大增加了设计实现上的复杂性,同时可能会引入了新的问题,即性能开销和数据一致性问题。
性能开销,分布式系统通常会引由于节点之间的数据同步而引入额外开销,这是因为同步过程中需要使用各种锁和同步机制,以保证数据一致性。如果节点同步问题处理不当,性能开销将对系统扩展性和性能产生较大影响,和集中式元数据模型一样形成性能瓶颈,这就对分布式元数据服务器的设计提出了更高的要求。这种性能开销会抵消一部分采用分布式所带来的性能提升,而且随着元数据服务器数量、文件数量、文件操作、存储系统规模、磁盘数量、文件大小变小、I/O操作随机性等增加而加剧。另外,元数据服务器规模较大时,高并发性元数据访问会导致同步性能开销更加显著。目前,一些分布式文件系统采用高性能网络(如InfiniBand,GibE等)、SSD固态硬盘或SAN磁盘阵列、分布式共享内存(SMP或ccNUMA)等技术进行集群内部的元数据同步和通信。这的确可以明显提高系统性能以抵消同步开销,不过成本方面也徒然增加许多。
数据一致性,这是分布式系统必须面对的难题。分布式元数据服务模型同样面临潜在的系统发生错误的风险,虽然一部分元数据节点发生故障不会致使整个系统宕机,但却可能影响整个系统正常运行或出现访问错误。为了保证高可用性,元数据会被复制到多个节点位置,维护多个副本之间的同步具有很高的风险。如果元数据没有及时同步或者遭受意外破坏,同一个文件的元数据就会出现不一致,从而导致访问文件数据的不一致,直接影响到上层数据应用的正确性。这种风险发生的概率随着系统规模的扩大而大幅增加,因此分布式元数据的同步和并发访问是个巨大的挑战。使用同步方法对元数据进行同步,再结合事务或日志,自然可以解决数据一致性问题,然而这大大降低了系统的并发性,违背了分布式系统的设计初衷。在保证元数据一致性的前提下,尽可能地提高并发性,这就对同步机制和算法设计方面提出了严格要求,复杂性和挑战性不言而喻。
分布式元数据服务模型虽然解决了集中式数据服务模型中存在的问题,但同时引入了设计复杂性、性能开销和元数据同步一致性等问题。这些问题直接影响到系统性能和扩展性。
发明内容
本发明的目的在于克服现有技术的缺陷和不足,提供一种集群存储系统的数据管理方法及系统,消除了上述元数据管理的性能瓶颈、单点故障、数据一致性等一系列相关问题。
为达到上述目的,本发明是通过以下技术方案来实现的:
一种集群存储系统的数据管理方法,该方法基于包括客户端和存储服务器集群的系统实现,包括数据存储和访问的操作,所述数据存储的操作包括:
利用磁盘文件系统存储元数据,数据布局以目录为基本单位进行分布并分配Hash范围,其中,文件的父目录利用扩展属性记录存储节点的映射关系,子文件在父目录所属存储节点中进行分布;
所述方法基于所述数据布局进行数据访问操作,其中,所述数据访问操作包括:
S1:客户端对数据布局信息进行感知并发出数据访问指令,集成服务器根据客户端的数据访问指令判断查找路径是否为根目录,如是,则执行步骤S2,如否,执行步骤S3;
S2:选定特定的活动节点作为目标节点进行数据访问;
S3:根据路径输入参数计算Hash值,获取数据布局信息,查找目标节点并进行数据访问。
相应地,本发明还公开一种集群存储系统的数据管理系统,所述数据管理系统包括客户端和存储服务器集群,所述客户端包括数据布局管理模块和元数据管理模块,所述存储服务器包括根目录判定模块、数据布局存储模块、查询模块;
所述数据布局管理模块用于对以目录为基本单位进行分布并分配Hash范围的数据进行管理;
所述元数据管理模块用于利用磁盘文件系统管理元数据;
所述根目录判定模块用于根据客户端发出的数据访问指令,判断查找路径是否为根目录;
所述查询模块用于根据根目录判定模块的判定结果,查找目标节点进行数据访问,如判定结果为是,则选定特定活动节点作为目标节点进行数据访问;如判定结果为否,则根据路径输入参数计算Hash值,获取数据布局信息,查找目标节点并进行数据访问;
所述数据布局存储模块用于利用磁盘文件系统存储元数据,数据布局以目录为基本单位进行分布并分配Hash范围,文件的父目录利用扩展属性记录存储节点的映射关系,子文件在父目录所属存储节点中进行分布。
本发明的技术方案,采用无元数据服务模型管理元数据,不需要专用的元数据服务器,元数据和数据没有分离而是一起存储,通过智能算法替代原有的查询方法进行数据定位。这种方法消除了元数据管理的性能瓶颈、单点故障、数据一致性等一系列相关问题,系统扩展性显著提高,系统并发性和性能将实现线性扩展增长。
附图说明
图1为现有技术中元数据服务模型示意图;
图2为本发明实施例的集群存储系统的数据管理方法的流程图;
图3为本发明实施例的集群存储系统的数据管理系统的示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步说明。
图2为本发明实施例的集群存储系统的数据管理方法的流程图。如图2所示,该方法基于包括客户端和存储服务器集群的系统实现,包括数据存储和访问的操作,所述数据存储的操作包括:
利用磁盘文件系统存储元数据,数据布局以目录为基本单位进行分布并分配Hash范围;磁盘文件系统文件的父目录利用扩展属性记录存储节点的映射关系,子文件在父目录所属存储节点中进行分布;所述方法基于所述数据布局进行数据访问操作。
其中,所述方法还包括创建新文件的操作,在父目录所属存储节点上新建文件时,新建文件分布到父目录所属存储节点上,新增节点不参加分布。
所述方法还包括父目录所属存储节点上文件重命名的操作,其中,在目标存储服务器上创建一个链接指向实际的存储服务器,访问时由服务器解析并进行重定向,服务器后台同时进行文件迁移,成功后文件链接被自动删除。
所述数据访问操作包括:
S1:客户端对数据布局信息进行感知并发出数据访问指令,集成服务器根据客户端的数据访问指令判断查找路径是否为根目录,如是,则执行步骤S2,如否,执行步骤S3;
S2:选定特定的活动节点作为目标节点进行数据访问;
本实施例中选择某个活动节点作为目标节点。如默认元数据存储节点中第一个活动节点作为目标节点。
S3:根据路径输入参数计算Hash值,获取数据布局信息,查找目标节点并进行数据访问。
其中,根据路径输入参数利用Davies-Meyer算法计算文件名hash值。本实施例中,使用Davies-Meyer算法计算文件名hash值,获得一个32位整数。Davies-Meyer算法具有非常好的hash分布性,计算效率很高。假设集群中有N个存储节点,则32位整数空间被平均划分为N个连续子空间,每个空间分别映射到一个存储节点。这样,计算得到的32位hash值就会被投射到一个存储节点,即我们要选择的目标节点。
根据获取到的数据布局信息,查找目标节点包括,通过将计算得到的文件名Hash值与预先分配的Hash范围进行匹配,查找目标节点,如果找到目标节点,则在所述目标节点中查找目标文件;如果未找到目标节点,则按照设置的自动搜索模式搜索所有节点。
所述按照设置的自动搜索模式搜索包括:以路径为目录,在所有节点中查找目标文件;如路径不存在,则返回错误。
当集群中加入一个新存储节点进行扩容时,如果不作其他任何处理,hash范围映射空间将会发生变化,现有的文件目录可能会被重新定位到其他的存储节点上,从而导致数据定位失败。一种解决问题的方法是对文件目录进行重新分布,把文件移动到正确的存储节点上去,但这大大加重了系统负载,尤其是对于已经存储大量的数据的海量存储系统来说显然是不可行的。另一种方法是使用一致性哈希算法,修改新增节点及相邻节点的hash映射空间,仅需要移动相邻节点上的部分数据至新增节点,影响相对小了很多。然而,这又带来另外一个问题,即系统整体负载不均衡。针对上述方法存在的局限性,本实施例中采用了更为弹性的算法。
本实施例中,将新建目录分布到所有存储节点上,新增节点加入数据分布并分配Hash范围。
新建文件分布到父目录所属存储节点上,新增节点不参加分布。
数据分布是以目录为基本单位的,文件的父目录利用扩展属性记录了节点映射信息,其下面子文件目录在父目录所属存储服务器中进行分布。由于文件目录事先保存了分布信息,因此新增节点不会影响现有文件存储分布,它将从此后的新创建目录开始参与存储分布调度。这种设计,新增节点不需要移动任何文件,但是负载均衡没有平滑处理,老节点负载较重。本方法设计中在新建文件时优先考虑容量负载最轻的节点,在目标存储节点上创建文件链接直向真正存储文件的节点。集群存储系统执行负载平滑,将进行文件移动和重新分布,此后所有存储节点容量相对均衡并全部参与分布调度。
如果一个文件被改名,显然hash算法将产生不同的值,非常可能会发生文件被定位到不同的存储服务器上,从而导致文件访问失败。采用数据移动的方法,对于大文件是很难在实时完成的。为了不影响性能和服务中断,本方法采用了文件链接来解决文件重命名问题,在目标存储服务器上创建一个链接指向实际的存储服务器,访问时由系统解析并进行重定向。系统后台同时进行文件迁移,成功后文件链接将被自动删除。对于文件移动也作类似处理,好处是前台操作可实时处理,物理数据迁移置于后台选择适当时机执行。
具体定位流程如下:
(a)如果路径path为根目录,则选定第一个活动节点作为目标节点;
(b)否则,以path为输入参数计算hash值,从父目录扩展属性中获取数据布局信息,然后查找定位目标节点;
(c)如果找到目标节点,则在目标节点中查找path;如果没有找到目标节点,根据设置自动搜索模式,将搜索所有的节点;
(d)以上述自动搜索模式搜索所有节点时,以path为目录,在所有节点中查找目标文件;
(e)如果未找到path,则返回错误;
(f)对所找到的目标节点进行数据访问。
新建目录分布到所有存储节点上,新增节点参加分布,并分配hash范围。目录创建流程如下:
(g)计算目录hash值,查找目标节点。若未找到则返回;
(h)在目录节点上创建目录;
(i)向其他所有节点发送请求创建目录;
(j)为目录分配hash范围。
新建文件分布到父目录所分布的存储节点上,新增节点不参加分布。文件创建流程如下:
(k)计算文件名hash值,查找目标卷。若未找到则返回;
(l)如果目标节点空闲容量在预定水位以下,则创建文件并返回;
(m)查找空闲容量在预定水位以下的节点,在其上创建文件,并在目标节点上创建链接指向实际文件。
图3为本发明实施例的集群存储系统的数据管理系统的示意图。如图3所示,所述数据管理系统由客户端和存储服务器集群组成,它摒弃了元数据服务,未将控制流与数据流进行分离,而是将元数据与数据本身统一存储,利用磁盘文件系统(如EXT4、XFS)文件的属性和扩展属性存储和管理元数据。数据分布是以目录为基本单位的,文件的父目录利用扩展属性记录了存储节点映射信息,子文件在父目录所属存储节点中进行分布。由于文件目录事先保存了分布信息,因此新增节点不会影响现有文件数据分布,它将从此后的新创建目录开始参与存储分布调度。客户端对数据布局信息感知,只需根据路径和文件名就可以采用智能算法对数据进行并行定位,而不需要查询索引或者其他服务器。
所述客户端包括数据布局管理模块和元数据管理模块,所述存储服务器包括根目录判定模块、数据布局存储模块、查询模块;
所述数据布局管理模块用于对以目录为基本单位进行分布并分配Hash范围的数据进行管理;
所述元数据管理模块用于利用磁盘文件系统管理元数据;
所述根目录判定模块用于根据客户端发出的数据访问指令,判断查找路径是否为根目录;
所述查询模块用于根据根目录判定模块的判定结果,查找目标节点进行数据访问,如判定结果为是,则选定特定活动节点作为目标节点进行数据访问;如判定结果为否,则根据路径输入参数计算Hash值,获取数据布局信息,查找目标节点并进行数据访问;
所述数据布局存储模块用于利用磁盘文件系统存储元数据,数据布局以目录为基本单位进行分布并分配Hash范围,文件的父目录利用扩展属性记录存储节点的映射关系,子文件在父目录所属存储节点中进行分布。
所述系统还包括新建目录模块,所述新建目录模块将新建目录分布到所有存储节点上,新增节点加入数据分布并分配Hash范围。
所述系统还包括新建文件模块,所述新建文件模块将新建文件分布到父目录所属存储节点上,新增节点不参加分布。
所述系统还包括文件重命名模块,所述文件重命名模块用于在目标存储服务器上创建一个链接指向实际的存储服务器,访问时由服务器解析并进行重定向,服务器后台同时进行文件迁移,成功后文件链接被自动删除。
本发明的技术方案,采用无元数据服务模型管理元数据,不需要专用的元数据服务器,元数据和数据没有分离而是一起存储,通过智能算法替代原有的查询方法进行数据定位。这种方法消除了元数据管理的性能瓶颈、单点故障、数据一致性等一系列相关问题,系统扩展性显著提高,系统并发性和性能将实现线性扩展增长。
上述仅为本发明的较佳实施例及所运用技术原理,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围内。
Claims (11)
1.一种集群存储系统的数据管理方法,该方法基于包括客户端和存储服务器集群的系统实现,包括数据存储和访问的操作,其特征在于,所述数据存储的操作包括:
利用磁盘文件系统存储元数据,数据布局以目录为基本单位进行分布并分配Hash范围,其中,文件的父目录利用扩展属性记录存储节点的映射关系,子文件在父目录所属存储节点中进行分布;
所述方法基于所述数据布局进行数据访问操作,其中,所述数据访问操作包括:
S1:客户端对数据布局信息进行感知并发出数据访问指令,集成服务器根据客户端的数据访问指令判断查找路径是否为根目录,如是,则执行步骤S2,如否,执行步骤S3;
S2:选定特定的活动节点作为目标节点进行数据访问;
S3:根据路径输入参数计算Hash值,获取数据布局信息,查找目标节点并进行数据访问。
2.根据权利要求1所述的集群存储系统的数据管理方法,其特征在于,所述方法还包括创建新目录的操作,其中,磁盘文件系统在创建新的目录时,将新建目录分布到所有存储节点上,新增节点加入数据分布并分配Hash范围。
3.根据权利要求1所述的集群存储系统的数据管理方法,其特征在于,所述方法还包括创建新文件的操作,其中,在父目录所属存储节点上新建文件时,新建文件分布到父目录所属存储节点上,新增节点不参加分布。
4.根据权利要求3所述的集群存储系统的数据管理方法,其特征在于,所述方法还包括父目录所属存储节点上文件重命名的操作,其中,在目标存储服务器上创建一个链接指向实际的存储服务器,访问时由服务器解析并进行重定向,服务器后台同时进行文件迁移,成功后文件链接被自动删除。
5.根据权利要求1所述的集群存储系统的数据管理方法,其特征在于,所述步骤S3中根据路径输入参数计算hash值包括利用Davies-Meyer算法计算文件名hash值。
6.根据权利要求1或5所述的集群存储系统的数据管理方法,其特征在于,所述步骤S3中根据获取到的数据布局信息,查找目标节点包括,通过将计算得到的文件名Hash值与预先分配的Hash范围进行匹配,查找目标节点,如果找到目标节点,则在所述目标节点中查找目标文件;如果未找到目标节点,则按照设置的自动搜索模式搜索所有节点。
7.根据权利要求6所述的集群存储系统的数据管理方法,其特征在于,所述按照设置的自动搜索模式搜索包括:以路径为目录,在所有节点中查找目标文件;如路径不存在,则返回错误。
8.一种集群存储系统的数据管理系统,所述数据管理系统包括客户端和存储服务器集群,其特征在于,所述客户端包括数据布局管理模块和元数据管理模块,所述存储服务器包括根目录判定模块、数据布局存储模块、查询模块;
所述数据布局管理模块用于对以目录为基本单位进行分布并分配Hash范围的数据进行管理;
所述元数据管理模块用于利用磁盘文件系统管理元数据;
所述根目录判定模块用于根据客户端发出的数据访问指令,判断查找路径是否为根目录;
所述查询模块用于根据根目录判定模块的判定结果,查找目标节点进行数据访问,如判定结果为是,则选定特定活动节点作为目标节点进行数据访问;如判定结果为否,则根据路径输入参数计算Hash值,获取数据布局信息,查找目标节点并进行数据访问;
所述数据布局存储模块用于利用磁盘文件系统存储元数据,数据布局以目录为基本单位进行分布并分配Hash范围,文件的父目录利用扩展属性记录存储节点的映射关系,子文件在父目录所属存储节点中进行分布。
9.根据权利要求8所述的集群存储系统的数据管理系统,其特征在于,所述系统还包括新建目录模块,所述新建目录模块用于将新建目录分布到所有存储节点上,新增节点加入数据分布并分配Hash范围。
10.根据权利要求8所述的集群存储系统的数据管理系统,其特征在于,所述系统还包括新建文件模块,所述新建文件模块用于将新建文件分布到父目录所属存储节点上,新增节点不参加分布。
11.根据权利要求8所述的集群存储系统的数据管理系统,其特征在于,所述系统还包括文件重命名模块,所述文件重命名模块用于在目标存储服务器上创建一个链接指向实际的存储服务器,访问时由服务器解析并进行重定向,服务器后台同时进行文件迁移,成功后文件链接被自动删除。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210276461.2A CN102855284B (zh) | 2012-08-03 | 2012-08-03 | 一种集群存储系统的数据管理方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210276461.2A CN102855284B (zh) | 2012-08-03 | 2012-08-03 | 一种集群存储系统的数据管理方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102855284A CN102855284A (zh) | 2013-01-02 |
CN102855284B true CN102855284B (zh) | 2016-08-10 |
Family
ID=47401872
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210276461.2A Active CN102855284B (zh) | 2012-08-03 | 2012-08-03 | 一种集群存储系统的数据管理方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102855284B (zh) |
Families Citing this family (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102855294B (zh) * | 2012-08-13 | 2016-12-21 | 北京联创信安科技股份有限公司 | 一种智能哈希数据布局方法、集群存储系统及其方法 |
CN103078944B (zh) * | 2013-01-08 | 2016-04-06 | 赛凡信息科技(厦门)有限公司 | 基于分布式对称文件系统的数据中心架构 |
CN103106286B (zh) * | 2013-03-04 | 2017-02-01 | 曙光信息产业(北京)有限公司 | 元数据的管理方法和装置 |
CN104144150A (zh) * | 2013-05-10 | 2014-11-12 | 中国电信股份有限公司 | 利用元数据访问信息的方法、装置和系统 |
CN104182418B (zh) * | 2013-05-27 | 2018-11-16 | 阿里巴巴集团控股有限公司 | 节点元数据获取方法与装置 |
CN104572648B (zh) * | 2013-10-11 | 2018-01-16 | 中国石油化工股份有限公司 | 一种基于高性能计算的存储统计系统及方法 |
CN103530387A (zh) * | 2013-10-22 | 2014-01-22 | 浪潮电子信息产业股份有限公司 | 一种hdfs针对小文件的改进方法 |
CN103647797A (zh) * | 2013-11-15 | 2014-03-19 | 北京邮电大学 | 一种分布式文件系统及其数据访问方法 |
CN103914264B (zh) * | 2014-03-12 | 2017-09-12 | 汉柏科技有限公司 | 一种矩阵硬盘的数据存储方法及系统 |
AU2015207840B2 (en) * | 2014-07-31 | 2020-06-18 | Samsung Electronics Co., Ltd. | System and method of managing metadata |
US20170277477A1 (en) * | 2014-10-03 | 2017-09-28 | Agency For Science, Technology And Research | Distributed Active Hybrid Storage System |
CN105224607B (zh) * | 2015-09-06 | 2019-05-24 | 浪潮(北京)电子信息产业有限公司 | 一种模拟云存储设备的虚拟文件系统设计方法 |
CN105338118A (zh) * | 2015-11-30 | 2016-02-17 | 上海斐讯数据通信技术有限公司 | 分布式存储系统 |
CN105550371A (zh) * | 2016-01-27 | 2016-05-04 | 华中科技大学 | 一种面向大数据环境的元数据组织方法和系统 |
CN107346209B (zh) * | 2016-05-08 | 2022-05-20 | 上海霄云信息科技有限公司 | 一种多磁盘聚合式数据存储系统及其实现方法与应用方法 |
CN106791889B (zh) * | 2016-12-27 | 2019-07-09 | 北京奇艺世纪科技有限公司 | 一种视频处理方法及系统、分布式对象存储系统 |
CN106843755B (zh) * | 2017-01-04 | 2019-10-11 | 北京百度网讯科技有限公司 | 用于服务器集群的数据均衡方法与装置 |
CN107483571A (zh) * | 2017-08-08 | 2017-12-15 | 柏域信息科技(上海)有限公司 | 一种动态云存储方法及系统 |
CN107844592A (zh) * | 2017-11-17 | 2018-03-27 | 北京盛和大地数据科技有限公司 | 一种查询元数据的方法和装置 |
CN108196956A (zh) * | 2017-12-28 | 2018-06-22 | 郑州云海信息技术有限公司 | 一种nas服务节点实现nas服务的方法及系统 |
CN110581873B (zh) * | 2018-06-11 | 2022-06-14 | 中国移动通信集团浙江有限公司 | 一种跨集群重定向方法及监控服务器 |
CN111078120B (zh) * | 2018-10-18 | 2023-11-03 | 深信服科技股份有限公司 | 一种分布式文件系统的数据迁移方法、系统及相关组件 |
CN110300035B (zh) * | 2019-05-23 | 2021-07-13 | 厦门网宿有限公司 | 判断存储系统负载状态的方法、系统、装置及服务器 |
CN111459411B (zh) * | 2020-03-30 | 2023-07-21 | 北京奇艺世纪科技有限公司 | 数据迁移方法、装置、设备及存储介质 |
CN111488198B (zh) * | 2020-04-16 | 2023-05-23 | 湖南麒麟信安科技股份有限公司 | 一种超融合环境下的虚拟机调度方法、系统及介质 |
CN111813346A (zh) * | 2020-07-23 | 2020-10-23 | 山东超越数控电子股份有限公司 | 基于云平台搭建Ceph分布式存储的方法、系统、设备及介质 |
CN113239008A (zh) * | 2020-12-10 | 2021-08-10 | 哈工大大数据集团四川有限公司 | 一种应急大数据研判系统 |
CN112733183B (zh) * | 2020-12-23 | 2023-01-10 | 苏州浪潮智能科技有限公司 | 一种安全访问指定存储区域的方法、系统及介质 |
CN113326003B (zh) * | 2021-05-25 | 2024-03-26 | 北京计算机技术及应用研究所 | 一种分布式存储系统元数据访问智能加速方法 |
CN114153374B (zh) * | 2021-08-04 | 2022-06-28 | 北京天德科技有限公司 | 一种元数据与数据共同存储的分布式存储系统 |
CN114491111B (zh) * | 2022-02-16 | 2022-09-16 | 北京中电兴发科技有限公司 | 一种用于图片存储的分布式元数据系统 |
CN115858419B (zh) * | 2023-02-16 | 2023-07-14 | 苏州浪潮智能科技有限公司 | 元数据管理方法、装置、设备、服务器及可读存储介质 |
CN118052106A (zh) * | 2023-08-30 | 2024-05-17 | 中国人民解放军63921部队 | 一种用于物质点法数值仿真的前处理方法及系统 |
CN117009310B (zh) * | 2023-09-27 | 2024-01-23 | 苏州元脑智能科技有限公司 | 文件同步方法、装置、分布式全局内容库系统及电子设备 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101162469A (zh) * | 2007-11-09 | 2008-04-16 | 清华大学 | 基于快照的细粒度文件与目录版本管理方法 |
CN101354726A (zh) * | 2008-09-17 | 2009-01-28 | 中国科学院计算技术研究所 | 一种机群文件系统的内存元数据管理方法 |
CN101692239A (zh) * | 2009-10-19 | 2010-04-07 | 浙江大学 | 一种分布式文件系统元数据分配方法 |
CN102411637A (zh) * | 2011-12-30 | 2012-04-11 | 创新科软件技术(深圳)有限公司 | 分布式文件系统的元数据管理方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7634494B2 (en) * | 2005-05-03 | 2009-12-15 | Intel Corporation | Flash memory directory virtualization |
-
2012
- 2012-08-03 CN CN201210276461.2A patent/CN102855284B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101162469A (zh) * | 2007-11-09 | 2008-04-16 | 清华大学 | 基于快照的细粒度文件与目录版本管理方法 |
CN101354726A (zh) * | 2008-09-17 | 2009-01-28 | 中国科学院计算技术研究所 | 一种机群文件系统的内存元数据管理方法 |
CN101692239A (zh) * | 2009-10-19 | 2010-04-07 | 浙江大学 | 一种分布式文件系统元数据分配方法 |
CN102411637A (zh) * | 2011-12-30 | 2012-04-11 | 创新科软件技术(深圳)有限公司 | 分布式文件系统的元数据管理方法 |
Also Published As
Publication number | Publication date |
---|---|
CN102855284A (zh) | 2013-01-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102855284B (zh) | 一种集群存储系统的数据管理方法及系统 | |
US20200242129A1 (en) | System and method to improve data synchronization and integration of heterogeneous databases distributed across enterprise and cloud using bi-directional transactional bus of asynchronous change data system | |
Corbellini et al. | Persisting big-data: The NoSQL landscape | |
US10891267B2 (en) | Versioning of database partition maps | |
US8386540B1 (en) | Scalable relational database service | |
US9201742B2 (en) | Method and system of self-managing nodes of a distributed database cluster with a consensus algorithm | |
Agrawal et al. | Data management in the cloud: challenges and opportunities | |
Auradkar et al. | Data infrastructure at LinkedIn | |
Wu et al. | Survey of large-scale data management systems for big data applications | |
US10445433B2 (en) | Methods and systems of query engines and secondary indexes implemented in a distributed database | |
CN105871603B (zh) | 一种基于内存数据网格的实时流式数据处理失效恢复系统及方法 | |
Qiao et al. | On brewing fresh espresso: Linkedin's distributed data serving platform | |
Yang et al. | A Scalable Data Platform for a Large Number of Small Applications. | |
Gajendran | A survey on nosql databases | |
CN102420854A (zh) | 面向云存储的分布式文件系统 | |
US20150134611A1 (en) | Transferring objects between different storage devices based on timestamps | |
US20190065573A1 (en) | Database optimization using special partition specifications for replicas | |
US11003550B2 (en) | Methods and systems of operating a database management system DBMS in a strong consistency mode | |
Waqas et al. | Transaction management techniques and practices in current cloud computing environments: A survey | |
Nidzwetzki et al. | Distributed secondo: an extensible and scalable database management system | |
Chen et al. | Providing scalable database services on the cloud | |
Das | Scalable and elastic transactional data stores for cloud computing platforms | |
US10970177B2 (en) | Methods and systems of managing consistency and availability tradeoffs in a real-time operational DBMS | |
CN107547657A (zh) | 一种基于云存储系统中单点数据编号的方法、装置以及存储介质 | |
Li et al. | Apache shardingsphere: A holistic and pluggable platform for data sharding |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
CB02 | Change of applicant information |
Address after: 100085 No. 1, building 3, building ten, No. 8, 813 street, Beijing, Haidian District Applicant after: Beijing Lianchuang Xinan Technology Co., Ltd. Address before: 100085, room 712, room 7, block D, Jinyu Ka Wah building, No. 9, 3rd Street, Haidian District, Beijing Applicant before: Beijing Lianchuang Xinan Technology Co.,Ltd. |
|
COR | Change of bibliographic data | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |