CN112799841A - 一种数据对象存储管理的方法和装置 - Google Patents

Abstract

本发明涉及存储领域，特别是涉及一种数据对象存储管理的方法和装置。其中，方法的步骤包括：为每个应用程序建立相应的虚拟桶，配置每个虚拟桶管理的实际桶；虚拟桶对管理的每个实际桶进行初始化，根据数据类型配置实际桶的类型，并为每个桶分配存储范围；虚拟桶根据实际桶的数据类型和存储范围，将数据对象存放在相应的实际桶中；虚拟桶根据外部数据请求，按照需要访问的数据类型和每个实际桶的存储范围，与相应的实际桶进行数据交互。本发明通过在应用程序和实际桶之间增加虚拟桶，使实际桶对应用程序透明，应用程序无需对实际桶进行直接管理，简化了数据访问操作，减少了应用程序的操作负担。

Description

一种数据对象存储管理的方法和装置

【技术领域】

本发明涉及存储领域，特别是涉及一种数据对象存储管理的方法和装置。

【背景技术】

在目前分布式对象存储使用中，应用程序想要访问对象存储中的对象或者向对象存储中写入对象，都需要先创建存储桶(bucket)，再通过bucket读取或写入对象。

由于每个bucket所存储的对数量有上限，超过数量上限后索引效率会变的很差，官方建议每个bucket存储的对象数量不超过10万，并且每个bucket只能绑定一个存储池。因此，在实际使用中会产生以下两个问题：当应用程序向一个bucket存储的对象达到一定数量后，需要新建一个bucket存放对象。这就导致应用程序需要维护bucket信息，甚至需要不断修改应用程序以适应数量不断上涨的对象存储需求。由于一个应用程序的数据可能存在热数据和冷数据，热数据需要存储在SSD池中，而冷数据需要存储在HDD池中。那这个应用程序就需要分两种bucket类型存储冷热数据，而每种bucket类型随着对象数量上涨又有可能需要新建bucket，对应用程序非常不友好。

鉴于此，如何克服现有技术所存在的缺陷，解决现有技术中心bucket的管理方式对应用程序不友好的现象，是本技术领域待解决的问题。

【发明内容】

针对现有技术的以上缺陷或改进需求，本发明解决了应用程序在访问存储桶时存取、数据分类、数据管理较为复杂的问题。

本发明实施例采用如下技术方案：

第一方面，本发明提供了一种数据对象存储管理的方法，具体为：为每个应用程序建立相应的虚拟桶，配置每个虚拟桶管理的实际桶；虚拟桶对管理的每个实际桶进行初始化，根据数据类型配置实际桶的类型，并为每个桶分配存储范围；虚拟桶根据实际桶的数据类型和存储范围，将数据对象存放在相应的实际桶中；虚拟桶根据外部数据请求，按照需要访问的数据类型和每个实际桶的存储范围，与相应的实际桶进行数据交互。

优选的，与相应的实际桶进行数据交互，还包括：虚拟桶查找每一个实际桶在另一个对象网关节点中同名的实际桶，作为实际桶的备份桶；当虚拟桶接收到外部数据请求时，获取每个实际桶的访问状态；若实际桶出现访问异常，或需要访问的数据对象出现访问异常，虚拟桶将外部数据请求重定向到备份桶上。

优选的，若实际桶中数据对象的数量超过预定数量阈值，还包括：建立新的实际桶，将新建实际桶分配至原实际桶所在的虚拟桶中；根据新建实际桶的数量，重新计算虚拟桶中每个实际桶的存储范围；根据重新计算的存储范围，将原实际桶中的数据对象迁移入对应的实际桶中。

优选的，将原实际桶中的数据对象迁移入对应的实际桶中，具体包括：获取每个原实际桶的存储范围和每个新实际桶的存储范围；当存入新的数据对象时，按照重新计算后的实际桶的存储范围，将数据对象存入对应的实际桶中；当读取文件时，同时向原实际桶的存储范围所定位的实际桶和重新计算后的实际桶的存储范围所定位的实际桶发起读请求。

优选的，将原实际桶中的数据对象迁移入对应的实际桶中，还包括：根据预设的迁移策略，查找每个实际桶中不属于重新计算后的存储范围的数据对象，并将查找到的数据对象迁移至重新计算后的存储范围对应的实际桶中；当实际桶中所有的数据对象都按照重新计算后的存储范围分布后，在读取文件时，仅向重新计算后的存储范围所定位的实际桶发起读请求。

优选的，配置每个虚拟桶管理的实际桶，具体包括：每个虚拟桶管理一个或多个实际桶；每个实际桶由一个或多个虚拟桶进行管理。

优选的，与相应的实际桶进行数据交互，还包括判断虚拟桶中所有的实际桶的数据类型是否相同；若相同，直接计算数据对象所在的存储范围，访问存储范围对应的实际桶；若不同，先计算数据对象所在的存储范围，再访问每一个数据类型中存储范围对应的实际桶。

优选的，将数据对象存放在相应的实际桶中，还包括：若数据对象的数据类型发生变化，将数据对象迁移至新数据类型对应的实际桶中，并生成相应的重定向索引。

优选的，为每个桶分配存储范围，具体包括：使用hash算法或crush算法计算每个数据对象的索引值；根据实际桶的数量，将数据对象索引值的范围分配至每个实际桶。

另一方面，本发明提供了一种数据对象存储管理的装置，具体为：包括至少一个处理器和存储器，至少一个处理器和存储器之间通过数据总线连接，存储器存储能被至少一个处理器执行的指令，指令在被处理器执行后，用于完成第一方面中的数据对象存储管理的方法。

与现有技术相比，本发明实施例的有益效果在于：通过虚拟桶聚合多个实际桶，使应用程序无需维护单个实际桶的信息。在本发明的优选方案中，可以通过制定故障处理策略、扩容策略和迁移策略，根据实际桶的存储状态进行自动故障处理、扩容和对象迁移，使上述操作对上层应用透明，，也无需处理每个实际桶的故障处理和扩容。在本发明的另一个优选方案中，将不同类型的数据在同一个虚拟存储桶中进行分离，应用程序通过自定义标签可以进行不同类型数据的存取，提高数据交互的效率。

【附图说明】

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种数据对象存储管理的方法流程图；

图2为现有的数据对象存储管理的存储架构示意图；

图3为本发明实施例提供的一种数据对象存储管理的方法提供的数据对象存储管理的存储架构示意图；

图4为具体实施场景中现有的数据对象存储管理的存储架构示意图；

图5为具体实施场景中本发明实施例提供的一种数据对象存储管理的方法提供的数据对象存储管理的存储架构示意图；

图6为本发明实施例提供的一种数据对象存储管理的方法中实际桶存储范围分布示意图；

图7为本发明实施例提供的一种数据对象存储管理的方法中进行存储容量扩展后实际桶存储范围分布示意图；

图8为本发明实施例提供的一种数据对象存储管理的方法中故障处理的示意图；

图9为本发明实施例提供的一种数据对象存储管理的装置结构示意图。

【具体实施方式】

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

本发明是一种特定功能系统的体系结构，因此在具体实施例中主要说明各结构模组的功能逻辑关系，并不对具体软件和硬件实施方式做限定。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。下面就参考附图和实施例结合来详细说明本发明。

实施例1：

在分布式对象存储使用中，应用程序以bucket的形式对象数据进行管理。但是，每个应用程序可能仅绑定若干个固定的bucket，每个bucket都有容量限制，而且无法直接获取bucket的状态和变化。当数据超出bucket限制、bucket属性变动或bucket发生故障时，应用程序需要通过繁琐的步骤进行处理，或无法及时处理。为了便于应用程序对数据对象进行管理，本实施例中提供了一种数据对象存储管理的方法，使应用程序能够对数据对象进行更灵活方便的管理。

如图1所示，本发明实施例提供的数据对象存储管理的方法具体步骤如下：

步骤101：为每个应用程序建立相应的虚拟桶，配置每个虚拟桶管理的实际桶。

在现有的分布式对象使用中，如图2所示，应用程序直接管理一组实际存在的bucket。在本实施例中，如图3所示，将每个应用程序所管理的一组实际存在的bucket进行整合，由一个虚拟存储桶(virtual bucket)进行管理。本发明实施例中，实际存在的bucket简称为实际桶，虚拟存储桶简称为虚拟桶。具体的，虚拟存储桶可以视为一组实际桶的管理器和路由器。虚拟桶本身并不绑定任何存储池，也不存储任何对象数据和对象索引，仅负责维护所管理的一组实际桶的信息。在实际使用中，实际桶的信息可以包括bucket ID、bucket名称、bucket状态和bucket对象数量等，也可以根据需要包括bucket类型等。bucketID和bucket名称用于关联和查找实际桶，bucket状态用户确认实际桶是否发生故障，bucket对象数量用于判断是否需要进行扩容，bucket类型用于对数据进行分类管理。在实际使用中，上述类型可以根据需要使用一项或多项，也可以根据需要使用实际桶的更多信息。应用程序进行数据访问时，仅访问唯一的虚拟桶即可完成数据存取，而不需要关注虚拟桶所管理的实际桶的数量和状态。

进一步的，在实际使用中，同一个应用程序可能会访问不同位置存储的数据，不同的应用程序也可能会访问同一组数据，因此虚拟桶和实际桶的对应关系可以为一对一、一对多、多对一和多对多。每个虚拟桶可以管理一个或多个实际桶；每个实际桶也可以由一个或多个虚拟桶进行管理。为了保证不同应用程序访问同一个数据对象时不发生访问冲突，可以使用版本管理来确认当前数据是否为需要使用的数据，每个应用程序都仅访问自身修改的数据版本。

步骤102：虚拟桶对管理的每个实际桶进行初始化，根据数据类型配置实际桶的类型，并为每个桶分配存储范围。

在分布式对象存储中，数据对象可能具有不同的数据类型。在实际的底层数据管理中心，不同类型的数据对象可以通过不同的存储池(pool)进行分类管理，同一类型的数据对象也可以使用不同的pool进行数据隔离。在本实施例提供的方法中，每个实际桶都仅存放一种类型的数据对象，仅与一个pool相对应，每个实际桶的类型即其存放的数据对象的类型。在具体实施中，数据对象的类型可以根据数据标签确定，也可以通过其它方式由用户自行定义。若某个数据不包含数据标签或数据类型为止，则为其添加预设的默认数据类型，放入默认数据类型的实际桶中，再根据后续的使用需要进行修改。在实际使用中，根据数据量和使用的具体需要，每个虚拟桶管理的实际桶可以仅有一个类型，也可以有多个类型。

另一方面，由于每个实际桶的存储容量有限，若应用程序需要使用的数据量超过一个实际桶的存储容量，则需要使用多个实际桶进行存储，每个桶的存储容量一般都相同。在实际使用中，存储范围的划分可以根据实际需要进行设定，不超过存储集群系统限定的最大存储容量值即可。为了便于索引的计算和定位，并且使每个桶中的数据量尽可能均等，在本实施例的优选方案中，可以先计算数据对象总存储容量的上下限，再根据实际桶的数量将上下限范围划分为均等且连续的存储范围，将每个存储范围分配至每个实际桶。上述划分过程都由虚拟桶完成，而不需要应用程序的参与。进一步的，由于不同类型的数据需要存放在不同的实际桶中，因此在进行存储范围划分时，需要对每一种不同类型的存储桶分别划分一组存储范围。在具体实施场景中，虚拟桶中包含A类型实际桶3个，B类型实际桶2个，总的存储范围为0-5，进行存储范围划分后，每个A类型实际桶的存储范围分别为{0-1、2-3、4-5}，每个B类型实际桶的存储范围分别为{0-2，3-5}。若数据范围不能完全平均分配，只要保证每个桶可以存储的数据对象数量大致等同即可。

步骤103：虚拟桶根据实际桶的数据类型和存储范围，将数据对象存放在相应的实际桶中。

应用程序进行数据写入时，不直接写入实际桶，而是通过虚拟桶对数据进行写入。应用程序仅需进行数据写入虚拟桶的操作，由虚拟桶查找数据应写入的实际桶，并对数据进行实际的写入操作。由于每个实际桶都包含了数据类型和存储范围两个特征，在进行数据写入时，需要将数据对象放入数据类型和存储范围都匹配的实际桶中。若虚拟桶中仅包含一种数据类型的实际桶，直接根据存储范围定位数据对象需要存放的实际桶，将数据对象写入相应的实际桶中。若虚拟通中包含多种数据类型的实际桶，先根据数据对象的类型确认对应的实际桶的数据类型，再根据存储范围确定对应的实际桶。

步骤104：虚拟桶根据外部数据请求，按照需要访问的数据类型和实际桶的存储范围，与相应的实际桶进行数据交互。

应用程序进行数据读取、更新等交互时，不直接向实际桶提出外部数据请求，而是通过虚拟桶对数据进行间接访问。应用程序仅需向虚拟桶发送外部数据请求，由虚拟桶按照数据请求中需要访问的数据类型和数据对象的标识，匹配实际桶的类型和存储范围，查找数据所在的实际桶，并进行相应的数据交互。

经过步骤101-步骤104，通过在应用程序和实际桶之间增加虚拟桶，使实际桶对应用程序透明，应用程序无需对实际桶进行直接管理，而是简单的使用唯一关联的虚拟桶进行数据写入和数据交互，简化了数据访问操作，减少了应用程序的操作负担。

在实际使用中，可能会出现实际桶出现存储桶实例崩溃等访问异常，或需要访问的数据对象出现访问异常的情况。现有技术中，由于应用程序无法获取实际桶的状态，因此无法即时处理故障，会导致访问错误，出现程序错误或异常。在分布式存储中，对象网关上的实际存储桶信息都保存在底层存储集群上，每个对象网关节点的实际桶分布都是相同的，不同对象网关节点中同名的实际桶中存放的数据对象相同，由分布式存储架构自动进行多个数据副本的数据同步，因此，每个数据对象都会存在多个相同的备份。在本实施例中，虚拟桶查找每一个实际桶在另一个对象网关节点中同名的实际桶，作为实际桶的备份桶。由于虚拟桶与实际桶存在于同一存储层次中，可以获取所管理的每个存储桶的健康状态，当虚拟桶接收到外部数据请求时，首先获取每个实际桶的访问状态，判断实际桶是否可以正常访问。若实际桶出现访问异常，或需要访问的数据对象出现访问异常，虚拟桶将外部数据请求重定向到备份桶上，由备份桶中获取需要访问的数据对象，以此来保证存储桶故障对应用程序的透明性。应用程序在进行数据交互时，由虚拟桶对实际桶的访问状态进行确认，并对出现访问异常的实际桶进行故障重定位，避免了由应用程序获得返回的异常后再次发送异常处理请求，保证了应用程序的每次访问都能够获取到需要的数据，减小了应用程序的异常处理开支，以及进行异常处理的时间消耗。

由于每个实际桶的存储数量都存在上限，在实际桶中的数据对象数量接近上限时，还需要对虚拟桶进行扩容。具体的，可以根据需要，设置接近上限的预设数量阈值，若实际桶中数据对象的数量超过预定数量阈值，则建立新的实际桶，将新建实际桶分配至原实际桶所在的虚拟桶中。再根据新建实际桶的数量，重新计算虚拟桶中每个实际桶的存储范围。重新计算存储范围后，会导致虚拟存储桶中相同类型实际桶的存储范围发生变化，因此，还需要根据重新计算的存储范围，将原实际桶中的数据对象迁移入对应的实际桶中。

为了减少数据迁移的时间消耗，使数据迁移不会影响到应用程序对数据的使用，虚拟桶需要针对迁移前后存入的数据保存新旧两套存储范围分布。当存入新的数据对象时，直接按照重新计算后的实际桶的存储范围，将数据对象存入对应的实际桶中。当读取文件时，由于不确定数据对象是否迁移完成，需要同时向原实际桶的存储范围所定位的实际桶和重新计算后的实际桶的存储范围所定位的实际桶发起读请求，以避免因存储范围不一致而导致的数据对象定位错误。

为了进一步避免数据迁移影响数据访问的效率和准确度，虚拟桶根据预设的迁移策略，在对比新旧存储范围分布的基础上进行对象迁移，直至虚拟存储桶中的对象完全按照新的存储范围进行分布，此时则可以删除旧的存储范围分布。预设的迁移策略可以为在业务空闲时段迁移，在每个未迁移的数据被访问后迁移等，具体由用户根据实际业务需要进行设置。例如，在某个具体实施场景中，可以在业务空闲时段，查找每个实际桶中不属于重新计算后的存储范围的数据对象，并将查找到的数据对象迁移至重新计算后的存储范围对应的实际桶中。当实际桶中所有的数据对象都按照重新计算后的存储范围分布后，即可删除旧的存储范围，在读取文件时，仅向重新计算后的存储范围所定位的实际桶发起读请求。

为了对不同类型的数据对象进行分类存储，通过分类提高访问效率，每个实际桶中都仅保存与桶类型对应的数据对象。在进行数据交互时，为了对数据对象存储的实际桶进行定位，不仅要依据存储范围，还要依据数据对象的类型，数据对象和实际桶需要存储范围和数据对象类型都匹配。在优选方案中，可以先判断虚拟桶中所有的实际桶的数据类型是否相同。若所有实际桶的数据类型都相同，直接计算数据对象所在的存储范围，访问存储范围对应的实际桶。若不同，先计算数据对象所在的存储范围，再访问每一个数据类型中存储范围对应的实际桶。在实际使用中，数据类型由应用程序根据需要自行定义，并使用文件标签的形式传递至虚拟桶。若数据对象未携带标签，可以将其视为预设的默认数据类型。先对虚拟桶中所有实际桶的类型进行判断，在虚拟桶中只有一个实际桶时，可以省略数据类型判断的步骤，仅向存储范围对应的实际桶发出读指令，提高了访问效率。在实际使用中，实际桶类型的判断在没有新增实际桶的情况下只需进行一次，当新增实际桶时再次进行判断。

在具体使用中，数据类型可能会发生变化，例如，数据类型为冷数据和热数据时，由于应用程序不同阶段对同一个数据对象的访问频率不同，冷数据可能由于访问频繁变为热数据，热数据也可能由于访问次数减少变为冷数据，此时，就需要根据数据类型的变化将数据对象迁移至新数据类型对应的实际桶中。若冷数据变为热数据，则将冷数据由冷数据对应类型的实际桶迁移至存储范围相同的热数据对应类型的实际桶中；若热数据变为冷数据，则将热数据由热数据对应类型的实际桶迁移至存储范围相同的冷数据对应类型的实际桶中。由于数据类型变化前后，数据对象对应的存储范围未变化，因此无法使用重新计算存储范围对应的实际桶来进行重定位，将数据对象迁移至新数据类型对应的实际桶中之后，还需要在旧的存储位置为数据对象生成相应的重定向索引。在接收到数据对象的访问请求时，根据重定向索引查找数据对象新的存储位置。

在分布式存储的实际应用中，每个实际桶都绑定一个pool，pool是分布式节点，使用crush分布的情况下，每个实际桶中的数据分布在一个pool中所有磁盘上；使用hash分布的情况下，每个实际桶中的数据分布在固定磁盘上。数据的具体分布方式也可以使用其它的扩展算法，具体由存储集群的管理系统确定。与pool中的存储地址对应，本实施例提供的数据对象存储管理的方法，对数据对象的文件名使用hash算法或crush算法获取索引值，作为数据对象的存储地址。相应的，每个实际桶的存储范围就是一段连续的索引值数字范围。为每个实际桶分配存储范围时，首先使用hash算法或crush算法计算每个数据对象的索引值。再根据实际桶的数量，将数据对象索引值的范围平均分配至每个实际桶中。若数据范围不能完全平均分配，只要保证每个桶可以存储的数据对象数量大致等同即可。

本实施例提供的数据对象存储管理的方法，在实际桶的基础上增加了虚拟桶，通过虚拟桶对数据存取、故障处理和数据扩容进行管理，使得上层应用程序从此无需维护存储桶信息，只需要和虚拟存储桶进行交互，从而提高了数据访问的便捷性、访问效率和访问安全性。

实施例2：

基于实施例1提供的数据对象存储管理的方法，本实施例提供了一个具体使用场景中通过该方法进行数据对象存储管理的实例。

本场景中存在两个应用程序APP01和APP02。在现有技术中，如图4所示，APP01管理bucket01和bucket02，APP02管理bucket03、bucket04、bucket05和bucket06。其中，bucket01、bucket02、bucket03和bucket04绑定SSD pool，bucket05和bucket06绑定HDDpool。每个应用程序都需要管理多个bucket，管理过程较为繁琐，并且无法直接获取到bucket的运行状态。在任一个bucket的存储容量到达上限时，还需要APP自行增加新的bucket并进行数据迁移。

如图5所示，根据步骤101，为每个应用程序APP建立一个虚拟桶vbucket，APP01对应vbucket01，APP02对应vbucket02。并为将应用程序需要使用的实际桶分配至相应的虚拟桶，vbucket01管理bucket01和bucket02，vbucket02管理bucket03、bucket04、bucket05和bucket06。

根据步骤102，虚拟桶获取下层每个bucket的bucket ID、bucket名称,bucket状态和bucket类型。进一步的，还需要根据应用程序的数据类型为每个实际桶设置类型，实际桶的类型可以由bucket类型进行记录。在存储集群层，包含SSD pool和HDD pool，应用程序需要经常读写的热数据(hot-data)放入SSD pool中，使用固态硬盘(Solid State Disk，简写为SSD)存储，以提高数据读写速度；应用程序不经常读写的冷数据(cold-data)放入HDDpool中，由硬盘驱动器(Hard Disk Drive，简写为HDD)存储，以降低存储大量数据的成本。在本实施例中，bucket类型与其所绑定的池类型相对应，分别为SSD类型和HDD类型。

为每个实际桶设置类型后，还需要为每个实际桶设置存储范围。在本实施例中，使用数据对象文件名的hash值作为存储的索引，存储范围即Hash值的范围，需要把一段连续的数字范围平均分到同一个虚拟桶内相同类型的实际桶上。若数据范围不能完全平均分配，只要保证每个桶可以存储的数据对象数量大致等同即可。在使用crush算法的场景中，根据crush索引的范围进行存储范围划分。在本实施例中，数据对象索引值的存储空间大小为1byte，索引hash值的最大取值范围为0-127。对于vbucket01，仅有1种类型的实际桶，因此直接将该范围分配到2个实际桶上，如图6所示，bucket01的存储范围是0-63，bucket02的存储范围是64-127。对于vbucket02，有2种类型的实际桶，因此需要分别为2中类型的实际桶设置存储范围，将该范围分配到每个类型相同的实际桶上，bucket03的存储范围是0-63，bucket04的存储范围是64-127，bucket05的存储范围是0-63，bucket06的存储范围是64-127。

初始化完成后，即可根据步骤103进行数据写入。对于应用程序，仅需将对象数据发送至虚拟桶，具体的写入步骤由虚拟桶执行。对于APP01，仅存在一种类型的实际桶，则收到数据对象时，虚拟桶首先根据文件名计算出一个hash值，然后根据所管理的实际桶的hash范围，将该文件放入hash值所在范围的实际桶中。例如，文件名“abc.jpg”的hash值为32，属于bucket01的存储范围，因此将“abc.jpg”写入bucket01中。对于APP02，虚拟存桶所管理的实际桶类型不相同，vbucket02管理的bucket03和bucket04为SSD类型，存储hot-data类型的数据，bucket05和bucket06为HDD类型，存储cold-data类型的数据。应用程序所存文件带有冷热数据标签，如hot-data和cold-data，则收到文件时，首先判断文件的冷热数据标签，以vbucket02为例，先根据文件名计算出一个hash值，如果是hot-data，将该文件放入SSD类型的hash值所在范围的实际桶中；如果是cold-data，将该文件放入HDD类型的hash值所在范围的实际桶中。例如，“def.txt”的标签为cold-data，需要放入HDD类型的bucket05或bucket06中，hash值为100，属于bucket06的存储范围，因此放入bucket06中。在实际使用中，也可能遇到没有带标签的数据对象，在本实施例中默认按照冷数据处理。若数据类型发生改变，还需要将数据对象迁移至改变后类型对应的桶中，若“def.txt”的标签变化为hot-data，则需要将该数据对象由HDD类型的bucket06中，迁移至SSD类型的相同存储范围的bucket04中，并生成相应的重定向索引以便于访问时进行查找。

根据步骤104，应用程序通过简单存储服务协议指定虚拟桶从对象存储中读取文件时，仅需向虚拟桶发出读取请求，而无需关注具体的存储位置和存储类型。虚拟桶的处理和写入文件类似，也分为两种情况。对于APP01，虚拟存桶所管理的实际桶类型相同，则根据文件名计算出的hash值，去所在hash范围的实际桶读取文件内容。对于APP02，虚拟桶所管理的实际桶类型不相同，则首先根据文件名计算出的hash值，根据hash值所在hash范围同时向不同类型的实际桶发起读请求，或根据hash值和数据类型对相应的实际桶发起读请求。

当实际桶中对象数量接近上限时，虚拟桶需要进行扩容和数据迁移，如图7所示，为APP01扩容和数据迁移后的实际桶分布和每个实际桶的存储范围。在vbucket01中新增一个实际桶bucket07，将原bucket01和bucket02中的数据大致均等的分配至3个实际桶中，重新计算的存储范围为0-42,43-85，86-127。扩展后，若需读取原索引为105的数据对象，根据旧存储范围定位的实际桶为bucket02，根据新存储范围定位的实际桶为bucket07，需要同时对两个实际桶发出读请求，以确保无论该数据对象是否完成迁移，都可以正确读取。若未进行迁移，还需要在迁移策略允许的时候将该数据从bucket02迁移至bucket07。在此过程中APP01仅需向vbucket01发出“读取索引为105的数据对象”的外部数据请求，而无需获知数据对象的具体存储位置。

如图8所示，当bucket01发生访问故障时，vbucket01自动获取bucket01的状态，并获取另一个对象网关节点上的bucket01作为备用桶。当vbucket01接收到APP01发送的外部数据请求时，将外部数据请求直接重定向到备用桶上，通过备用桶获取需读取的数据对象。在此过程汇总，APP01仅需向vbucket01发送读取请求，而无需进行bucket01的状态确认，以及相应的故障处理步骤。

通过本实施例提供的具体实例，可以看出，使用虚拟桶对实际桶进行管理，可以聚合多个实际桶，使应用程序无需对每一个实际桶的信息和状态进行管理维护。将不同类型的数据对象在同一个虚拟存储桶中进行分离，应用程序通过自定义标签可以进行不同类型数据对象的存取。通过制定扩容策略和迁移策略，可以根据下层实际桶状态进行自动扩容、对象迁移和故障处理，使得上层应用程序对于数据存储的变化无感知。

实施例3：

在上述实施例1至实施例2提供的数据对象存储管理的方法的基础上，本发明还提供了一种可用于实现上述方法的数据对象存储管理的装置，如图9所示，是本发明实施例的装置架构示意图。本实施例的数据对象存储管理的装置包括一个或多个处理器21以及存储器22。其中，图9中以一个处理器21为例。

处理器21和存储器22可以通过总线或者其他方式连接，图9中以通过总线连接为例。

存储器22作为一种数据对象存储管理方法非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如实施例1至实施例2中的数据对象存储管理方法。处理器21通过运行存储在存储器22中的非易失性软件程序、指令以及模块，从而执行数据对象存储管理的装置的各种功能应用以及数据处理，即实现实施例1至实施例2的数据对象存储管理的方法。

存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

程序指令/模块存储在存储器22中，当被一个或者多个处理器21执行时，执行上述实施例1至实施例2中的数据对象存储管理的方法，例如，执行以上描述的图1所示的各个步骤。

本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(Read Only Memory，简写为：ROM)、随机存取存储器(Random AccessMemory，简写为：RAM)、磁盘或光盘等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种数据对象存储管理的方法，其特征在于：

为每个应用程序建立相应的虚拟桶，配置每个虚拟桶管理的实际桶；

虚拟桶对管理的每个实际桶进行初始化，根据数据类型配置实际桶的类型，并为每个桶分配存储范围；

虚拟桶根据实际桶的数据类型和存储范围，将数据对象存放在相应的实际桶中；

虚拟桶根据外部数据请求，按照需要访问的数据类型和每个实际桶的存储范围，与相应的实际桶进行数据交互。

2.根据权利要求1所述的数据对象存储管理的方法，其特征在于，所述与相应的实际桶进行数据交互，还包括：

虚拟桶查找每一个实际桶在另一个对象网关节点中同名的实际桶，作为实际桶的备份桶；

当虚拟桶接收到外部数据请求时，获取每个实际桶的访问状态；

若实际桶出现访问异常，或需要访问的数据对象出现访问异常，虚拟桶将外部数据请求重定向到备份桶上。

3.根据权利要求1所述的数据对象存储管理的方法，其特征在于，若实际桶中数据对象的数量超过预定数量阈值，还包括：

建立新的实际桶，将新建实际桶分配至原实际桶所在的虚拟桶中；

根据新建实际桶的数量，重新计算虚拟桶中每个实际桶的存储范围；

根据重新计算的存储范围，将原实际桶中的数据对象迁移入对应的实际桶中。

4.根据权利要求3所述的数据对象存储管理的方法，其特征在于，所述将原实际桶中的数据对象迁移入对应的实际桶中，具体包括：

获取每个原实际桶的存储范围和每个新实际桶的存储范围；

当存入新的数据对象时，按照重新计算后的实际桶的存储范围，将数据对象存入对应的实际桶中；

当读取文件时，同时向原实际桶的存储范围所定位的实际桶和重新计算后的实际桶的存储范围所定位的实际桶发起读请求。

5.根据权利要求4所述的数据对象存储管理的方法，其特征在于，所述将原实际桶中的数据对象迁移入对应的实际桶中，还包括：

根据预设的迁移策略，查找每个实际桶中不属于重新计算后的存储范围的数据对象，并将查找到的数据对象迁移至重新计算后的存储范围对应的实际桶中；

当实际桶中所有的数据对象都按照重新计算后的存储范围分布后，在读取文件时，仅向重新计算后的存储范围所定位的实际桶发起读请求。

6.根据权利要求1所述的数据对象存储管理的方法，其特征在于，所述配置每个虚拟桶管理的实际桶，具体包括：

每个虚拟桶管理一个或多个实际桶；

每个实际桶由一个或多个虚拟桶进行管理。

7.根据权利要求1所述的数据对象存储管理的方法，其特征在于，所述与相应的实际桶进行数据交互，还包括：

判断虚拟桶中所有的实际桶的数据类型是否相同；

若相同，直接计算数据对象所在的存储范围，访问存储范围对应的实际桶；

若不同，先计算数据对象所在的存储范围，再访问每一个数据类型中存储范围对应的实际桶。

8.根据权利要求7所述的数据对象存储管理的方法，其特征在于，所述将数据对象存放在相应的实际桶中，还包括：

若数据对象的数据类型发生变化，将数据对象迁移至新数据类型对应的实际桶中，并生成相应的重定向索引。

9.根据权利要求1所述的数据对象存储管理的方法，其特征在于，所述为每个桶分配存储范围，具体包括：

使用hash算法或crush算法计算每个数据对象的索引值；

根据实际桶的数量，将数据对象索引值的范围分配至每个实际桶。

10.一种数据对象存储管理的装置，其特征在于：

包括至少一个处理器和存储器，所述至少一个处理器和存储器之间通过数据总线连接，所述存储器存储能被所述至少一个处理器执行的指令，所述指令在被所述处理器执行后，用于完成权利要求1-9中任一项所述的数据对象存储管理的方法。

Images