CN115344568A - 内存索引机制处理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明提供一种内存索引机制处理方法、装置、电子设备及存储介质，所述方法包括：接收客户端发送的配置文件；从所述配置文件中解析出需要建立的索引信息；在对应的区域服务器中的内存中建立内存索引表并管理二级索引数据；基于所述内存索引表进行数据查询。本发明提供的内存索引机制处理方法、装置、电子设备及存储介质，基于内存二级索引的查询机制，将索引数据存储在内存数据库中，通过内存进行二级索引检索，提高了对大数据的实时查询响应。

Description

内存索引机制处理方法、装置、电子设备及存储介质

技术领域

本发明涉及数据库技术领域，尤其涉及一种内存索引机制处理方法、装置、电子设备及存储介质。

背景技术

为了实现对海量数据的高效存储和查询，对非主键列查询耗时太长的问题，众多NoSQL数据库被开发出来。

现有技术通过在客户端维护索引表以建立被查询的列与主键的对应关系，检索时通过索引表获取满足条件的主键集合，然后再根据查找到的主键在数据表中获取完整记录。

因为是在客户端同时维护数据表与索引表的一致性，所以如要建立新的索引，还需修改客户端代码，增加了客户端代码的冗余和复杂性，而且在客户端维护索引一致性会产生多余的远程方法调用，导致程序效率低下。

发明内容

本发明提供一种内存索引机制处理方法、装置、电子设备及存储介质，用以解决现有技术中内存索引机制处理效率低的技术问题。

本发明提供一种内存索引机制处理方法，包括：

接收客户端发送的配置文件；

从所述配置文件中解析出需要建立的索引信息；

在对应的区域服务器中的内存中建立内存索引表并管理二级索引数据；

基于所述内存索引表进行数据查询。

可选地，所述在对应的区域服务器中的内存中建立内存索引表，包括：

在对应的区域服务器中的内存中，采用倒排的方法，将数据表的值与主键进行交换，建立所述内存索引表。

可选地，所述基于所述内存索引表进行数据查询，包括：

截取Scan操作对应的检索条件；

从所述内存索引表中找出符合条件的索引项；

返回原数据表的主键，以进行数据查询。

可选地，索引元数据存储于HBase的表描述器中的配置器中。

可选地，索引增量更新分为三类：增量更新本地索引、增量更新全局索引、增量更新索引。

本发明还提供一种内存索引机制处理装置，包括：

接收模块，用于接收客户端发送的配置文件；

解析模块，用于从所述配置文件中解析出需要建立的索引信息；

构建模块，用于在对应的区域服务器中的内存中建立内存索引表并管理二级索引数据；

查询模块，用于基于所述内存索引表进行数据查询。

可选地，所述构建模块具体用于在对应的区域服务器中的内存中，采用倒排的方法，将数据表的值与主键进行交换，建立所述内存索引表。

可选地，所述查询模块包括截取单元、查找单元和返回单元，其中：

所述截取单元用于截取Scan操作对应的检索条件；

所述查找单元用于从所述内存索引表中找出符合条件的索引项；

所述返回单元用于返回原数据表的主键，以进行数据查询。

本发明还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任一种所述内存索引机制处理方法的步骤。

本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一种所述内存索引机制处理方法的步骤。

本发明提供的内存索引机制处理方法、装置、电子设备及存储介质，基于内存二级索引的查询机制，将索引数据存储在内存数据库中，通过内存进行二级索引检索，提高了对大数据的实时查询响应。

附图说明

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

图1是本发明提供的内存索引机制处理方法的流程示意图；

图2是本发明提供的系统总体结构图；

图3是本发明提供的建立的索引结构图；

图4是本发明提供的使用HT树构建的内存索引图；

图5是本发明提供的节点数量随时间变化的示意图；

图6是本发明提供的内存索引机制处理装置的结构示意图；

图7是本发明提供的电子设备的结构示意图。

具体实施方式

HBase是一种基于列存储的分布式数据库，作为开源分布式批处理框架Hadoop生态圈的核心组件，以良好的写性能，极佳的可扩展性，稳定的数据存储，在众多一线互联网企业的存储架构中发挥着关键作用，是海量数据的理想存储介质。

HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。但是访问HBase进行数据查询时只能通过Rowkey(注：Rowkey可以认为是等同关系数据库中表的主键)进行精确索引，因此基于主键作为检索条件查询效率非常高。这使得要按照某个列(column)进行条件查询需要进行全表扫描，才能最后得到想要的数据，然而HBase并不支持创建非主键列的索引，所以对非主键列进行条件查询需要扫描全表，效率低下。

为了实现对海量数据的高效存储和查询，对非主键列查询耗时太长的问题，众多NoSQL数据库被开发出来，现有技术通过在客户端维护索引表以建立被查询的列与主键的对应关系，检索时通过索引表获取满足条件的主键集合，然后再根据查找到的主键在数据表中获取完整记录。因为是在客户端同时维护数据表与索引表的一致性，所以如要建立新的索引，还需修改客户端代码，增加了客户端代码的冗余和复杂性，而且在客户端维护索引一致性会产生多余的远程方法调用，导致程序效率低下。

由于HBase只支持按照Rowkey进行索引，这导致应用系统通常情况下需要使用条件或者条件组合进行数据的查询无法在HBase上实现。实验表明，该方案相比原生数据库的条件检索速度有了极大提升，相比于基于Solr和HBase的二级索引方案检索速度也有所提升。

HBase由多个软件子系统组成，主要包括客户端、HMaster、HRegionServer、Zookeeper等，这些子系统共同组成一个分布式应用系统，它具有开源、分布式、可扩展及面向列存储的特点，能够为大数据提供随机、实时的读写访问功能。

如何从海量数据中快速获得所需数据是使用HBase等NoSQL数据库的一个重要原因，HBase在其主键上建立了B+树索引，在使用主键进行查询时效率很高。但是，在进行非主键的条件查询时，由于缺少主键的支撑，HBase必须进行全表扫描，导致查询效率低下，无法满足上述要求。

基于上述技术问题，本申请实施例基于内存二级索引的查询机制，将索引数据存储在内存数据库中，通过内存进行二级索引检索，提高了对大数据的实时查询响应。

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1是本发明提供的内存索引机制处理方法的流程示意图，如图1所示，本申请实施例提供一种内存索引机制处理方法，该方法包括：

步骤101、接收客户端发送的配置文件。

具体地，图2是本发明提供的系统总体结构图，如图2所示，HBase是一个构建在HDFS之上，用于海量数据存储分布式列存储系统。HBase表的每行都是按照RowKey的字典序排序存储，每行数据是按照RowKey区间进行分割存储成多个区域(Region)。HBase只针对行健的索引，在原生产品中访问HBase表中的行只能通过行健访问，行健区间访问和全表扫描三种。

其中，索引管理模块是框架核心，在用户对数据表进行更新操作时，内存索引机制处理器会对这些请求进行拦截，并对索引表进行相应操作，包括插入、删除和更新索引的元数据(记录用户表对应的索引表名称、索引列等信息)。执行查询操作时，系统会在缓存中寻找对应索引位置，提高了索引检索速度，当缓存中的索引更新时，索引管理模块也会对索引进行更新。索引持久化管理模块主要对缓存索引进行持久化操作，提供索引表和值表的持久化存储，HBase为持久化存储数据提供可扩展性和容错性。

由于HBase无法定制服务端逻辑，使得用户无法在服务端实现自己需求的二级索引方案，内存索引机制是一种服务端组件，类似于轻量级的MapReduce，它的主要思想是通过将集群内的数据移动取代为计算移动来减少计算代价，提高效率。

内存索引机制允许在Region服务器上运行自己的代码，更准确地说是允许用户执行Region级的操作，并且可以使用与DBMS中触发器(trigger)类似的功能。

用户通过提供的客户端接口所创建的索引信息应该被合理的保存，这些元数据信息是自适应动态构建索引和批量构建索引的依据，也是用户进行查询时自动利用索引加速查询过程的依据。为更好的利用HBase提供的各种钩子(Hook)函数去捕获用户创建、更改索引的动作，将索引元数据存储于HBase的表描述器(HTableDescriptor)中的配置器Configuration中，如果对HTableDescriptor进行任何的修改，都可以通过基本协处理器(BaseMasterObserver)中的预修改表(preModifyTable)进行获取。

索引增量更新分为三类，增量更新本地索引、增量更新全局索引、增量更新索引。本申请实施例自适应支持索引的三类增量更新。

索引同步是将跨表、跨库更新HBase索引表更新请求同步到目标索引，从而避免同步更新索引数据的一些弊端，充分利用批处理提高同步过程的安全性和高效性。在实现同步过程中使用Kafka(一种开源的分布式消息队列)安全存储数据，使用ZooKeeper(一种开源的分布式协调服务组件)用于通知用户接收新主题(Topic)中的消息。

索引数据可以存储于索引列族、索引表、针对不同类型的索引数据需要相应的子查询接口与请求参数，然后将子查询接口获取到的结果进行整合、过滤，将最终满足条件的结果返回给用户。大部分情形下，为某特定表建立索引要么都建立为全局索引，要么全部建立为本地索引，所以该实现可以满足大部分应用场景。

步骤102、从所述配置文件中解析出需要建立的索引信息。

步骤103、在对应的区域服务器中的内存中建立内存索引表并管理二级索引数据。

具体地，图3是本发明提供的建立的索引结构图，如图3所示，建立的索引结构图，采用倒排的方法，将数据表的值与主键进行交换，原本的值充当主键，原本的主键放在值的位置，一个最基本的索引表即构建完毕。在未建立索引前，HBase的数据模型可形式化表示如下：

{{{|}}},0,1,2,,iiii R→C→CQ→T V i＝n

其中行健为R，列族为C，列限定符为CQ，时间戳为T，值为V。则二级索引的形式化表示如下：

{{{|}}},0,1,2,,iiii V→C→CQ→T R i＝n

框架保证了索引文件和主表在同一个区域服务器(RegionServer)上，这样可以保证在需要使用索引文件时只需与RegionServer建立一次连接就可以完成，提高了速度。在此架构中，用户首先在配置文件(hbase-site.xml)中设定索引的细节，主服务器从配置文件中获取需要建立的索引信息，然后在对应的RegionServer中的内存中建立索引同时管理二级索引数据。每个节点上都部署了内存索引处理器，部署之后RegionServer端中的每个区域Region上都会自动创建一个区域索引处理RegionHost实例，它的主要功能是用来维护系统级或表级的区域观察者协处理Regionserver。

步骤104、基于所述内存索引表进行数据查询。

具体地，在本申请实施例中，在构建完索引表后，当进行索引查询时，客户端需要进行Scan操作，此操作将会被协处理器拦截，将检索条件截取，并从索引表中找出符合条件的索引项，返回原数据表的Rowkey，数据表根据Rowkey查询即可。

内存的索引相较于传统位于磁盘的索引在设计和架构上都大不相同，基于内存的索引在查询效率上得到了极大提升。广泛采用的内存索引有T树、基于缓存敏感的CSS/CSB+树和改进的Hash索引等。本申请实施例使用了HT树构建内存索引。

图4是本发明提供的使用HT树构建的内存索引图，如图4所示，每个节点有4个哈希表，每个哈希表中有三个哈希桶，在使用HT构建内存索引时，需要通过查找算法查找到关键字可以插入的哈希表，然后通过计算，找到关键字可插入的哈希桶，判断哈希桶是否已满，若已满则分裂该节点，将该关键字插入，若未满则直接插入哈希桶。

内存索引工作流程与一般索引的使用过程有所不同，具体流程如下：

1)内存索引初始化

当向数据表的构建过程中，需要同步进行内存索引的建立，对外提供检索服务。在第一次请求索引检索时，系统会检查内存索引是否为空，如果为空，则进行索引的初始化操作，建立内存索引。

2)Put操作过程

Put操作在HBase中相当于插入操作，当HBase执行这个操作时，当前操作发生的Region上的Observer会拦截这个事件，向内存索引中插入一条对应的索引项。

3)Delete操作过程

和Put操作相似，当客户端执行Delete操作时，HBase将从表中删除一条记录，当前操作发生的Region上的Observer会拦截这个事件，在内存索引中删除一条对应的索引项。

4)查询操作过程

该机制中，为了提高查询效率，尽量将数据处理过程本地化。在协处理器拦截到查询请求后，将会构建检索条件，根据条件在内存索引中进行多线程检索。得到满足检索条件的Rowkey后，返回数据表中查询原始数据，将结果返回客户端。在进行内存索引查询时，首先在哈希表中进行查找，定位关键字所在桶，继续在桶中查找，若找到，则指针指向所需记录。

下面评估本申请提出的基于内存索引机制处理方案，验证在构建二级索引时对数据库写入性能的影响和在构建了二级索引时对查询性能有怎样的提升。同时，基于内存构建索引与使用solr构建索引在查询性能上的表现。测试数据扩展性与集群扩展性。主机上搭建了Hadoop集群、Zookeeper集群和HBase集群，为了与同样基于协处理器的solr方案和HBase方案进行比较，还搭建了solr集群。实例所用数据为某上网流量近三天流量访问站点记录，属性包括ID，访问站点(STCD)，流量(RZ)，地区(RFROM)和时间(TM)，共3000万条数据。

在一台客户端上进行，数据源是3000万条数据，本测试用例。详情如下：查询上网弄时间段流量值在一定范围内的记录条数，对流量范围更改后即可得到不同的数据量。在流量属性上以建立HT树内存索引，对上网流量进行范围查询。

无索引的方案与其他有索引的方案性能相比有很大差距，原因是，在原生的数据库中搜寻一个特定值时，只能通过Scan的方式进行全表的扫描，效率极低，在数据量大时，这种查询方式可达几十个小时，无法进行实际使用。同时，可以发现，无论查询出的结果为多少，无索引的查询速度都在110分钟左右。排除误差影响，因为无论结果如何，无索引的方案都要全表扫描，在每次扫描的数据量相同时，查询时间变化不大。而本申请相比于同样构建了二级索引的基于solr的方案，性能有较明显的提升，数据量大时，查询速度为其3.5倍左右，与未构建索引的查询效率相比速度是其50倍左右，与同样基于内存索引的HBase方案提升了10％左右。

本申请不仅在性能上优势巨大，在随着查询结果的增大时，查询所需的时间变化也较小，因为通过内存进行计算，计算速度快，并且都在索引上建立了索引树结构，在关键字搜索时根据树结构搜索可以快速定位，数据量增大时，对速度影响也较小。

在3000万条数据的基础上，通过增加节点的数量进行集群扩展性实验，由于节点的变化对单值查询的性能影响可以忽略，因此，实验只对范围查询进行。

图5是本发明提供的节点数量随时间变化的示意图，如图5所示，随着节点数量的增加，查询响应时间逐渐减少。在进行范围查询时，会向所有节点发送查询请求，所以，当节点数量增加时，相应的查询时间就会变短。

本申请的内存索引机制将跨表、跨库更新HBase索引表索引更新请求同步到二级索引，并接收客户端发出的数据查询请求，通过本地索引、全局索引获得查询结果，并返回给客户端。

本申请提供的基于内存二级索引的查询机制，将索引数据存储在内存数据库中，通过内存进行二级索引检索，提高了对大数据的实时查询响应，方案不仅在性能上优势巨大，在随着查询结果的增大时，查询所需的时间变化也较小，因为通过内存进行计算，计算速度快，并且都在索引上建立了索引树结构，在关键字搜索时根据树结构搜索可以快速定位，数据量增大时，对速度影响也较小。

可选地，所述在对应的区域服务器中的内存中建立内存索引表，包括：

在对应的区域服务器中的内存中，采用倒排的方法，将数据表的值与主键进行交换，建立所述内存索引表。

具体地，图3是本发明提供的建立的索引结构图，如图3所示，建立的索引结构图，采用倒排的方法，将数据表的值与主键进行交换，原本的值充当主键，原本的主键放在值的位置，一个最基本的索引表即构建完毕。在未建立索引前，HBase的数据模型可形式化表示如下：

{{{|}}},0,1,2,,iiii R→C→CQ→T V i＝n

其中行健为R，列族为C，列限定符为CQ，时间戳为T，值为V。则二级索引的形式化表示如下：

{{{|}}},0,1,2,,iiii V→C→CQ→T R i＝n

框架保证了索引文件和主表在同一个区域服务器(RegionServer)上，这样可以保证在需要使用索引文件时只需与RegionServer建立一次连接就可以完成，提高了速度。在此架构中，用户首先在配置文件(hbase-site.xml)中设定索引的细节，主服务器从配置文件中获取需要建立的索引信息，然后在对应的RegionServer中的内存中建立索引同时管理二级索引数据。每个节点上都部署了内存索引处理器，部署之后RegionServer端中的每个区域Region上都会自动创建一个区域索引处理RegionHost实例，它的主要功能是用来维护系统级或表级的区域观察者协处理Regionserver。

可选地，所述基于所述内存索引表进行数据查询，包括：

截取Scan操作对应的检索条件；

从所述内存索引表中找出符合条件的索引项；

返回原数据表的主键，以进行数据查询。

具体地，在构建完索引表后，当进行索引查询时，客户端需要进行Scan操作，此操作将会被协处理器拦截，将检索条件截取，并从索引表中找出符合条件的索引项，返回原数据表的Rowkey，数据表根据Rowkey查询即可。

可选地，索引元数据存储于HBase的表描述器中的配置器中。

具体地，为更好的利用HBase提供的各种钩子(Hook)函数去捕获用户创建、更改索引的动作，将索引元数据存储于HBase的表描述器(HTableDescriptor)中的配置器Configuration中，如果对HTableDescriptor进行任何的修改，都可以通过基本协处理器(BaseMasterObserver)中的预修改表(preModifyTable)进行获取。

可选地，索引增量更新分为三类：增量更新本地索引、增量更新全局索引、增量更新索引。

具体地，索引增量更新分为三类，增量更新本地索引、增量更新全局索引、增量更新索引。本申请实施例自适应支持索引的三类增量更新。

索引同步是将跨表、跨库更新HBase索引表更新请求同步到目标索引，从而避免同步更新索引数据的一些弊端，充分利用批处理提高同步过程的安全性和高效性。在实现同步过程中使用Kafka(一种开源的分布式消息队列)安全存储数据，使用ZooKeeper(一种开源的分布式协调服务组件)用于通知用户接收新主题(Topic)中的消息。

图6是本发明提供的内存索引机制处理装置的结构示意图，如图6所示，本发明提供的内存索引机制处理装置，包括接收模块601、解析模块602、构建模块603和查询模块604，其中：

接收模块601用于接收客户端发送的配置文件；

解析模块602用于从所述配置文件中解析出需要建立的索引信息；

构建模块603用于在对应的区域服务器中的内存中建立内存索引表并管理二级索引数据；

查询模块604用于基于所述内存索引表进行数据查询。

可选地，所述构建模块具体用于在对应的区域服务器中的内存中，采用倒排的方法，将数据表的值与主键进行交换，建立所述内存索引表。

可选地，所述查询模块包括截取单元、查找单元和返回单元，其中：

所述截取单元用于截取Scan操作对应的检索条件；

所述查找单元用于从所述内存索引表中找出符合条件的索引项；

所述返回单元用于返回原数据表的主键，以进行数据查询。

本申请实施例提供的内存索引机制处理装置，可以用于执行上述相应实施例中所述的方法，通过本实施例提供的装置执行上述相应实施例中所述方法的具体步骤与上述相应实施例相同，且能够达到相同的技术效果，在此不再对本实施例中与方法实施例相同的部分及有益效果进行具体赘述。

图7是本发明提供的电子设备的结构示意图，如图7所示，该电子设备可以包括：处理器(processor)710、通信接口(Communications Interface)720、存储器(memory)730和通信总线740，其中，处理器710，通信接口720，存储器730通过通信总线740完成相互间的通信。处理器710可以调用存储器730中的逻辑指令，以执行内存索引机制处理方法，该方法包括：

接收客户端发送的配置文件；

从所述配置文件中解析出需要建立的索引信息；

在对应的区域服务器中的内存中建立内存索引表并管理二级索引数据；

基于所述内存索引表进行数据查询。

此外，上述的存储器730中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

另一方面，本发明还提供一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法所提供的内存索引机制处理方法，该方法包括：

接收客户端发送的配置文件；

从所述配置文件中解析出需要建立的索引信息；

在对应的区域服务器中的内存中建立内存索引表并管理二级索引数据；

基于所述内存索引表进行数据查询。

又一方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各提供的内存索引机制处理方法，该方法包括：

接收客户端发送的配置文件；

从所述配置文件中解析出需要建立的索引信息；

在对应的区域服务器中的内存中建立内存索引表并管理二级索引数据；

基于所述内存索引表进行数据查询。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种内存索引机制处理方法，其特征在于，包括：

接收客户端发送的配置文件；

从所述配置文件中解析出需要建立的索引信息；

在对应的区域服务器中的内存中建立内存索引表并管理二级索引数据；

基于所述内存索引表进行数据查询。

2.根据权利要求1所述的内存索引机制处理方法，其特征在于，所述在对应的区域服务器中的内存中建立内存索引表，包括：

在对应的区域服务器中的内存中，采用倒排的方法，将数据表的值与主键进行交换，建立所述内存索引表。

3.根据权利要求1所述的内存索引机制处理方法，其特征在于，所述基于所述内存索引表进行数据查询，包括：

截取Scan操作对应的检索条件；

从所述内存索引表中找出符合条件的索引项；

返回原数据表的主键，以进行数据查询。

4.根据权利要求1所述的内存索引机制处理方法，其特征在于，索引元数据存储于HBase的表描述器中的配置器中。

5.根据权利要求1所述的内存索引机制处理方法，其特征在于，索引增量更新分为三类：增量更新本地索引、增量更新全局索引、增量更新索引。

6.一种内存索引机制处理装置，其特征在于，包括：

接收模块，用于接收客户端发送的配置文件；

解析模块，用于从所述配置文件中解析出需要建立的索引信息；

构建模块，用于在对应的区域服务器中的内存中建立内存索引表并管理二级索引数据；

查询模块，用于基于所述内存索引表进行数据查询。

7.根据权利要求6所述的内存索引机制处理装置，其特征在于，所述构建模块具体用于在对应的区域服务器中的内存中，采用倒排的方法，将数据表的值与主键进行交换，建立所述内存索引表。

8.根据权利要求6所述的内存索引机制处理装置，其特征在于，所述查询模块包括截取单元、查找单元和返回单元，其中：

所述截取单元用于截取Scan操作对应的检索条件；

所述查找单元用于从所述内存索引表中找出符合条件的索引项；

所述返回单元用于返回原数据表的主键，以进行数据查询。

9.一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至6任一项所述内存索引机制处理方法的步骤。

10.一种非暂态计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述内存索引机制处理方法的步骤。

Images