可缩放的容错元数据服务制造技术

元数据可以被存储在可缩放的容错元数据服务中，并可从中检索。在一个示例中，元数据被分为各个分区，且每一分区由一个或多个节点来服务。对于每一分区，节点中的第一个可以处理读和写请求，而其它节点可以在第一节点故障或经历高负载时处理读请求。当相对于元数据作出请求时，元数据服务器可在该元数据被分配给的分区中标识要对其作出该请求的节点。作出请求的实体接着联系那个节点，并请求对元数据的读或写。在一分区中，元数据可以在第一节点和其它节点之间使用基于日志的复制协议来复制。

【技术实现步骤摘要】
可缩放的容错元数据服务
技术介绍
元数据常常被描述为“关于数据的数据”。元数据可以采取各种形式，其范围从简单到复杂。在一个简单的示例中，计算机文件与元数据相关联，其可包括文件的名称和类型、创建和最近修改的日期、访问许可等等。在更复杂的示例中，数据遵循复杂多层的结构， 其中，元数据可以包括定义数据的结构的模式。看待元数据的一种方式是它仅仅是一种数据。然而，在实践中，对元数据的管理提出了与对与该元数据相关的底层数据的管理稍微不同的问题。元数据可能比底层数据被更频繁地访问。此外，元数据的访问失败可以被视为相比普通数据的访问失败更不能接受。
技术实现思路
可以通过考虑应用于元数据的可靠性以及吞吐量约束的系统来管理元数据。此外，该系统可以是可缩放的，以便满足涉及要存储的元数据的量以及使用元数据的速率的任意条件。元数据可以被划分成各个分区。每个分区被分配给节点或节点的集合。每个节点是对针对元数据的访问请求进行响应的服务器。对分区进行服务的节点可以包括主节点且可任选地包括一个或多个次节点。主节点维持该分区的当前真实版本。次节点包含该分区的副本。读元数据的请求也可以被定向至主节点。读元数据的请求也可以被定向至主节点。然而，如果对系统的要求使得使用附加节点来对元数据请求进行服务是有意义的，则某些读请求可以被定向至次节点，从而减轻主节点的一些压力。分区本身可以被以使得这些分区中的每一个上的负载大致相等的方式来划分。在一个示例中，平衡负载意味着各分区包含大致相等量的元数据。然而，对不同类型的元数据的要求可以是不同的，以便使得可以通过将少量高要求元数据分配到一个分区并将大量低要求元数据分配到另一个分区来平衡跨各分区的负载。本文的主题允许动态的负载平衡， 这取决于元数据正在被如何使用。当实体提交访问元数据的请求时，该实体将该请求提交到元数据服务器。然后，该元数据服务器标识发起请求的实体向其提交该请求的适当节点。通常，向其提交请求的节点是分区的处理所请求的元数据的主节点，但在某些情形中该节点可以是次节点之一。然后，发起请求的实体从由元数据服务器标识的节点请求元数据。分区中的元数据可以通过基于日志的复制协议来更新。在这样的协议中，对元数据的当前状态的任何改变(即，增加新元数据记录的写或修改现有元数据记录的写)被定向至负责分区的主节点。在对主节点进行写之后的某一时刻，该主节点将该写发送给次节点，以使得次节点将会具有该新信息。然而，次节点可以继续提供旧信息，直到新信息已经被提交为止。各节点中的每一个维持一个日志，其中日志的末尾指示哪个是当前版本的任何数据。当主节点提交该新数据时，它将该提交输入到其日志中。然后，主节点通知次节点， 次节点通过将该提交输入它们各自的日志中来提交该数据。然后，主节点和次节点开始提供新数据而不是旧数据。提供本
技术实现思路
是为了以简化的形式介绍将在以下详细描述中进一步描述的一些概念。本
技术实现思路
并不旨在标识出所要求保护的主题的关键特征或必要特征，也不旨在用于限定所要求保护的主题的范围。附图说明图1是可以对关于元数据的请求进行响应的示例系统的框图。图2是其中可以将元数据存储在元数据系统中的示例过程的流程图。图3是示例的基于日志的复制方案的框图。图4是访问元数据的示例过程的流程图。图5是其中使用元数据来构建索引的示例场景的框图。图6是实现可以在为一分区进行服务的各节点之间划分工作的一种示例方式的过程的流程图。图7是在节点故障的情况下为分区获取新节点的示例过程的框图。图8是分割分区以适应该分区的增长的示例过程的框图。图9是可以结合本文描述的主题的实现来使用的示例组件的框图。具体实施例方式元数据通常被描述为“关于数据的数据”。存在各种类型的元数据。例如，在计算机文件系统中，每个文件与指示该文件的名称和类型、创建日期、最后修改日期、访问许可等等的元数据关联。关于文件的这一类型的信息是相对简单类型的元数据。其他类型的元数据更为复杂。例如，数据可以被组织成多层结构，其中该结构由模式来描述。当数据被以此方式组织时，该数据仅可以在元数据的帮助下来解释。因此，使用这种类型的复杂的结构化数据的系统通常访问元数据以解释该元数据所描述的底层数据。看待元数据的一种方式是其仅仅是可以像其他数据那样被管理的特定类型的数据。然而，在实践中，对元数据的管理提出了稍微不同于对与该元数据相关的底层数据的管理的问题。元数据可能比底层数据被更频繁地访问。而且，访问失败的后果更为严重。例如，底层数据的消费者可能具有该底层数据的私有副本，但是在不访问元数据的情况下可能不能够解释该数据。或者，除非实体有权访问元数据，否则该实体可能尝试创建符合该元数据所定义的模式的数据但因此不能够以正确的形式创建该数据。因此，对元数据的吞吐量和容错约束两者都高于对普通数据的吞吐量和容错约束。为了提供对元数据的访问，可以创建可缩放的容错元数据管理系统。这样的元数据管理系统可以将元数据正文划分成各个分区。将元数据划分成各个分区允许不同服务器群提供不同的元数据。特定分区可以被以这样的方式被分配给特定的服务器群对于该分区的预期请求量是在服务于这些请求的群的能力之内。分区是可缩放的，因此，如果元数据的量增加——或者如果对于元数据的预期请求速率增加——则元数据能被划分成大量的分区，并且然后可以跨大量服务器来重新分配。对元数据的每一分区进行服务的服务器群可以包含一个主节点和一组次节点。主节点可以服务于写请求。此外，当分区上负载低时，主节点可以服务于读请求。如果分区上的负载增大至超过一个节点有效地服务于读请求的能力，则读请求可以被定向至次节点之一。次节点包含被存储在主节点上的元数据的副本，且允许元数据管理系统缩放以适应较高负载的时期。当实体做出对元数据的请求(读请求或写请求)时，该实体将这些请求提交给元数据服务器。元数据服务器知道元数据被如何分割，而且因而能够标识持有所请求的元数据的服务器。在一个示例中，可以通过基于该请求所涉及的元数据的某种函数标识特定分区的散列函数来分割元数据。然而，分区可以用任何方式实现。当元数据服务器标识分区时，它可以在节点组之中标识服务于该分区的特定节点。如上所述，正常地，请求被路由到服务于分区的主节点，但在高负载期间特定请求可以被路由到次节点。当标识了节点时，服务器将该节点的身份返回给发起请求的实体。然后，发起请求的实体将其请求提交给该所标识的节点。然后，该节点对请求作出响应。在主节点和次节点之间的元数据复制可以通过基于日志的复制协议来管理。在一个示例中，当分区的主节点接收到写请求时，它把新近写的数据复制到该分区的次节点。在复制了数据之后，次节点拥有该新数据。然而，这时，新数据可能不是该节点所提供的数据版本。节点可以继续提供该数据的先前版本，直到主节点提交该数据的新版本为止。哪一版本构成元数据的当前版本的问题可以通过提交日志来管理，其中一元数据项的当前版本由应用于该元数据项的最后一个日志条目确定。因此，在主节点已经接收到(诸)次节点已经接收到所复制的数据的确认后，主节点可以通过将该提交输入到该主节点的提交日志中来提交该复制的数据。然后，主节点将该提交传送到(诸)次节点，(诸)次节点将该提交输入到它们的提交日志并开始提供该新数据来替换旧数据。在一个示例中，元数据服务用来本文档来自技高网...

【技术保护点】
１．一种用于处理元数据的方法，所述方法包括：从实体（１０２）接收（４０２）关于元数据（５１２）项的请求（１０４）；标识（４０４）存储所述元数据（５１２）项的分区（１０８），其中元数据的正文被划分成第一多个分区（１０８，１１０，１１２），所述分区（１０８）是所述第一多个分区（１０８，１１０，１１２）之一；向所述实体（１０２）提供（４０６）为所述分区（１０８）处理请求的节点（１１６）的身份；在所述节点（１１６）处接收来自所述实体（１０２）的所述请求（１０４）；以及根据所述请求（１０４）读或写（４０８）所述元数据（５１２）项。

【技术特征摘要】
...

【专利技术属性】
技术研发人员：N·曾，M·叶，冯宏华，J·许，Y·曹，Y·余，宋霖，
申请(专利权)人：微软公司，
类型：发明
国别省市：US