CN116260764A - 一种提高Web应用***的路由检索和匹配效率的方法和装置 - Google Patents
一种提高Web应用***的路由检索和匹配效率的方法和装置 Download PDFInfo
- Publication number
- CN116260764A CN116260764A CN202211723804.5A CN202211723804A CN116260764A CN 116260764 A CN116260764 A CN 116260764A CN 202211723804 A CN202211723804 A CN 202211723804A CN 116260764 A CN116260764 A CN 116260764A
- Authority
- CN
- China
- Prior art keywords
- route
- search tree
- matching
- path
- node
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/48—Routing tree calculation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/74—Address processing for routing
- H04L45/745—Address table lookup; Address filtering
- H04L45/748—Address table lookup; Address filtering using longest matching prefix
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供了一种提高Web应用***的路由检索和匹配效率的方法和装置,属于Web应用***技术领域,它解决了现有路由模块在路由分发操作上的效率问题。本提高Web应用***的路由检索和匹配效率的方法和装置,包括路由模块和基于该结构的操作,以及实现该方法的装置,路由模块使用路由搜索树作为核心数据结构来组织和存储路由项,然后围绕该结构设计实现相关的路由操作。本发明具有路由搜索树在避免冗余存储URL路径的同时,提供了极高的检索匹配效率的优点。
Description
技术领域
本发明属于Web应用***技术领域,涉及一种提高Web应用***的路由检索和匹配效率的方法和装置。
背景技术
在Web应用***中,路由器也称路由分发器或请求分发器,它是负责对请求进行路由分发操作(包括解析、匹配、处理和分发等)的基础模块。为了和计算机网络领域的路由器在概念上加以区分,以下将其称作路由模块。路由模块的核心功能是接收并解析HTTP请求,根据请求的方法和URL路径,检索和匹配到对应的路由项,将请求分发到对应的业务模块(或函数)进行处理。
在单体架构的Web应用***中,由于***设计承载的业务量较小、对外开放的接口数量也不多,基于快速实现的考虑,***通常采用简易的路由模块设计。为了易于开发,需要对接口的URL路径进行特殊规定,从路径的层级和内容上建立URL路径和业务模块(或处理函数)之间的联系。这样的设计虽然能够降低路由分发的复杂性,但是接口的地址格式呆板、语义表达受限、无法清晰表述业务,接口的扩展和升级也比较困难。
随着业务需求的持续增长,现代Web应用***的架构由单体应用向分布式、微服务化的方向演进已经成为主流趋势。在微服务架构的Web应用***中,服务网关具备路由分发、负载均衡、访问权限控制等功能,是接收和处理请求的前沿组件。***通过服务网关来聚合内部各种微服务的接口,向外部提供统一的RESTful API。因此,大型Web应用***必然对服务网关的性能有很高的要求。路由分发作为服务网关的核心功能,对***的整体负载能力有着至关重要的影响。
发明内容
本发明的目的是针对现有的技术存在上述问题,为Web应用***提供了一种组织、检索和匹配路由项的方法和装置,以解决现有技术设计的路由模块在路由分发操作上的效率问题。
本发明提出的技术方案所面向的应用场景如下:
1、Web应用***需要对外提供基于业务设计的、表述性强的、对用户友好的API接口。接口在设计上有明确的内部规范,或者遵循RESTful等开放标准。
2、Web应用***使用了动态资源服务器,需要根据请求的方法和URL路径对请求进行动态处理。
3、路由模块需要支持对URL路径的静态和正则两种匹配方式。
本发明设计了一种基于路由搜索树的数据结构,以及基于该结构的操作。以下内容将详细介绍本发明的技术方案,主要包括路由模块的功能逻辑设计,以及实现该模块所需要的底层技术细节(路由搜索树的定义、性质、数据结构、操作等)。
本发明的目的可通过下列技术方案来实现:
一种提高Web应用***的路由检索和匹配效率的方法和装置,包括路由模块和基于该结构的操作,以及实现该方法的装置,路由模块使用路由搜索树作为核心数据结构来组织和存储路由项,然后围绕该结构设计实现相关的路由操作。
路由操作的主要功能逻辑包含以下5个核心过程:
1、导入搜索树:路由模块根据***运行模式和配置来决定是否需要导入搜索树。导入搜索树是一个检查持久化存储的数据并将其反序列化为搜索树结构的过程。路由模块会检查外部介质(缓存、文件或数据库)中是否存在(经过序列化的)持久化存储的数据。如果存在,则对数据进行反序列化以便将搜索树还原到内存中;如果不存在,则执行构建过程。在实际应用中,如果路由项未发生变更,导入搜索树可以跳过构建过程,直接进入匹配过程。只有在路由项发生变更需要更新搜索树时,才需要重新构建。
2、构建搜索树:路由模块会在持久化数据不存在或者搜索树需要更新时,执行构建过程。构建搜索树是一个根据生成算法,将全部路由项聚合成一颗或多颗搜索树(森林)的过程。在实际应用中,构建过程只需要在路由模块初始化时执行一次。
3、存储搜索树:路由模块根据***运行模式和配置来决定是否需要存储搜索树。存储搜索树是一个对已构建的搜索树进行序列化并将其持久化存储到外部介质(缓存、文件或数据库)的过程。在实际应用中,对于常驻内存运行的路由模块,可以一直在内存中维护搜索树,只将外部介质作为数据备份使用,也可以选择不存储搜索树。对于不能常驻内存运行的路由模块,由于进程只在接收到请求时执行程序(或脚本),在处理完请求后结束程序(或脚本)并释放资源,所以需要将外部介质(缓存、文件或数据库)作为主要存储介质,以便在进程每次运行时加载到内存。
4、匹配路由项:在构建搜索树后,路由模块就可以对请求进行解析,根据请求的方法选择要检索的路由搜索树。基于路由搜索树的结构特性,完成请求和路由项之间的高效匹配;
5、分发和处理请求:如果匹配成功,则根据匹配到的路由项,将请求分发到指定的业务模块或服务节点,完成后续的业务处理过程。如果匹配失败,则执行预设的异常处理过程。
以上所述的内容已经包含了路由模块的主要功能逻辑。在实际应用中,Web应用***根据业务需要还可以设计其它功能逻辑,对本发明提供的基础设计进行扩展。
路由搜索树是一种在特里树基础上改进而成的多叉树结构。特里树也称前缀树或字典树,是一种专门处理字符串匹配的数据结构,常用于字符串的匹配、检索和统计应用。由于路由模块的业务特殊性,经典的特里树并不适用于路由项的检索和匹配。本方案根据应用场景的要求对其进行了特别的优化和改进。
路由搜索树的设计原理如下:
1、根据请求的方法(GET、POST、DELETE……)对路由项进行分组。每一个路由项分组单独构建成一颗路由搜索树。路由模块对每个请求的检索和匹配只会用到一颗路由搜索树。
2、路由项的规则和请求的URL路径是分段进行处理的。使用/字符作为分隔符,可以将一个URL路径拆分成多个路径分段。路由搜索树的每个节点保存一个路径分段(而不是只保存一个字符)。路径分段的数量决定了路由搜索树的高度。这是路由搜索树和传统特里树的显著区别。
3、路由项的规则需要支持静态和正则两种匹配方式。其中,静态匹配指的是路由项的规则是一个普通的URL路径字符串(不包含正则表达式),规则与请求的URL路径只需要进行简单的字面比较。静态匹配在很多程序设计语言中可以使用==、===运算符或者字符串的标准库函数来完成,执行效率相对较高。正则匹配指的是路由项的匹配规则是一个包含正则表达式的URL路径字符串,规则与请求的URL路径需要进行正则匹配。正则匹配在很多程序设计语言中需要使用正则比较函数来完成,执行效率相对较低。
4、如果一个路径分段中不包含正则表达式,那么该路径分段只需要进行静态匹配,我们将其称作静态路径分段(简称静态分段)。如果一个路径分段中包含正则表达式,那么该路径分段需要进行正则匹配,我们称其称作正则路径分段(简称正则分段)。由于两种路径分段在处理上存在差异,所以路由搜索树在设计上需要特别区分这两种路径分段类型。
路由搜索树的性质如下:
路由搜索树是一颗多叉树。多叉树中的每个节点可以包含0个或任意多个子节点。
根节点作为树的起始节点,只用于组织整个树形结构,不存储任何路径分段。
除根节点外的每一个节点都对应一个URL路径分段。同一层级的所有子节点,其对应的路径分段必须是唯一的。
从根节点出发到任意节点,将沿途经过的所有节点对应的路径分段通过/字符拼接起来,就是该节点的URL路径前缀。每个URL路径前缀在整个路由搜索树中是唯一的。
路由搜索树的节点结构,使用伪代码的表述如下:
class TreeNode
string PathSegment
object RuleContext
hashset StaticChi ldren
hashset RegularChi ldren
end class
每个节点至少包含路径分段、规则上下文、静态子节点集合和正则子节点集合等4个成员。在具体实现中,根据业务需要还可以扩展增加其它成员。
每个节点至少包含一个字符串类型的PathSegment成员。该成员用于存储节点对应的路径分段。
每个叶子节点至少包含一个对象(或键值对)类型的RuleContext成员。该成员用于存储节点对应的路由项规则上下文。对于非叶子节点,该成员的值为空(nul l)。
每个节点至少包含一个哈希表类型的StaticChi ldren成员。该成员是一个存储静态路径分段的子节点集合,每个元素的键是静态路径分段的内容,元素的值指向对应的子节点。根据哈希表结构的性质,对于在集合中***和检索子节点的操作,其时间复杂度均为O(1)。
每个节点至少包含一个哈希表类型的RegularChi ldren成员。该成员是一个存储正则路径分段的子节点集合,每个元素的键是正则路径分段的内容,元素的值指向对应的子节点。对于向集合中***子节点的操作,其时间复杂度为O(1)。对于在集合中匹配子节点的操作,其时间复杂度为O(CR)。这里的CR是子节点包含的正则路径分段的总数。
路由搜索树的生成算法是路由模块根据请求的方法对所有路由项进行分组,然后循环对每个分组的每个路由项进行以下操作:
1、对路由项匹配的URL路径进行格式化,去除规则路径开头和结尾的/字符。例如,/user/([0-9]+)/account路径经过处理后得到user/([0-9]+)/account。将/作为分隔符,把URL路径拆分为若干个路径分段。例如,user/([0-9]+)/account路径经过拆分后得到user、([0-9]+)和account共3个路径分段。将拆分后的路径分段依次加入到队列中。
2、根据路由项匹配的请求方法(如GET、POST、PUT、PATCH、DELETE等)查找对应路由搜索树的根节点是否存在。如果根节点不存在,则创建树的根节点,获取到根节点的引用。
3、从选定路由搜索树的根节点开始,将其作为当前节点,开始逐层检索。
4、从队列中取出一个路径分段,在当前节点的子节点集合中查找该路径分段是否存在。查找过程需要首先根据内容确定路径分段的类型。对于静态路径分段(只包含0-9A-Za-z_-字符),在当前节点的Stat icChi ldren子节点集合中查找。对于正则路径分段(包含()[]{}*.+?等特殊字符),在当前节点的RegexChi ldren子节点集合中查找。
5、如果路径分段已存在,则将对应的子节点作为当前节点;如果路径分段不存在,则创建一个新节点。新节点的PathSegment成员记录当前的路径分段,StaticChi ldren和RegexChi ldren子节点集合初始为空。将新节点连接到当前节点的对应子节点集合中。将新节点作为当前节点。
6、重复执行步骤5和6,直到所有的路径分段都已经***到路由搜索树中,结束该流程。
主流程序设计语言提供的序列化(反序列化)函数都支持对整型、浮点型、字符串、数组和哈希表(键值对)等数据类型进行转换处理。路由搜索树在设计上充分考虑了持久化存储的需要,特别选择了这些易于进行序列化处理的数据类型。
在具体实现中,基于Web应用***的运行环境差异,可以将路由搜索树序列化成JSON、XML等多种格式。经过序列化的数据可以作为数据流、记录或文本存储到外部介质(文件、缓存、数据库等),也可以封装成Protobuf等协议格式在网络中传输。
路由搜索树的匹配算法如下:
1、对请求的URL路径进行格式化,去除路径开头和结尾的/字符。将/作为分隔符,把URL路径拆分为若干个路径分段。例如,user/1/account路径经过拆分后得到user、1和account共3个路径分段。将路由分段加入到队列中。
2、根据请求的方法(如GET、POST、PUT、PATCH、DELETE等)选择一个待匹配的路由搜索树,获取到根节点的引用。如果路由搜索树不存在,说明请求使用了***不支持的方法,路由模块可以执行预设的异常处理。
3、从选定路由搜索树的根节点开始,将其作为当前节点,开始逐层检索。
4、从队列中取出一个路径分段,在当前节点的StaticChi ldren成员中,查找是否存在该路径分段。由于该成员使用哈希表结构实现,因此只需要判断键(路径分段)是否存在即可,查找效率很高。如果不存在,则继续在当前节点的RegexChi ldren成员中查找。路径分段需要分别与成员(集合)中的每个正则表达式进行匹配,该匹配过程的时间复杂度为O(CR),这里的CR是子节点包含的正则路径分段的总数。如果匹配到子节点,则将该子节点选定为当前节点。如果全部子节点都匹配失败,说明请求的URL路径有误,路由模块可以执行预设的异常处理。
5、重复执行步骤4,直到队列中的所有路径分段都已经匹配成功。最后一个路径分段匹配到的节点,其RuleContext成员记录的即为命中的路由项。路由模块根据路由项的规则上下文对请求进行分发。
与现有技术相比,本提高Web应用***的路由检索和匹配效率的方法和装置具有以下优点:
本发明设计了一种基于路由搜索树的数据结构,以及基于该结构的操作;通过构建路由搜索树,可以高效率地组织和存储路由项;通过基于路由搜索树的检索操作,可以高效率地完成路由项的匹配和分发。
附图说明
图1是本发明中路由操作的流程图。
图2是本发明中路由搜索树的结构图。
具体实施方式
以下是本发明的具体实施例并结合附图,对本发明的技术方案作进一步的描述,但本发明并不限于这些实施例。
本发明通过一个具体的应用示例,来说明路由搜索树的优势。假设***的用户模块提供了一系列业务接口,这些接口对应的路由项如下:
GET/user/login(获取用户登录页)
POST/authent icate(登录、验证用户身份)
GET/user/logout(注销)
GET/user/([0-9]+)/account(获取指定用户的账户信息)
GET/user/([0-9]+)/permission(获取指定用户的权限)
GET/user/([0-9]+)/privi lege(获取指定用户的特权)
GET/user/([0-9]+)/privi lege/vip(获取指定用户的VIP特权)
GET/user/([0-9]+)/fol low(获取指定用户的关注列表)
POST/user/([0-9]+)/fol low(关注)
GET/user/([0-9]+)/settings/basic(获取用户的基本设置)
GET/user/([0-9]+)/settings/security(获取用户的安全设置)
POST/user/([0-9]+)/settings(保存用户设置)
……
根据本发明的技术方案中提供的生成算法,以上所有路由项最终生成的路由搜索树结构,如图2所示,根据路由搜索树的数据结构特性,我们可以推导出以下结论:
1、路由搜索树作为一种改进的特里树结构,其在字符串的存储效率上明显优于其它数据结构。如上图所示,所有以/user/([0-9]+)/为前缀的路由项都聚合在([0-9]+)节点之下,避免了URL路径的冗余存储。
2、检索匹配的效率与树的高度和检索分支上的正则数量有关,与路由项的总数无关。
3、树的高度由所有API接口的URL路径中最大的目录层级决定。接口的URL路径通常都遵循尽量保证简短易读的设计原则,避免设置过多的目录层级。在实际应用中,大型Web应用***可能会提供成百上千的接口,但大多数接口的URL路径其目录层级都不超过6层。显然,接口的路径层级远远小于接口的数量。
4、所有的匹配操作只发生在树的一条分支上,我们把这条分支称作检索分支。在检索分支上,匹配静态路径分段的时间复杂度都是0(1);匹配动态路径分段的时间复杂度为O(CR),这里的CR是同一级正则路径分段的总数。举例说明,假设获取用户信息的接口支持手机号码、用户ID(8位)和用户名(a-z)三种格式的参数,则该接口的路由项为:
4.1、GET/user/(1[0-9]{10})/info(根据手机号获取用户信息)
4.2、GET/user/([0-9]{8})/info(根据ID获取用户信息)
4.3、GET/user/([a-z]+)/info(根据用户名获取用户信息)
此时,对于/user/……/info这条检索分支来说,第2个路径分段出现了3种正则表达式,则该路径分段的CR为3,即最糟糕的情况下需要对3个正则表达式进行匹配。显然,实际应用中很少有这样的接口设计。即便如此设计,同一级CR的数量也是很少的,对匹配效率的影响不大。
结论:路由搜索树在避免冗余存储URL路径的同时,提供了极高的检索匹配效率。
本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代,但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。
Claims (7)
1.一种提高Web应用***的路由检索和匹配效率的方法和装置,包括路由模块和基于该结构的操作,以及实现该方法的装置,其特征在于,所述路由模块使用路由搜索树作为核心数据结构来组织和存储路由项,然后围绕该结构设计实现相关的路由操作。
2.根据权利要求1所述的一种提高Web应用***的路由检索和匹配效率的方法和装置,其特征在于,所述路由搜索树是在特里树基础上改进而成的多叉树结构。
3.根据权利要求1所述的一种提高Web应用***的路由检索和匹配效率的方法和装置,其特征在于,所述路由操作的主要步骤如下:
S1、导入搜索树:路由模块根据***运行模式和配置来决定是否需要导入搜索树;
S2、构建搜索树:路由模块会在持久化数据不存在或者搜索树需要更新时,执行构建过程;
S3、存储搜索树:路由模块根据***运行模式和配置来决定是否需要存储搜索树;
S4、匹配路由项:在构建搜索树后,路由模块就可以对请求进行解析,根据请求的方法选择要检索的路由搜索树;
S5、分发和处理请求:如果匹配成功,则根据匹配到的路由项,将请求分发到指定的业务模块或服务节点,完成后续的业务处理过程。如果匹配失败,则执行预设的异常处理过程。
4.根据权利要求1所述的一种提高Web应用***的路由检索和匹配效率的方法和装置,其特征在于,所述路由搜索树的设计原理如下:
Sa1、根据请求的方法(GET、POST、DELETE……)对路由项进行分组,每一个路由项分组单独构建成一颗路由搜索树;
Sa2、路由项的规则和请求的URL路径是分段进行处理的;
Sa3、路由项的规则需要支持静态和正则两种匹配方式;
Sa4、如果一个路径分段中不包含正则表达式,那么该路径分段只需要进行静态匹配;如果一个路径分段中包含正则表达式,那么该路径分段需要进行正则匹配。
5.根据权利要求1所述的一种提高Web应用***的路由检索和匹配效率的方法和装置,其特征在于,所述路由搜索树的生成算法是路由模块根据请求的方法对所有路由项进行分组,然后循环对每个分组的每个路由项进行以下操作:
Sb1、对路由项匹配的URL路径进行格式化,去除规则路径开头和结尾的/字符;
Sb2、根据路由项匹配的请求方法(如GET、POST、PUT、PATCH、DELETE等)查找对应路由搜索树的根节点是否存在;如果根节点不存在,则创建树的根节点,获取到根节点的引用;
Sb3、从选定路由搜索树的根节点开始,将其作为当前节点,开始逐层检索;
Sb4、从队列中取出一个路径分段,在当前节点的子节点集合中查找该路径分段是否存在;
Sb5、如果路径分段已存在,则将对应的子节点作为当前节点;如果路径分段不存在,则创建一个新节点;
Sb6、重复执行步骤Sb5和Sb6,直到所有的路径分段都已经***到路由搜索树中,结束该流程。
6.根据权利要求1所述的一种提高Web应用***的路由检索和匹配效率的方法和装置,其特征在于,所述路由搜索树通过序列化成包括但不限于JSON、XML的格式进行存储。
7.根据权利要求1所述的一种提高Web应用***的路由检索和匹配效率的方法和装置,其特征在于,所述路由搜索树的匹配算法如下:
Sc 1、对请求的URL路径进行格式化,去除路径开头和结尾的/字符;将/作为分隔符,把URL路径拆分为若干个路径分段;
Sc2、根据请求的方法(如GET、POST、PUT、PATCH、DELETE等)选择一个待匹配的路由搜索树,获取到根节点的引用;
Sc3、从选定路由搜索树的根节点开始,将其作为当前节点,开始逐层检索;
Sc4、从队列中取出一个路径分段,在当前节点的StaticChildren成员中,查找是否存在该路径分段;如果不存在,则继续在当前节点的RegexChildren成员中查找;
Sc5、重复执行步骤Sc4,直到队列中的所有路径分段都已经匹配成功。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211723804.5A CN116260764A (zh) | 2022-12-30 | 2022-12-30 | 一种提高Web应用***的路由检索和匹配效率的方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211723804.5A CN116260764A (zh) | 2022-12-30 | 2022-12-30 | 一种提高Web应用***的路由检索和匹配效率的方法和装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116260764A true CN116260764A (zh) | 2023-06-13 |
Family
ID=86678458
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211723804.5A Pending CN116260764A (zh) | 2022-12-30 | 2022-12-30 | 一种提高Web应用***的路由检索和匹配效率的方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116260764A (zh) |
-
2022
- 2022-12-30 CN CN202211723804.5A patent/CN116260764A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR100493882B1 (ko) | Xml 데이터 검색을 위한 질의 처리 방법 | |
US11068439B2 (en) | Unsupervised method for enriching RDF data sources from denormalized data | |
US20140188893A1 (en) | Data retrieval apparatus, data storage method and data retrieval method | |
US20060026138A1 (en) | Real-time indexes | |
US20140222870A1 (en) | System, Method, Software, and Data Structure for Key-Value Mapping and Keys Sorting | |
US8015195B2 (en) | Modifying entry names in directory server | |
CN105608228B (zh) | 一种高效的分布式的rdf数据存储方法 | |
CN112800065A (zh) | 基于改进区块存储结构的高效数据检索方法 | |
US7962484B2 (en) | LDAP bulk append | |
Von der Weth et al. | Multiterm keyword search in NoSQL systems | |
CN114416670A (zh) | 适用于网盘文档的索引创建方法、装置、网盘及存储介质 | |
CN106570153A (zh) | 一种海量url的数据提取方法及*** | |
CN112667747B (zh) | 支持自定义插件的动态配置多数据库分布式持久化方法 | |
CN107180034A (zh) | MySQL数据库的集群*** | |
CN106570152B (zh) | 一种手机号码的海量提取方法及*** | |
Li et al. | Accurate Counting Bloom Filters for Large‐Scale Data Processing | |
CN108121807B (zh) | Hadoop环境下多维索引结构OBF-Index的实现方法 | |
CN116260764A (zh) | 一种提高Web应用***的路由检索和匹配效率的方法和装置 | |
Gupta et al. | Efficient query analysis and performance evaluation of the NoSQL data store for bigdata | |
Abughofa et al. | Towards online graph processing with spark streaming | |
CN113672583B (zh) | 基于存储与计算分离的大数据多数据源分析方法及*** | |
CN113448757A (zh) | 消息处理方法、装置、设备、存储介质和*** | |
Zegour | Scalable distributed compact trie hashing (CTH*) | |
CN113946580B (zh) | 一种海量异构日志数据检索中间件 | |
CN110908996B (zh) | 一种数据处理的方法和装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |