CN103544300B - 一种云环境下可扩展存储索引结构的实现方法 - Google Patents

Abstract

本发明公开了一种云环境下可扩展存储索引结构的实现方法，利用Skiplist这种数据结构来有针对性地构建云环境下可扩展存储索引结构，使得数据子集、数据都是有序存储的，这样知道待查询键的区间上下界就可以实现范围的查询。同时，上层的全局索引结点由下层结点的元数据构成，减轻了上层全局索引的内存开销，并可以存储更多的全局索引结点，大大提高了整个云存储***的查询速度，实时性得到提高。此外，本发明中的存储索引结构可以进行动态调整，具有很好的扩展性。

Description

一种云环境下可扩展存储索引结构的实现方法

技术领域

本发明属于云存储技术领域，更为具体地讲，涉及一种云环境下可扩展存储索引结构的实现方法。

背景技术

随着计算机及网络技术的发展，云计算技术作为一种高性能、低成本的实用分布式计算技术，已被广泛运用于以大数据处理为代表的各种网络应用中。高可扩展性和可靠性的云存储***逐渐成为大数据处理的首选方案之一，已有的优秀云存储***包括：Google的GFS、MapReduce以及其开源实现Hadoop、亚马逊的Dynamo和Facebook的Cassandra等。相对于传统数据存储***，云存储***分布更广，支持数据更多，这就意味着云存储时代的辅助索引***必然发生大的变化。

当前大多数的云存储***都采用健-值（Key-Value）模型,将查询的键（key）和具体值（value）映射为键值对（kv-pair）来存取数据。该模型简单，适合通过主键进行查询。在单键查询的时候有着良好的表现，但却不能有效支持范围查询。实际的应用效果表明，这类基于Key-Value模型的云存储***还存在一些亟待提高的地方。例如，对于一个在线视频点播***来说，用户们往往倾向于采用多于一个的键值来进行查询，或需要查询特定属性处于某一个数据范围之内的视频信息。为了满足上述的应用需求，当前的解决方案主要是通过运行一个后台批处理任务（例如运行一个MapReduce的任务），来扫描整个数据集然后得到查询结果。然而，这类解决方案缺乏时效性，新存入的数据不能被及时的查询到，必须等到后台的批处理任务完成了完整的扫描，数据才会可查。上述分析表明，当前云存储***在多维度查询和范围查询方面支持的都不是很理想、且时效性差，有必要构建云环境下存储索引结构。

目前少数基于不同数据结构的双层存储索引结构已经被提出。这些方案能够很方便地实现云存储***的可扩展性，使云存储***能够同时支持大规模的查询。但是，这些方案在全局索引中大都采用了基于P2P协议的覆盖网络来实现并行查询，但是P2P网络本身的维护比较复杂，查询时的网络开销也比较大，这会影响到云存储***的查询性能。同时，由于现有的云存储***一般都是master-slave结构的，要在这些节点上重新构建一个P2P网络，会对原有的存储***带来一定的负面影响。

发明内容

本发明的目的在于克服现有技术的不足，提供一种云环境下可扩展存储索引结构的实现方法，以解决云存储***中存储索引结构不支持范围查询以及缺乏实时性的问题。

为实现上述发明目的，本发明云环境下可扩展存储索引结构的实现方法，其特征在于，包括以下步骤：

（1）、建立主从式的可扩展存储索引的两层结构

整个存储索引结构分为上下两层，上层为全局索引，由全局索引服务器负责管理，下层为多个局部索引，每个局部索引由一个局部索引服务器负责管理；

对待索引的数据集进行切分，按照平均的原则，分成包含等量数据的数据子集，划分的数据子集的个数与局部索引服务器相等；然后，划分好的数据子集与下层索引服务器一一对应，并在各下层索引服务器中以SkipList为基础建立局部索引，下层索引服务器将数据子集的各个数据分别存放到局部索引的各个结点中，完成局部索引的建立；

在局部索引建立完成的基础上，各局部索引挑选桩结点作为自己索引范围的“代表”发布到上层的全局索引中；发布时，抽取发布的桩结点的元数据发送到上层的全局索引服务器中，元数据包括：索引的键，局部索引服务器IP地址，局部索引服务器磁盘物理块号，以达到减轻上层索引的内存开销和存储更多结点的目的；全局索引服务器接收到下层各局部索引发布的元数据后，通过SkipList的形式将这些元数据作为全局索引结点组织成一个全局索引，在逻辑上将下层各独立的局部索引关联起来，维持了索引空间的整体一致性；

（2）、发布元数据结点的调整

局部索引向全局索引发布桩结点的元数据进行关联后，各局部索引会根据预估的收益，判断是否要继续往局部索引的下一层级进行发布：

如果往局部索引的下一层级进行发布，云存储***的查询速度变化率为正向，并且大于全局索引服务器的内存占用变化率，则将局部索引的下一层级结点的元数据发布到上层的全局索引中，否则，不往下一层级进行发布；

（3）、查询

3.1）、单键值查询

a1、由上层的全局索引服务器作为处理查询的入口，首先，在全局索引中查询到待查询键的全局索引结点；a2、根据全局索引中查询到的全局索引结点，定位到下层具体的某一个局部索引服务器上，将查询操作转移给该局部索引服务器继续处理；a3、局部索引服务器执行查询操作，查询本机负责的局部索引，找到待查键对应的数据后，直接返回给查询请求发起端；

3.2）、范围查询

b1、按照单键值查询的方式，以待查询键的区间的下界为键，找到具体某一个局部索引中对应的结点；b2、找到的结点为起点，顺序向后遍历并缓存查询到的数据，直到找到待查询键的区间的上界为止，然后将所有找到的数据返回给查询请求发起端。

本发明的发明目的是这样实现的：

本发明云环境下可扩展存储索引结构的实现方法，利用Skiplist这种数据结构来有针对性地构建云环境下可扩展存储索引结构，使得数据子集、数据都是有序存储的，这样知道待查询键的区间上下界就可以实现范围的查询。同时，上层的全局索引结点由下层结点的元数据构成，减轻了上层全局索引的内存开销，并可以存储更多的全局索引结点，大大提高了整个云存储***的查询速度，实时性得到提高。此外，本发明中的存储索引结构可以进行动态调整，具有很好的扩展性。

附图说明

图1是本发明中可扩展存储索引的两层结构示意图；

图2是本发明中发布元数据结点的调整示意图；

图3是局部索引发布到全局索引时加速系数和内存的变化情况；

图4是单键值查询的处理过程示意图；

图5是局部索引***示意图；

图6是可扩展索引结构的构造示意图；

图7是范围查询处理流程示意图；

图8是局部索引***示意图。

具体实施方式

下面结合附图对本发明的具体实施方式进行描述，以便本领域的技术人员更好地理解本发明。需要特别提醒注意的是，在以下的描述中，当已知功能和设计的详细描述也许会淡化本发明的主要内容时，这些描述在这里将被忽略。

实施例

图1是本发明中可扩展存储索引的两层结构示意图。

在本实施例中，如图1所示，建立主从式的可扩展存储索引的两层结构的过程为：

整个存储索引结构分为上下两层，下层为多个局部索引，每个局部索引由一个局部索引服务器负责管理，索引的数据存放在下层的局部索引结点中，而上层的全局索引则起到一个定位和导向的作用，由全局索引服务器负责管理。

在存储索引建立的时候，首先会对待索引的数据集进行切分，按照平均的原则，分成包含等量数据的数据子集，划分的数据子集的个数与下层的局部索引服务器相等。然后，划分好的数据子集与下层索引服务器一一对应，在各下层索引服务器中以SkipList为基础建立局部索引，下层索引服务器将数据子集的各个数据分别存放到局部索引的各个结点中，完成局部索引的建立。

在局部索引建立完成的基础上，各局部索引挑选桩结点作为自己索引范围的“代表”发布到上层的全局索引中，其中，必须包括局部索引中的桩结点，即图1中的黑色圆圈部分。发布时，并不是直接将下层局部索引中结点原封不动的拷贝给上层全局索引作为结点，而是抽取这些被发布结点的元数据，包括：索引的键，局部索引服务器IP地址，局部索引服务器磁盘物理块号，仅将元数据发送到上层全局索引服务器中，可以达到减轻上层全局索引的内存开销和存储更多结点的目的。全局索引服务器接收到下层各局部索引发布的元数据后，通过SkipList的形式将这些元数据作为全局索引结点组织成一个全局索引，在逻辑上将下层各独立的局部索引关联起来，维持了索引空间的整体一致性。

图2是本发明中发布元数据结点的调整示意图；

局部索引向全局索引发布桩结点的元数据进行关联后，各局部索引会根据预估的收益，判断是否要继续往局部索引的下一层级进行发布：

如果往局部索引的下一层级进行发布，云存储***的查询速度变化率为正向，并且大于全局索引服务器的内存占用变换率，则将局部索引的下一层级结点的元数据发布到上层的全局索引中，否则，不往下一层级进行发布。

在本实施例中，如图2所述，本发明引入动态发布调整算法，下层的局部索引根据预估的收益对下一层级即L2（L3层级为当前发布的层级）进行判断，看是否需要进行发布，下一层级L2的收益即云存储***的查询速度变化率为正向，并且大于全局索引服务器的内存占用变化率，因此，将L2层级的结点的元数据发布到上层的全局索引中。

本发明中的索引存储结构采用下层的局部索引向上层的全局索引发布结点的元数据，在上层的全局索引服务器中构建全局索引，来维护索引结构的整体性。在下层的局部索引发布向上层的全局索引发布结点的元数据时，采用的是自顶向下的方式逐步增加发布的结点的元数据。首先，每一个局部索引将最高层级（图2中的L4层级）结点的元数据发布到全局索引中，SkipList的特性保证了最高层的结点必然包括桩结点，接着各局部索引会根据预估的收益，判断是否要继续往下一层级发布。

预估的策略根据的是局部索引发布之后，整体索引结构即云存储***的查询速度变化率和全局服务器的内存变化率为基准。图2给出了一个局部索引发布的结点从L3层级向L2层级延伸时，上层全局索引中结点变化的情况。因为SkipList本身的特性，下一层级的结点总是包含着上一层级的结点，所以在向下一层级扩展发布的时候，仅需要将之前没有包含的新结点的元数据发送给上层的全局索引，即仅在全局索引中***之前没有的结点的元数据。

对于SkipList来说，其索引的数据是存储于最底层的结点中，同时各结点以p的概率向上升高，升高的部分作为查询的加速结点使用。因此，在SkipList中自顶向下结点的数量将会以幂级的形式增加。与下层局部索引发布的结点数量相对应，上层全局索引的内存开销也将以幂级的形式增加。基于这个原因，下层局部索引不能不加限制的向上层发布结点的元数据，应以索引结构即云存储***整体的查询速度和内存开销的综合值作为发布的判断依据。

图3是局部索引发布到全局索引后，索引结构整体的查询速度以及全局索引服务器内存占用情况的示意图。从图3可以看出，随着发布层数的增加，索引结构整体的查询速度提升趋势逐渐变缓，而全局索引服务器的内存占用即开销则明显升高。因此，本发明在发布时会根据查询速度和内存占用的变化情况作为判断，设定一个阈值，作为发布层数的最大上界。具体方法为：设Q_old为局部索引发布下一层结点元数据之前，索引结构整体的查询速度。Q_new为局部索引发布下一层结点数据之后，预估的索引结构整体的查询速度。假定将局部索引发布到下一层，则发布之后的索引结构整体查询速度变化率为：

$A_{\mathrm{query}}=\frac{Q_{\mathrm{new}}-Q_{\mathrm{old}}}{Q_{\mathrm{old}}}$

与索引结构整体查询速度变化率为A_query的定义方法相同，定义全局服务器内存占用变化率为A_{men_load}。则下层的局部索引向上层的全局索引发布结点元数据的阈值定义如下：

本发明中存储索引采用了两层结构，在处理一个典型的单键值查询操作时，如图4所示，包括3个步骤：a1、由上层的全局索引服务器作为处理查询的入口，首先，在全局索引中查询到待查询键的全局索引结点；a2、根据全局索引中查询到的全局索引结点，定位到下层具体的某一个局部索引服务器上，将查询操作转移给该局部索引服务器继续处理；a3、局部索引服务器执行查询操作，查询本机负责的局部索引，找到待查键对应的数据后，直接返回给查询请求发起端。

除了常规的单键值查询，本发明支持按照一个待查询键的区间来检索该区间里面所有相应的值，即支持范围查询。本索引结构在构建的时候，将待索引数据集按照顺序分成若干互不相交的子集，每一个子集映射到一个单独的局部索引上。局部索引采用SkipList存储，则其中存储的子集数据也是有序的。因此，通过本索引结构进行范围查询主要需要2个步骤：b1、按照单键值查询的方式，以待查询键的区间的下界为键，找到具体某一个局部索引中对应的结点；b2、找到的结点为起点，顺序向后遍历并缓存查询到的数据，直到找到待查询键的区间的上界为止，然后将所有找到的数据返回给查询请求发起端。

此外，本发明还采用动态***算法解决局部服务器中的热点问题，保存索引结构整体的负载均衡。

本发明中，整个索引结构被划分为互不相交的子集，各子集分别由单独的局部索引来维护。随着索引的动态***及删除等调整操作，局部索引的大小有可能会出现差异，即有的局部索引逐渐变大，而有的局部索引反而会变小。局部索引的大小发生变化有可能会导致各局部索引之间的负载出现不均衡，因为相对较大的局部索引，被访问的概率会加大。因此，需要相应的动态***算法来解决局部索引中可能存在的热点问题。

局部索引的***算法依赖于wall(x,i)定义来完成。wall(x,i)接受2个参数：x为计算***位置的起始结点，一般设置为待***的局部索引的桩结点；i为***因子，是用来确定***位置的层高，该参数越大则***后保留在前半部分子集中的结点越多，反正则越少。

局部索引的***流程为：

以欲进行***处理的局部索引S₁的桩结点为起始结点x，从高度i开始找到右边第一个高度等于i+1的结点wall(x,i)；

以结点wall(x,i)为界，将局部索引S₁前半部分指向结点wall(x,i)结点的后继指针修改为NULL，即从局部索引S₁中删除后半部分的结点；

以结点wall(x,i)为界，将后半部分的结点发送给局部索引S₂，逐个***到局部索引S₂中，即S₂为接收S₁***出来的后半部分数据的局部索引。

因此，wall(x,i)代表这样一个结点，该结点是结点x的第i层右边指向的第一个高度等于i+1的结点。图5给出了一个以结点5为起始结点求wall(5,3)的例子，线框中的结点24即为所求。

实例

一、可扩展存储索引结构的构造过程

当前的互联网应用通常采用云存储***来保存海量的业务数据，而这些云存储***一般以分布式哈希表（DistributedHashTable，简称DHT）来提供访问的入口。DHT是一种典型的健-值模型实例，数据在保存到DHT的过程中，首先会对其键计算相应的哈希值，然后再根据哈希值映射到逻辑空间的相应位置中。因为哈希函数的离散性，导致了数据的存储是随机分布的，因此采用DHT的方式存储数据并不能很好的支持范围查询。本发明提出了一种构建于云存储***上层的二级索引，其构造的过程如图6所示。

1、该存储索引结构对云存储***的存储空间进行划分，按照等量和有序的原则设定好各局部索引管理的空间范围。在本实例中，云存储***的存储空间为1-12，但由于DHT采用哈希函数离散映射的特性，其中的各键的存储是无序的。假定我们采用3个局部索引来保存分布式存储中的数据，按照等量的原则，每个局部索引应该存储4个数据。因此，从左往右，1号局部索引管理1-4，2号局部索引管理5-8，3号局部索引管理9-12。

2、按照第一步分配好的局部索引管理范围，将分布式存储***中的数据映射到对应的局部索引中。当映射过程完成以后，各局部索引内部将会是有序的，同时各局部索引之间也是有序的。

3、下层的各局部索引分别将其最高层级的结点即桩结点发布到上层的全局索引中，全局索引通过下层发布过来的元数据，构造全局索引，从而将各局部索引关联起来，构成完整的索引空间。基于SkipList的特性，其第一个结点必然是属于最高层级的，我们称之为桩结点。在图6中，从左往右，1号局部索引的桩结点为1，2号局部索引的桩结点为5，3号局部索引的桩结点为9。当这些最高层的桩结点发布到上层全局索引后，该全局索引构成了一个包含1，5，9三个结点的全局索引。

4、下层各局部索引逐步向下进行结点的迭代发布。根据预估的发布后查询速度变化率和发布后全局索引内存占用变化率，来判断是否要继续向下一层级发布局部索引结点的元数据。以图6为例，在构造的过程中，从左往右，1号局部索引发布了1，2号局部索引发布了5，3号局部索引发布了9。假设局部索引继续向下发布时，索引结构整体的查询速度能够取得正向收益，则1号局部索引将会再发布3，2号局部索引将会再发布7，3号局部索引将会再发布11。因此，当再向下发布后，上层的全局索引中将会包含1，3，5，7，9，11一共6个数据。若预估查询速度变化率和全局索引内存占用变化率，得到的索引结构整体的查询速度收益是负向的，则停止向下一层级发布。

二、可扩展索引结构的查询处理过程

本发明提出的可扩展索引结构是采用了两层体系结构，索引数据实际上存储于各局部索引中，而上层的全局索引则用来关联各局部索引，维护索引空间的整体一致性。对本索引结构实施查询操作时，首先会以上层的全局索引作为查询的入口，通过查询全局索引，来确定哪一个局部索引实际包含着待查数据。其次，查询处理将会转交给该局部索引，由该局部索引查询到确定的数据后，直接返回给查询请求的发起者。

图7给出了一个范围查询的具体处理流程，索引结构的索引空间和实施例一中一致，为1-12，待查询的数据为1-6。

1、待查询的区间会被发送给上层的全局服务器，全局索引以区间的下界作为查询的入口键（即数据1），在全局索引中进行检索。

2、当上层的全局索引根据下界的键定位到具体局部索引后，查询处理会被转交给发布该键的下层局部索引。在图7中，全局索引的数据1是由下层的左边第一个局部索引发布的，所以查询处理将会转移给该局部索引来继续处理。

3、当局部索引接收到转交来的查询处理请求时，首先会根据待查询的区间，遍历自己的索引。因为各局部索引内部是有序的，故只需不断向后遍历即可，直至满足查询区间的上界为止。假如待查询的区间查过了一个局部索引的管辖范围，则需要将查询请求转交给该局部索引的后继兄弟。由于各局部索引之间也是互相有序的，故该转交能够保证查询的完整性和正确性。以图7为例，因为待查区间共有6个数据，而每个局部索引只管理4个数据，所以需要进行局部索引直接的递进转交。当1号局部索引查询到键4后，发现并没有满足查询区间的上界，故其将查询请求转交给右边的后续局部索引（我们称之为2号局部索引），2号局部索引接受到查询请求后，继续在本空间中顺序向后检索，直至检索到数据6，满足了待查区间的上界。至此，本范围查询处理结束，查询到的数据集直接从2号局部索引返回给查询的请求端。

范围查询是本索引结构的主要特征之一，而单键查询作为范围查询的一个特殊情况（即待查区间为1的情况），其处理过程和上述介绍的流程是一致的。主要区别在于，单键查询不涉及局部索引内部的遍历，也不涉及局部索引间的转交。对于单键查询的情况，上层全局索引转交给下层某一局部索引后，直接在该局部索引内部找到待查数据，即可返回。

三、局部索引的***过程

扩展性是本发明提出的索引结构的一个重要特性，可扩展性要求本索引能够支持动态的增长。本索引结构的数据存储于各局部索引中，随着数据的动态***，可能出现部分局部索引管理数据过多，从而导致被访问的概率增大的情况。为此，本发明提出了一个局部索引***算法，当局部索引中存储的数据过多，可以将其一分二，前半部分继续保留在原索引服务器中，而后半部分可以选择存储到一台新的局部索引服务器，或是迁移到已有的负载较轻的局部索引服务器上。

图8给出了一个局部索引***的例子。其***的处理过程如下：

首先，根据wall(x,i)来确定***的结点位置。在本实例中，***的起始计算结点选择的是局部索引S₁第一个最高的桩结点（即5），***因子i的取值为3。则根据定义，找到的***位置为24；

以结点24为界，将前半部分结点中指向结点24的指针，修改为指向NULL。需要修改的为节点5，14，19的对应位置。

节点24以后的结点迁移到新的局部服务器上，或者是逐个归并到已有的负载较轻的局部索引服务器上。如果是迁移到新的局部服务器，一个可选的步骤是将第一个桩结点的高度调整到最高（即将结点24的高度提升到最高的5层），以保证最高层只有其一个结点。如果是迁移到已有的负载较轻的局部索引中，则需要将24以后的结点逐个遍历，重新***到该局部索引中。迁移后各结点的高度，将以重新***后生成的高度为准。

尽管上面对本发明说明性的具体实施方式进行了描述，以便于本技术领域的技术人员理解本发明，但应该清楚，本发明不限于具体实施方式的范围，对本技术领域的普通技术人员来讲，只要各种变化在所附的权利要求限定和确定的本发明的精神和范围内，这些变化是显而易见的，一切利用本发明构思的发明创造均在保护之列。

Claims (3)

1.一种云环境下可扩展存储索引结构的实现方法，其特征在于，包括以下步骤：

(1)、主从式的可扩展存储索引的两层结构

整个存储索引结构分为上下两层，上层为全局索引，由全局索引服务器负责管理，下层为多个局部索引，每个局部索引由一个局部索引服务器负责管理；

对待索引的数据集进行切分，按照平均的原则，分成包含等量数据的数据子集，划分的数据子集的个数与局部索引服务器相等；然后，划分好的数据子集与下层索引服务器一一对应，并在各下层索引服务器中以SkipList为基础建立局部索引，下层索引服务器将数据子集的各个数据分别存放到局部索引的各个结点中，完成局部索引的建立；

在局部索引建立完成的基础上，各局部索引挑选桩结点作为自己索引范围的“代表”发布到上层的全局索引中；发布时，抽取发布的桩结点的元数据发送到上层的全局索引服务器中，元数据包括：索引的键，局部索引服务器IP地址，局部索引服务器磁盘物理块号，以达到减轻上层索引的内存开销和存储更多结点的目的；全局索引服务器接收到下层各局部索引发布的元数据后，通过SkipList的形式将这些元数据作为全局索引结点组织成一个全局索引，在逻辑上将下层各独立的局部索引关联起来，维持了索引空间的整体一致性；

(2)、发布元数据结点的调整

局部索引向全局索引发布桩结点的元数据进行关联后，各局部索引会根据预估的收益，判断是否要继续往局部索引的下一层级进行发布：

如果往局部索引的下一层级进行发布，云存储***的查询速度变化率为正向，并且大全局索引服务器的内存占用变化率，则将局部索引的下一层级结点的元数据发布到上层的全局索引中，否则，不往下一层级进行发；

(3)、查询

3.1)、单键值查询

a1、由上层的全局索引服务器作为处理查询的入口，首先，在全局索引中查询到待查询键的全局索引结点；a2、根据全局索引中查询到的全局索引结点，定位到下层具体的某一个局部索引服务器上，将查询操作转移给该局部索引服务器继续处理；a3、局部索引服务器执行查询操作，查询本机负责的局部索引，找到待查键对应的数据后，直接返回给查询请求发起端；

3.2)、范围查询

b1、按照单键值查询的方式，以待查询键的区间的下界为键，找到具体某一个局部索引中对应的结点；b2、找到的结点为起点，顺序向后遍历并缓存查询到的数据，直到找到待查询键的区间的上界为止，然后将所有找到的数据返回给查询请求发起端。

2.根据权利要求1所述的可扩展存储索引结构的实现方法，其特征在于，还包括局部索引的***过程：

以欲进行***处理的局部索引S₁的桩结点为起始结点x，从高度i开始找到右边第一个高度等i+1的结点wall(x,i)，i为***因子，是***位置的层高；

以结点wall(x,i)为界，将局部索引S₁前半部分指向结点wall(x,i)结点的后继指针修改为NULL，即从局部索引S₁中删除后半部分的结点；

以结点wall(x,i)为界，将后半部分的结点发送给局部索引S₂，逐个***到局部索引S₂中，即S₂为接收S₁***出来的后半部分数据的局部索引；

前半部分即局部索引S₁继续保留在原索引服务器中，而后半部分即局部索引S₂可以选择存储到一台新的局部索引服务器，或是迁移到已有的负载较轻的局部索引服务器上。

3.根据权利要求1所述的可扩展存储索引结构的实现方法，其特征在于，所述的如果往局部索引的下一层级进行发布，云存储***的查询速度变化率为正向，并且大于全局索引服务器的内存占用变化率，则将局部索引的下一层级结点的元数据发布到上层的全局索引中，否则，不往下一层级进行发布为：

设Q_old为局部索引发布下一层结点元数据之前，索引结构整体的查询速度，Q_new为局部索引发布下一层结点数据之后，预估的索引结构整体的查询速度；将局部索引发布到下一层，则发布之后的索引结构整体查询速度变化率为：

$A_{query}=\frac{Q_{new}-Q_{old}}{Q_{old}}$

与索引结构整体查询速度变化率为A_query的定义方法相同，定义全局服务器内存占用变化率为A_{men_load}，则下层的局部索引向上层的全局索引发布结点元数据的阈值定义如下：