CN116578585B - 数据查询方法、装置、电子设备及存储介质 - Google Patents

数据查询方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN116578585B
CN116578585B CN202310856225.6A CN202310856225A CN116578585B CN 116578585 B CN116578585 B CN 116578585B CN 202310856225 A CN202310856225 A CN 202310856225A CN 116578585 B CN116578585 B CN 116578585B
Authority
CN
China
Prior art keywords
query
database
query request
request
result
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.)
Active
Application number
CN202310856225.6A
Other languages
English (en)
Other versions
CN116578585A (zh
Inventor
阙裕斌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Origin Shuan Technology Co ltd
Original Assignee
Beijing Origin Shuan Technology Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beijing Origin Shuan Technology Co ltd filed Critical Beijing Origin Shuan Technology Co ltd
Priority to CN202310856225.6A priority Critical patent/CN116578585B/zh
Publication of CN116578585A publication Critical patent/CN116578585A/zh
Application granted granted Critical
Publication of CN116578585B publication Critical patent/CN116578585B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/242Query formulation
    • G06F16/2433Query languages
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/284Relational databases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/955Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • YGENERAL 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
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE 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/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开提供了一种数据查询方法、装置、电子设备及存储介质,所述方法包括:拦截目标终端向第一数据库发送的第一查询请求;解析所述第一查询请求,以确定所述第一查询请求是否查询第二数据库;若确定查询所述第二数据库,则根据所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求;根据所述至少一个第二查询请求获取所述第二数据库的至少一个查询结果;根据所述第一查询请求对应的查询结果格式,合并所述至少一个查询结果并发送给目标终端。本公开提供的方案,通过将目标终端向第一数据库发送的第一查询请求转换为适用于第二数据库的第二查询请求的方式,实现了所述目标终端查询其他数据库的功能。

Description

数据查询方法、装置、电子设备及存储介质
技术领域
本公开涉及数据查询技术领域,尤其涉及一种数据查询方法、装置、电子设备及存储介质。
背景技术
Kibana是Elastic NV公司维护的一个免费且开放的数据分析系统。Kibana除了可以对日志进行数据分析,还可以对指标以及调用链等场景的数据进行查询分析。Kibana虽然分析功能强大、组件库丰富、易用性很好,但是局限性也很明显,就是必须结合开源的文献搜索引擎Elasticsearch使用。也就是说Kibana只能对存储在Elasticsearch中的数据进行分析。
由于Kibana深度绑定Elasticsearch,使用Kibana只能分析Elasticsearch中的数据。但是若为了满足性能需求采用了其他类型的联机处理分析(Online analyticalprocessing,简称OLAP)数据源,同时还想使用具有丰富的组件库和强易用性的Kibana分析数据,目前使用Kibana是无法实现的。
发明内容
本公开提供一种数据查询方法、装置、电子设备及存储介质,以解决相关技术中由目标终端发出的适应于第一数据库的查询请求无法查询第二数据库的问题。
本公开的第一方面实施例提出了一种数据查询方法,包括:
拦截目标终端向第一数据库发送的第一查询请求;
解析所述第一查询请求,以确定所述第一查询请求是否查询第二数据库;所述第二数据库为关系型数据库或非关系型数据库;
若确定查询所述第二数据库,则根据所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求;
根据所述至少一个第二查询请求获取所述第二数据库的至少一个查询结果;
根据所述第一查询请求对应的查询结果格式,合并所述至少一个查询结果并发送给目标终端。
在一些实施例中,所述解析所述第一查询请求,以确定所述第一查询请求是否查询第二数据库,包括:
解析所述第一查询请求中的统一资源定位符URL,获取所述URL中的索引index名称;
基于所述第二数据库的数据表与所述第一数据库的index名称列表的映射关系,确定所述第一查询请求是否查询第二数据库。
在一些实施例中,所述根据所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求,包括:
判断所述第一查询请求是否为结构化查询语言SQL查询格式;
若是,则基于所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求;
若否,则将所述第一查询请求转换为SQL查询格式的至少一个查询命令;并根据所述至少一个查询命令,获取与所述第二数据库查询格式对应的至少一个第二查询请求。
在一些实施例中,所述将所述第一查询请求转换为SQL查询格式的至少一个查询命令,包括:
基于所述第一数据库的查询语法,根据所述第一查询请求中的关键字信息,确定至少一个查询命令。
在一些实施例中,所述根据所述至少一个查询命令,获取与所述第二数据库查询格式对应的至少一个第二查询请求,包括:
基于所述第二数据库的查询模板,将所述至少一个查询命令渲染为与所述第二数据库查询格式对应的至少一个第二查询请求;其中,所述至少一个第二查询请求中的每个查询请求均携带有标识信息,所述标识信息用于指示其对应的所述第二查询请求在所述第一查询请求中的顺序和层级。
在一些实施例中,所述根据所述第一查询请求对应的查询结果格式,合并所述至少一个查询结果并发送给目标终端,包括:
基于所述第一数据库的查询结果模板,将所述至少一个查询结果渲染为所述第一查询请求对应的查询结果格式;其中,渲染后的所述至少一个查询结果中的每个查询结果均携带有标识信息,所述标识信息用于指示其对应的所述第二查询请求在所述第一查询请求中的顺序和层级;
根据所述渲染后的所述至少一个查询结果中的每个查询结果的标识信息,确定所述渲染后的所述至少一个查询结果中的每个查询结果在所述第一查询请求中的顺序和层级;
根据所述渲染后的所述至少一个查询结果中的每个查询结果在所述第一查询请求中的顺序和层级,合并所述至少一个查询结果并发送给目标终端。
在一些实施例中,本公开所述的数据查询方法,还包括:
构建第二数据库的数据表与所述第一数据库的index名称列表的映射关系。
本公开的第二方面实施例提出了一种数据查询装置,包括:
拦截模块,用于拦截目标终端向第一数据库发送的第一查询请求;
解析模块,用于解析所述第一查询请求,以确定所述第一查询请求是否查询第二数据库;
第一获取模块,用于若确定查询所述第二数据库,则根据所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求;
第二获取模块,用于根据所述至少一个第二查询请求获取所述第二数据库的至少一个查询结果;
发送模块,用于根据所述第一查询请求对应的查询结果格式,合并所述至少一个查询结果并发送给目标终端。
本公开的第三方面实施例提出了一种电子设备,包括:
处理器和存储器,该存储器用于存储计算机程序,所述处理器用于调用并运行所述存储器中存储的计算机程序,执行如本公开第一方面实施例中描述的方法的步骤。
本公开的第四方面实施例提出了一种存储有计算机指令的非瞬时计算机可读存储介质,其特征在于,所述计算机指令用于使所述计算机执行如本公开第一方面实施例中描述的方法的步骤。
综上,根据本公开提供的数据查询方法,包括拦截目标终端向第一数据库发送的第一查询请求;解析所述第一查询请求,以确定所述第一查询请求是否查询第二数据库;若确定查询所述第二数据库,则根据所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求;根据所述至少一个第二查询请求获取所述第二数据库的至少一个查询结果;根据所述第一查询请求对应的查询结果格式,合并所述至少一个查询结果并发送给目标终端。本公开提供的方案,通过将目标终端向第一数据库发送的第一查询请求转换为适应于第二数据库的第二查询请求,并将查询结果以第一查询请求对应的查询结果格式发送给所述目标终端,解决了相关技术中由目标终端发出的适应于第一数据库的查询请求无法查询第二数据库的问题。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本公开的实施例,并与说明书一起用于解释本公开的原理,并不构成对本公开的不当限定。
图1为本公开实施例提供的相关技术中利用Kibana查询Elasticsearch的第一原理框图;
图2为本公开实施例提供的相关技术中利用Kibana查询Elasticsearch的第二原理框图;
图3为本公开实施例提供的相关技术中利用Kibana查询Elasticsearch的第三原理框图;
图4为本公开实施例提供的相关技术中利用Kibana查询Elasticsearch的第四原理框图;
图5为本公开实施例提供的数据查询方法的流程示意图;
图6为本公开实施例提供的数据查询装置的结构示意图;
图7为本公开应用示例提供的数据查询方法的原理框图;
图8为本公开应用示例提供的所述elasticsearch-proxy的部署方法的流程示意图;
图9为本公开应用示例提供的数据查询方法的流程示意图;
图10为本公开应用示例提供的利用同步调用格式实现本公开应用示例提供的数据查询方法的流程示意图;
图11为本公开应用示例提供的利用异步消息机制实现本公开应用示例提供的数据查询方法的流程示意图;
图12为本公开实施例提供的电子设备的组成示意图。
具体实施方式
下面详细描述本公开的实施例,实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,旨在用于解释本公开,而不能理解为对本公开的限制。
下面对本公开中的关键字进行示意:
Kibana:Kibana是Elastic NV公司维护的一个免费且开放的数据分析系统。Kibana除了可以对日志进行数据分析,还可以对指标以及调用链等场景的数据进行查询分析。Kibana作为ELK数据分析的核心,集成了丰富的可视化工具、界面交互开发工具和管理工具,能够帮助数据分析人员将数据轻松分享给任何人,甚至还能通过机器学习来监测数据中的隐藏异常并追溯其来源。利用Kibana能深入挖掘数据的内在关联并迅速呈现,很好的解决企业的大数据分析难题。
ELK:开源组件近实时的分布式搜索分析引擎(Elasticsearch)及日志采集器(Logstash)和Kibana一起提供数据搜索/分析的功能,简称为ELK。
OLAP:联机分析处理(Online analytical processing,简称OLAP),是计算机技术中快速解决多维分析问题(MDA)的一种方法。OLAP是更广泛的商业智能范畴的一部分,它还包括关系数据库、报告编写和数据挖掘。OLAP的典型应用包括销售业务报告、市场营销、管理报告、业务流程管理(BPM)、预算和预测、财务报表以及类似领域。OLAP是对传统数据库术语“联机事务处理(OLTP)”修改而成的。
Kibana虽然分析功能强大、组件库丰富、易用性很好,但是其局限性也很强。比如Kibana必须结合Elasticsearch使用,也就是说Kibana只能对存储在Elasticsearch中的数据进行分析。
但是随着业务量的发展,用户需要分析的数据越来越多,这就要求业务系统必须在具备高吞吐量的同时,也要具备较高的实时性。Elasticsearch在大数据场景中性能往往会满足不了生产环境的性能需求,其主要原因如下:
首先,Elasticsearch由于分词等特性,在写吞吐量上有明显的瓶颈;
其次,Elasticsearch如果运行环境资源不足,就容易导致业务系统稳定性下降,数据写入发生延迟;
再次,由于Elasticsearch数据压缩率不高的原因,业务系统对内存有着较高的要求。
在对写入吞吐和查询实时性有很高要求的大数据处理分析场景中,特别是数据量为PB级别的场景,为了让数据写入和查询高效稳定,往往会将数据存储到其他的OLAP数据库中,例如ClickHouse、Apache Druid、Apache Doris等。OLAP数据库能够通过列式存储和高质量的数据压缩,极大地减少数据扫描范围和数据传输时的大小,另外这些存储也实现了向量化执行引擎充分发挥中央处理器(CPU)的性能,达到快速高效计算的目的。所以在大数据处理时,我们也会使用其他类型的OLAP数据库来满足生产环境的性能需求。
由于Kibana深度绑定Elasticsearch,使用Kibana只能分析Elasticsearch中的数据。但是若为了满足性能需求采用了其他类型的联机处理分析(Online analyticalprocessing,简称OLAP)数据源,同时还想使用具有丰富的组件库和强易用性的Kibana分析数据,目前使用Kibana是无法实现的。
相关技术中,Kibana是一个运行在Node.js环境上的应用,前端后端的主要语言都是JavaScript。Kibana由Kibana客户端(client)和Kibana服务器(server)组成。Kibanaclient的功能主要是在浏览器展示各种分析组件,并且将用户的请求发送到Kibanaserver,最后将Kibana server响应的结果渲染到浏览器中。Kibana server的功能是监听一个端口,接收Kibana client的请求,处理请求以及返回请求结果到Kibana client。如图1所示,Kibana通过以下步骤查询Elasticsearch中的数据:
首先,元数据管理,具体的:
用户使用Kibana数据分析过程中会创建的仪表盘、可视化库、数据视图等分析组件,我们称这些分析组件为元数据。Kibana server接收到用户创建元数据的请求后,会解析所述请求并转换成组件模型,将模型存储到Elasticsearch中。Kibana server在Elasticsearch中对组件模型进行查询、修改和删除。
其次,业务数据查询,具体的:
用户通过Kibana组件可以分析各种类型的业务数据,比如日志数据、指标数据、调用链数据等。上述数据如果需要在Kibana中进行分析,则必须存储在Elasticsearch中。原生的Kibana server不能从其他数据库查询分析数据。
为了解决原生的Kibana server不能从其他数据库查询分析数据的问题,相关技术中提出了以下方案。
方案A:如图2所示,方案A实现了一种与Kibana相似的数据查询系统,对接OLAP数据库。具体的,用户自行开发Kibana client和Kibana server,Kibana client和Kibanaserver的交互可参考原生Kibana,Kibana server的数据查询需兼容OLAP数据库,元数据管理可以使用其他数据库,比如MySQL,PostgreSQL或者原生Elasticsearch等。
方案B:如图3所示,方案B开发了一种Kibana平台,扩展bsearch接口实现OLAP数据库业务数据查询逻辑,解决了现有的Kibana server代码查询接口bsearch只能查询Elasticsearch中的数据的问题,元数据管理依然使用Elasticsearch。
方案C:如图4所示,方案C设计了一个代理模块(Kibana-proxy),Kibana-proxy位于Kibana client和Kibana server之间,Kibana-proxy查询数据时包括以下步骤:
步骤a:Kibana-proxy拦截Kibana client发出的数据查询请求,并解析所述请求的查询语句。具体的,提取请求中的index字段去匹配是否需要查询OLAP数据库,如果匹配成功则认为此查询是查询其他OLAP数据库业务数据的请求,这部分匹配成功的请求将进行步骤b的处理。否则,匹配不成功的请求依然转发到Kibana server进行处理,和原生Kibana逻辑保持一致;
步骤b:解析所述请求的查询语句,转换为查询Query模型;
步骤c:将所述Query模型转换为一条或者多条查询语句,然后使用这些查询语句在OLAP数据库查询出结果列表;
步骤d:将查询出的结果列表以Kibana server结果格式为模板,拼装到一起组装成Kibana-proxy的查询结果;
步骤e:向Kibana client返回所述查询结果。
需要注意的是,元数据管理的请求在上述步骤第一步中是通过Kibana-proxy直接转发到Kibana server处理,Kibana-proxy没有做任何处理,这部分和原生Kibana逻辑保持一致。
上述相关技术中的方案存在以下缺陷:
方案A:
方案A中的每一个组件的前后端都需要重新开发测试,开发成本高;
续运维成本高,如果生产环境中已经有正在使用的Kibana,还涉及到现有数据和组件的迁移工作;
无法使用Kibana新版本的功能;由于Kibana是开源的,Kibana能够借助开源社区的力量快速的迭代更新。如果重新开发,后续Kibana新的功能都无法使用。
方案B:
Kibana官方的开发文档比较少,开发难度大;
后续Kibana版本更新困难,因为二次开发是选用的Kibana的一个版本,后期Kibana有升级需求时需要做全面的兼容性测试,可能会遇到不兼容的情况需要做兼容性适配;
现有环境中的Kibana需要重新部署,如果客户环境中存在Kibana环境,还需要考虑重新部署Kibana的问题,对现有的业务会有一定的影响。
方案C:
开发难度大,Kibana接口文档少,各个Kibana版本还需要做接口解析兼容;
Kibana版本升级也需要做兼容性测试,Kibana升级之后接口请求可能会变化,所以Kibana-proxy解析接口的兼容性也需要全面测试。
为了解决相关技术中存在的问题,本公开提供一种数据查询方法,本方法基于目标终端发送的对应于第一数据库的第一查询请求,能够将所述第一查询请求转换为对饮关于第二数据库的第二查询请求,使与所述第一数据库关联的目标终端也能够查询所述第二数据库的数据。
在介绍本公开的详细方案之前,先对本公开所应用的场景进行描述。
在本公开的一个实施例中,所述的应用场景可以为数据查询系统中的数据查询。所述数据查询系统包括数据查询平台和若干个数据库,所述数据查询平台包括目标终端(也称前端或客户端,client)和服务器(也称后端,server)。所述服务器可基于用户在client的创建元数据操作请求,解析所述请求并转换成组件模型,将模型存储到数据库中。所述client可向所述server发送数据查询请求,由所述server接收所述查询结果并返回给所述client。其中,所述数据查询平台可为Kibana、Kaggle、阿里天池等,所述数据库可为Elasticsearch及ClickHouse、Apache Druid、Apache Doris等OLAP数据库。
作为深度绑定的数据查询平台和数据库,比如Kibana和Elasticsearch,由于Kibana的所述server的配置信息(如Elasticsearch的地址和端口配置信息)的限制,用户通过所述client发出的查询信息只能查询Elasticsearch中的数据。所述server返回的查询结果也必须与所述client匹配,才能被用户查阅。
在所述数据查询系统包含一个数据查询平台及多个数据库的应用场景中,所述数据查询平台的所述client发出的查询信息只能查询与之匹配的数据库中的数据。比如,用户需要的数据存储在Elasticsearch和OLAP两个数据库中,则用户无法通过Kibana平台的查询请求查询OLAP数据库中的数据,本公开实施例提供的数据查询方法正是要解决上述应用场景中的问题,使用户可以通过一个数据查询平台查询与之匹配的数据库之外的其他数据库中的数据。
基于此,如图5所示,本公开实施例提供了一种数据查询方法,包括以下步骤:
步骤501:拦截目标终端向第一数据库发送的第一查询请求;
其中,所述目标终端为与所述第一数据库匹配的数据查询平台的所述client。
在一实施例中,所述拦截目标终端向第一数据库发送的第一查询请求,包括:
拦截所述client通过数据查询平台的所述server向第一数据库发送的第一查询请求。
所述拦截目标终端向第一数据库发送的第一查询请求的实现方式可为:
基于所述server的端口配置信息,监听并拦截所述数据查询平台的所述server的端口发出的所述第一查询请求。
步骤502:解析所述第一查询请求,以确定所述第一查询请求是否查询第二数据库;所述第二数据库为关系型数据库或非关系型数据库;
在一实施例中,关系型数据库指用关系模型来组织数据信息的数据库。关系模型指的是二维表格模型,而一个关系型数据库便是由二维表以及表之间的关系所构成的一个数据集合。非关系型数据库指非关系型的,分布式系统的,且一般不确保遵照ACID(原子性、一致性、隔离性和持久性)标准的数据储存系统。非关系型数据库是一种数据结构化储存的集合,可以是文档或键值对等。非关系型数据库的本质是传统关系型数据库的功能阉割版本,通过去掉不需要的功能来提高性能。通常关系型数据库的查询能够使用结构化查询语言(Structured Query Language,简称SQL)语句,非关系型数据库的查询可以使用SQL语句,也可以不使用SQL语句,而非关系型数据库对应的查询语句。
在一实施例中,所述第二数据库为数据查询格式和数据查询结果均与所述第一数据库不同的数据库;若所述第一数据库和第二数据库均为关系型数据库,所述第一查询请求使用SQL语句,则通过如MyCat的异构分布式功能,也可能实现MySQL数据库和关系型非MySQL数据库的查询。但如果所述非MySQL数据库为非关系型数据库,则由于其查询请求的格式不是SQL语句,则无法查询。必须将所述第一查询请求转化为与所述第二数据库查询格式对应的至少一个第二查询请求才能够实现对所述第二数据库的查询。
所述第一查询请求的查询统一资源定位符URL的规则为/index名称/(_async_search|_search),所述/index名称(索引名称)表示所述第一查询请求对应的查询操作的索引名称,所述/(_async_search|_search)表示这是一个查询操作,所述查询操作可以是_async_search(异步查询)或者是_search(同步查询)中的一种,本公开对此不予限定。
所述解析所述第一查询请求,即根据所述第一数据库的查询URL规则,解析出index名称,若解析出的index名称在所述第二数据库的数据表映射所述第一数据库的index名称列表中,则确定所述第一查询请求查询第二数据库。否则所述第一查询请求继续查询所述第一数据库,并向所述目标终端返回查询结果。
基于此,在一实施例中,所述解析所述第一查询请求,以确定所述第一查询请求是否查询第二数据库,包括:
解析所述第一查询请求中的统一资源定位符URL,获取所述URL中的索引index名称;
基于所述第二数据库的数据表与所述第一数据库的index名称列表的映射关系,确定所述第一查询请求是否查询第二数据库。
步骤503:若确定查询所述第二数据库,则根据所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求;
相关技术中,SQL语句的查询可以查询如MySQL数据库等关系型数据库。但是如对Elasticsearch的查询中,查询语句使用非SQL语句,且查询请求的类型还分为数据查询(data query)和聚合查询(aggregation query)。聚合查询分为指标聚合查询(metricaggregation query)和分桶聚合查询(bucket aggregation query)。无论是数据查询还是聚合查询,其对应的查询语句中均有关键字作为标识,比如查询请求中关键字size大于0或者不存在aggs关键字的情况可视为数据查询,查询请求中包含aggs关键字的情况可视为聚合查询。
在一实施例中,所述第一查询请求可以同时包含数据查询和多个聚合查询,聚合查询中的分桶聚合查询也可以包含多个层级。但是,每个数据查询或者分桶聚合查询都可以转换成一个SQL语句,因此所述第一查询请求可以根据其包含的关键字转换为与所述第二数据库查询格式对应的至少一个第二查询请求。
基于此,在一实施例中,所述根据所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求,包括:
判断所述第一查询请求是否为结构化查询语言SQL查询格式;
若是,则基于所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求;
若否,则将所述第一查询请求转换为SQL查询格式的至少一个查询命令;并根据所述至少一个查询命令,获取与所述第二数据库查询格式对应的至少一个第二查询请求。
由上述描述可知,非SQL语句的查询类型是基于关键字信息确定的,基于此,在一实施例中,所述将所述第一查询请求转换为SQL查询格式的至少一个查询命令,包括:
基于所述第一数据库的查询语法,根据所述第一查询请求中的关键字信息,确定至少一个查询命令。
需要注意的是,以所述第一数据库为Elasticsearch为例,所述第一查询请求为非SQL语句;因此,需根据所述第一查询请求中的关键字信息确定其包含的至少一个查询命令。
在一实施例中,所述至少一个查询命令包括至少一个聚合查询指令、针对至少一个第二数据库的查询指令或由一个层级的分桶指令得到的多个分桶指令中的至少一种。
在一实施例中,所述根据所述至少一个查询命令,获取与所述第二数据库查询格式对应的至少一个第二查询请求,包括:
预定义不同查询类型对应的所述第二数据库的查询模板;所述查询模板指与所述第二数据库为非关系型数据库时,其查询格式对应的查询模板;
基于所述第二数据库的查询模板,将所述至少一个查询命令渲染为与所述第二数据库查询格式对应的至少一个第二查询请求;其中,所述至少一个第二查询请求中的每个查询请求均携带有标识信息,所述标识信息用于指示其对应的所述第二查询请求在所述第一查询请求中的顺序和层级。
其中,所述查询模板包括以下模板中的至少之一:
数据查询模板、指标聚合查询模板、分桶聚合查询模板。
所述查询模板可根据标准SQL的语法定义,比如:
数据查询模板:SELECT<FIELDS>FROM<DB.TABLE>ORDER BY<ORDERBY>LIMIT<LIMIT>
指标聚合查询模板:SELECT<METRICS>FROM<DB.TABLE>WHERE<FILTERS>
分桶聚合查询模板:
SELECT<METRICS>,<BUCKET_FIELDS>FROM<DB.TABLE>WHERE<FILTERS>GROUPBY
<GROUP_BY_FIELDS_OR_FUNCTIONS>ORDER BY<ORDERBY>LIMIT<LIMIT>
实际应用中,不同的所述第二数据库类型对应不同的SQL语法,或者不同的所述第二数据库在做聚合时具有专用的函数,其模板也会不同,本公开中对此不予限定。
在一实施例中,所述至少一个查询指令可包括至少一个聚合查询指令,还可包括针对至少一个第二数据库的查询指令,还可包括由一个层级的分桶指令得到的多个分桶指令,本公开中对此不予限定。
步骤504:根据所述至少一个第二查询请求获取所述第二数据库的至少一个查询结果;
由于所述至少一个第二查询请求是对应于所述第二数据库的查询格式的查询请求,因此可直接从所述第二数据库中获取至少一个查询结果。其中,为了至少一个查询结果与所述第一查询请求中至少一个查询命令的顺序和层级相匹配,所述至少一个查询结果中的每个查询结果均携带有标识信息,所述标识信息用于指示其对应的所述第二查询请求在所述第一查询请求中的顺序和层级。
步骤505:根据所述第一查询请求对应的查询结果格式,合并所述至少一个查询结果并发送给目标终端。
其中,合并至少一个查询结果时,需要基于每个查询结果的标识信息,根据所述标识信息指示的每个查询结果对应的顺序和层级合并。
基于此,在一实施例中,所述根据所述第一查询请求对应的查询结果格式,合并所述至少一个查询结果并发送给目标终端,包括:
基于所述第一数据库的查询结果模板,将所述至少一个查询结果渲染为所述第一查询请求对应的查询结果格式;其中,渲染后的所述至少一个查询结果中的每个查询结果均携带有标识信息,所述标识信息用于指示其对应的所述第二查询请求在所述第一查询请求中的顺序和层级;
根据所述渲染后的所述至少一个查询结果中的每个查询结果的标识信息,确定所述渲染后的所述至少一个查询结果中的每个查询结果在所述第一查询请求中的顺序和层级;
根据所述渲染后的所述至少一个查询结果中的每个查询结果在所述第一查询请求中的顺序和层级,合并所述至少一个查询结果并发送给目标终端。
实际应用中,由于确定所述第一查询请求是否查询第二数据库时,需要基于所述第二数据库的数据表与所述第一数据库的index名称列表的映射关系,因此,本公开所述的数据查询方法,在所述步骤501之前,还包括:
构建所述第二数据库的数据表与所述第一数据库的index名称列表的映射关系。
综上,本公开实施例提供的数据查询方法,包括拦截目标终端向第一数据库发送的第一查询请求;解析所述第一查询请求,以确定所述第一查询请求是否查询第二数据库;若确定查询所述第二数据库,则根据所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求;根据所述至少一个第二查询请求获取所述第二数据库的至少一个查询结果;根据所述第一查询请求对应的查询结果格式,合并所述至少一个查询结果并发送给目标终端。
本公开提供的方案,通过将目标终端向第一数据库发送的第一查询请求转换为适应于第二数据库的第二查询请求,并将查询结果以第一查询请求对应的查询结果格式发送给所述目标终端,解决了相关技术中由目标终端发出的适应于第一数据库的查询请求无法查询第二数据库的问题。
进一步的,本公开所述的第二数据库可以是关系型数据库,非关系型数据库,或者既包含关系型数据库又包含非关系型数据库。关系型数据库对应的所述第一查询请求可直接转换为针对关系型数据库的至少一个所述第二查询请求。非关系型数据库对应的所述第一查询请求可转换为SQL查询格式的至少一个查询命令;并根据所述至少一个查询命令,得到与非关系型数据库查询格式对应的至少一个第二查询请求,进而实现了对非关系数据库的查询请求。
进一步,本公开所述至少一个查询指令可包括至少一个聚合查询指令,还可包括针对至少一个第二数据库的查询指令,还可包括由一个层级的分桶指令得到的多个分桶指令。
为了实现本公开实施例提供的数据查询方法,本公开实施例还提供一种数据查询装置,如图6所示,所述数据查询装置600,包括:
拦截模块601,用于拦截目标终端向第一数据库发送的第一查询请求;
解析模块602,用于解析所述第一查询请求,以确定所述第一查询请求是否查询第二数据库;
第一获取模块603,用于若确定查询所述第二数据库,则根据所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求;
第二获取模块604,用于根据所述至少一个第二查询请求获取所述第二数据库的至少一个查询结果;
发送模块605,用于根据所述第一查询请求对应的查询结果格式,合并所述至少一个查询结果并发送给目标终端。
在一实施例中,所述数据查询装置600,还包括构建模块。所述构建模块,用于构建第二数据库的数据表与所述第一数据库的index名称列表的映射关系。
在一实施例中,所述解析模块602,具体用于:
解析所述第一查询请求中的统一资源定位符URL,获取所述URL中的索引index名称;
基于所述第二数据库的数据表与所述第一数据库的index名称列表的映射关系,确定所述第一查询请求是否查询第二数据库。
在一实施例中,所述第一获取模块603,具体用于:
根据所述第一查询请求,获取至少一个查询命令;
根据所述至少一个查询命令,获取与所述第二数据库查询格式对应的至少一个第二查询请求。
在一实施例中,所述第一获取模块603,还具体用于:
基于所述第一数据库的查询语法,根据所述第一查询请求中的关键字信息,确定至少一个查询命令。
在一实施例中,所述第一获取模块603,还具体用于:
基于所述第二数据库的查询模板,将所述至少一个查询命令渲染为与所述第二数据库查询格式对应的至少一个第二查询请求;其中,所述至少一个第二查询请求中的每个查询请求均携带有标识信息,所述标识信息用于指示其对应的所述第二查询请求在所述第一查询请求中的顺序和层级。
在一实施例中,所述发送模块605,具体用于:
基于所述第一数据库的查询结果模板,将所述至少一个查询结果渲染为所述第一查询请求对应的查询结果格式;其中,渲染后的所述至少一个查询结果中的每个查询结果均携带有标识信息,所述标识信息用于指示其对应的所述第二查询请求在所述第一查询请求中的顺序和层级;
根据所述渲染后的所述至少一个查询结果中的每个查询结果的标识信息,确定所述渲染后的所述至少一个查询结果中的每个查询结果在所述第一查询请求中的顺序和层级;
根据所述渲染后的所述至少一个查询结果中的每个查询结果在所述第一查询请求中的顺序和层级,合并所述至少一个查询结果并发送给目标终端。
本领域技术人员应当理解,图6所示的数据查询装置600中各单元的实现功能可参照前述数据查询方法的相关描述而理解。图6所示的数据查询装置600中的各单元的功能可通过运行于处理器上的程序而实现,也可以通过具体的逻辑电路而实现。需要说明的是:上述实施例提供的数据查询装置600在进行数据查询时,仅以上述各程序单元的划分进行举例说明,实际应用中,可以根据需要而将上述处理分配由不同的程序单元完成,即将系统的内部结构划分成不同的程序单元,以完成以上描述的全部或者部分处理。另外,上述实施例提供的数据查询装置600与数据查询方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
下面以具体的应用示例对本公开所述的数据查询方法、装置做进一步描述。
本公开应用示例的应用场景为用户使用Kibana数据查询平台的client对Elasticsearch数据库和OLAP数据库进行数据查询。
如图7所示,图7为本公开应用示例提供的数据查询方法的原理框图。本公开应用示例提供的数据查询方法,由代理单元(elasticsearch-proxy)执行,所述的elasticsearch-proxy可以通过运行于处理器上的程序、软件、软件模块、脚本或代码的形式实现,按任意形式的编程语言(包括编译或解释语言,或者声明性或过程性语言)来编写,并且其可按任意形式部署,包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
如图8所示,所述elasticsearch-proxy的部署步骤为:
步骤801:配置elasticsearch-proxy;
具体的,elasticsearch-proxy的配置包括:elasticsearch-proxy在运行时拦截Kibana server发到Elasticsearch的查询请求,拦截的过程中需要从所述查询请求中区分出查询OLAP数据库的请求。因此在elasticsearch-proxy中需要配置OLAP数据库的数据表对应Elasticsearch的index名称列表。同时,也需要在elasticsearch-proxy中配置OLAP数据库、Elasticsearch的地址以及监听的端口。
步骤802:启动elasticsearch-proxy;
步骤803:配置Kibana server中elasticsearch-proxy的地址;
具体的,将Kibana server中的Elasticsearch地址和端口配置修改为elasticsearch-proxy的地址和端口。实际应用中,与Elasticsearch相同,elasticsearch-proxy可以部署多个节点。在Kibana请求压力大的情况下,可以横向扩展elasticsearch-proxy做负载均衡,同时也可以保证运行环境的高可用。在elasticsearch-proxy多个节点的情况下,只需要在Kibana后端的elasticsearch.hosts配置中把elasticsearch-proxy的节点都配置到数组中。
步骤804:重启Kibana server;
步骤805:在Elasticsearch中创建OLAP数据库中的数据表对应Elasticsearch的index名称列表;
步骤806:在Kibana页面创建所述index名称列表对应的数据视图(DataView)。
具体的,因为Kibana的元数据是从Elasticsearch加载的,OLAP数据库中的数据表如果需要在Kibana中可见,还需要在Kibana创建一个数据视图(DataView)与Elasticsearch中的index名称列表关联。
如图9所示,本公开应用示例提供的数据查询方法,包括以下步骤:
步骤901:elasticsearch-proxy启动监听端口;
具体的,elasticsearch-proxy从配置信息中读取监听端口配置(listen.port),监听Kibana server发到Elasticsearch的第一查询请求。
步骤902:elasticsearch-proxy解析所述第一查询请求,并判断所述第一查询请求是否查询OLAP数据库;若所述第一查询请求查询OLAP数据库,则进入步骤9031;若所述第一查询请求不查询OLAP数据库,则进入步骤9032;
其中,所述elasticsearch-proxy解析所述第一查询请求,具体以以下方式实现:
所述elasticsearch-proxy定时刷新配置,并从配置中读取OLAP数据库的数据表映射到Elasticsearch的索引名称列表。所述elasticsearch-proxy基于所述第一查询请求对应的URL中的index名称判断所述第一查询请求是否查询OLAP数据库。
步骤9031:elasticsearch-proxy根据所述第一查询请求,获取与所述OLAP数据库查询格式对应的至少一个第二查询请求;
具体的,所述Kibana client通过所述Kibana server发出的所述第一查询请求的类型分为数据查询(data query)和聚合查询(aggregation query)。聚合查询分为指标聚合查询(metric aggregation query)和分桶聚合查询(bucket aggregation query)。指标聚合查询指查询至少一种数据的某些指标,比如查询过滤后数据的最大值(max)、最小值(min)或者平均值(avg)等指标。分桶聚合查询指按照一定的规则将至少一种数据再拆分成多种。分桶完成之后的数据可以再做指标聚合查询,或者过滤,甚至可以继续分桶。
无论是数据查询还是聚合查询,其对应的查询语句中均有关键字作为标识,按照Elasticsearch文档关于查询语法的描述,我们可以根据所述第一查询请求中不同的关键字来区分出所述第一查询请求中的不同查询命令。比如:
过滤条件查询:如果所述第一查询请求中的关键字包含match和bool(must/must_not/should/filter)结构,则表示所述第一查询请求中这部分内容是过滤条件的部分,即对应到OLAP SQL的where语句部分。
排序查询:如果所述第一查询请求中的关键字包含sort结构,则把所述第一查询请求中这部分内容转换为排序,即对应到OLAP SQL的order by语句部分。
数据查询:如果所述第一查询请求中的关键字size大于0或者不存在aggs关键字,则判断所述第一查询请求要做hits查询,同时size个数解析为limit数。然后再根据_source或者fields字段判断所述第一查询请求要查询的字段。_source取所有字段,fields取部分字段。_source和fields在一个查询请求中也会同时出现。
聚合查询:如果所述第一查询请求中的关键字包含aggs关键字,则判断所述第一查询请求为聚合查询。聚合查询包含查询名称、查询方法和查询定义。定义聚合查询模板时除了以上查询名称、查询方法和查询定义的转换,还需要增加标识信息,以便定位该查询在Elasticsearch查询中的顺序和层级。解析聚合查询的时,根据查询方法判断查询是指标聚合查询还是分桶聚合查询。比如关键字中包含avg、min等,则判断查询是指标聚合查询,关键字中包含terms、range等,则判断查询是分桶聚合查询。
需要注意的是Elasticsearch查询是非常灵活的,一个Elasticsearch查询中可以同时存在数据查询和多个聚合查询,聚合查询中的分桶聚合查询也可以出现多个层级。所述elasticsearch-proxy基于所述第一查询请求解析出的至少一个查询命令中的每个查询命令都可以转换为一个SQL语句,所以所述第一查询请求最终可能会转换为OLAP SQL中的多个查询。
即预定义不同查询类型对应的所述OLAP数据库的查询模板;
基于所述OLAP数据库的查询模板,将所述至少一个查询命令渲染为与所述OLAP数据库查询格式对应的至少一个第二查询请求。
步骤9032:elasticsearch-proxy查询所述Elasticsearch,并进入步骤905;
步骤904:elasticsearch-proxy根据所述至少一个第二查询请求获取所述OLAP数据库的至少一个查询结果;
由于所述第二查询请求是由对应于所述OLAP数据库的查询模板渲染的,因此,所述第二查询请求可以直接从所述OLAP数据库得到查询结果,且每个查询结果均携带有标识信息。
步骤905:elasticsearch-proxy根据所述第一查询请求对应的查询结果格式,合并所述至少一个查询结果并发送给所述Kibana client。
其中,合并至少一个查询结果时,需要基于每个查询结果的标识信息,根据所述标识信息指示的每个查询结果对应的顺序和层级合并。
具体的,基于所述Elasticsearch的查询结果模板,将所述至少一个查询结果渲染为所述第一查询请求对应的查询结果格式;根据所述渲染后的所述至少一个查询结果中的每个查询结果的标识信息,确定所述渲染后的所述至少一个查询结果中的每个查询结果在所述第一查询请求中的顺序和层级;根据所述渲染后的所述至少一个查询结果中的每个查询结果在所述第一查询请求中的顺序和层级,合并所述至少一个查询结果并发送给所述Kibana client。
实际应用中,本公开应用示例提供的数据查询方法,可以使用同步调用的格式实现,也可使用异步消息机制实现。具体的:
如图10所示,利用同步调用格式实现本公开应用示例提供的数据查询方法,包括以下步骤:
步骤1001:启动监听端口;
具体的,监听由Kibana client通过Kibana server发出的Elasticsearch Query,即第一查询请求;
步骤1002:匹配OLAP数据库查询,进行后续处理;
具体的,判断所述Elasticsearch Query是否查询OLAP数据库;
步骤1003:解析Elasticsearch Query,返回查询模型;
所述查询模型用于Elasticsearch Query转换为对应于OLAP SQL;
步骤1004:递归转换查询模型到一个或者多个OLAP SQL,同时返回查询结果;
步骤1005:将所有的结果都返回,将所有的结果按照Elasticsearch结果的格式组装到一起,返回Kibana client。
异步消息机制在查询压力大的情况下具有更高并行度。异步消息机制可以使用线程池执行,每个执行器都可以启动一个线程池处理。也可以使用Actor模型处理,例如Akka或者Vert.x框架, Actor模型可以将同一流程中的各个消息做并行分布式处理,并且可以持久化消息状态,具有更高的并行度和可用性。
由于异步消息机制需要定义任务的执行器和消息,因此定义代理监听器、查询解析器、OLAP数据查询器和结果组装器,并定义[消息1:Elasticsearch查询]、[消息2:查询任务]、[消息3: 查询任务结果]、[消息4: 查询结果列表]和[消息5:拼装结果]。
如图11所示,利用异步消息机制实现本公开应用示例提供的数据查询方法,包括以下步骤:
步骤1101:代理监听器监听Kibana server发出的第一查询请求并过滤出OLAP数据库查询,将过滤出的查询语句封装为[消息1:Elasticsearch查询]传递给查询解析器;
步骤1102:查询解析器解析[消息1:Elasticsearch查询],转换为OLAP查询语句,封装为[消息2:查询任务]传递给OLAP数据查询器;
步骤1103:OLAP数据查询器处理查询任务,连接OLAP数据库查询返回查询结果,组装成[消息3: 查询任务结果]返回到查询解析器;
步骤1104:所有的[消息2:查询任务]都返回[消息3:查询任务结果]之后,将[消息3:查询任务结果]组装成[消息4:查询结果列表]传递给结果组装器;
步骤1105:结果组装器以Elasticsearch的结果格式为模板将[消息4: 查询结果列表]组装为[消息5:拼装结果]返回给查询解析器;
步骤1106:查询解析器将[消息5:拼装结果]直接返回给代理监听器;
步骤1107:代理监听器将[消息5:拼装结果]中的结果字符串取出放入查询结果,返回到Kibana server。
综上,本申请应用示例提供的数据查询方法,具备以下优点:
首先,研发成本低;因为Elasticsearch接口文档很详细,Elasticsearch版本官方也能保证接口查询语法的兼容性,并且官方也提供Java语言的语法解析库,因此解析Elasticsearch的查询工作较小,并且能保证很好的兼容性;
其次,运维成本低;如果现有环境中已存在Kibana,可以继续复用当前的Kibana,并不需要重新部署Kibana,对现有架构影响小。只需要修改现有环境的Kibana server的配置信息即可。
再次,Kibana更新升级方便:因为没有针对Kibana做修改或者请求拦截处理,所以不会影响Kibana升级。
再次,用户交互一致性高;因为使用原生的Kibana,因此在交互上可以和原生Kibana保持一致。
再次,elasticsearch-proxy通用性好;elasticsearch-proxy不仅能够应用于Kibana查询分析数据的场景,如果其他应用原本是查询的Elasticseach数据,现在想同时查询其他OLAP数据,也可以使用elasticsearch-proxy。
基于本公开所述的数据查询装置600中程序单元的硬件实现,且为了实现本公开实施例提供的数据查询方法,本公开还提供了一种电子设备1200。如图12所示,图12为本公开实施例提供的电子设备的组成示意图,所述电子设备1200,包括:处理器1201和存储器1202,该存储器1202用于存储计算机程序,所述处理器1201用于调用并运行所述存储器1202中存储的计算机程序,执行如本公开实施例提供的数据查询方法的步骤。
实际应用时,如图12所示,所述电子设备1200中的各个组件通过总线模块1203耦合在一起。可理解,总线模块1203用于实现这些组件之间的连接通信。总线模块1203除包括数据总线之外,还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见,在图12中将各种总线都标为总线模块1203。
本公开实施例还提供一种存储有计算机指令的非瞬时计算机可读存储介质,所述计算机指令被所述计算机执行时,实现本公开实施例提供的数据查询方法的步骤。
在一些实施例中,计算机可读存储介质可以是磁性随机存取存储器(Ferromagnetic Random Access Memory,简称FRAM)、只读存储器(Read Only Memory,简称ROM)、可编程只读存储器(Programmable Read-Only Memory,简称PROM)、可擦除可编程只读存储器(Erasable Programmable Read-Only Memory,简称EPROM)、电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory,简称EEPROM)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(Compact Disc Read-OnlyMemory,简称CD-ROM)等存储器;也可以是包括上述存储器之一或任意组合的各种设备。
在一些实施例中,计算机指令可以采用程序、软件、软件模块、脚本或代码的形式,按任意形式的编程语言(包括编译或解释语言,或者声明性或过程性语言)来编写,并且其可按任意形式部署,包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。作为示例,计算机指令可以但不一定对应于文件系统中的文件,可以被存储在保存其它程序或数据的文件的一部分,例如,存储在超文本标记语言(Hyper Text Markup Language,简称HTML)文档中的一个或多个脚本中,存储在专用于所讨论的程序的单个文件中,或者,存储在多个协同文件(例如,存储一个或多个模块、子程序或代码部分的文件)中。作为示例,计算机指令可被部署为在一个计算设备上执行,或者在位于一个地点的多个计算设备上执行,又或者,在分布在多个地点且通过通信网络互连的多个计算设备上执行。
需要说明的是,本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
在本说明书的描述中,参考术语“一个实施方式”、“一些实施方式”、“示意性实施方式”、“示例”、“具体示例”或“一些示例”等的描述意指结合实施方式或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施方式或示例中。在本说明书中,对上述术语的示意性表述不一定指的是相同的实施方式或示例。而且,描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施方式或示例中以合适的方式结合。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为,表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分,并且本发明的优选实施方式的范围包括另外的实现,其中可以不按所示出或讨论的顺序,包括根据所涉及的功能按基本同时的方式或按相反的顺序,来执行功能,这应被本发明的实施例所属技术领域的技术人员所理解。
在流程图中表示或在此以其他方式描述的逻辑和/或步骤,例如,可以被认为是用于实现逻辑功能的可执行指令的定序列表,可以具体实现在任何计算机可读介质中,以供指令执行系统、装置或设备(如基于计算机的系统、包括处理模块的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用,或结合这些指令执行系统、装置或设备而使用。
应当理解,本发明的实施方式的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中,多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如,如果用硬件来实现,和在另一实施方式中一样,可用本领域公知的下列技术中的任一项或他们的组合来实现:具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路,具有合适的组合逻辑门电路的专用集成电路,可编程门阵列(PGA),现场可编程门阵列(FPGA)等。
本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成,程序可以存储于一种计算机可读存储介质中,该程序在执行时,包括方法实施例的步骤之一或其组合。
此外,在本发明的各个实施例中的各功能单元可以集成在一个处理模块中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。上述提到的存储介质可以是只读存储器,磁盘或光盘等。
尽管上面已经示出和描述了本发明的实施方式,可以理解的是,上述实施方式是示例性的,不能理解为对本发明的限制,本领域的普通技术人员在本发明的范围内可以对上述实施实施进行变化、修改、替换和变型。

Claims (9)

1.一种数据查询方法,其特征在于,包括:
拦截目标终端向第一数据库发送的第一查询请求;
解析所述第一查询请求,以确定所述第一查询请求是否查询第二数据库;所述第二数据库为关系型数据库或非关系型数据库;
若确定查询所述第二数据库,则根据所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求;
根据所述至少一个第二查询请求获取所述第二数据库的至少一个查询结果;
基于所述第一数据库的查询结果模板,将所述至少一个查询结果渲染为所述第一查询请求对应的查询结果格式;其中,渲染后的所述至少一个查询结果中的每个查询结果均携带有标识信息,所述标识信息用于指示其对应的所述第二查询请求在所述第一查询请求中的顺序和层级;
根据所述渲染后的所述至少一个查询结果中的每个查询结果的标识信息,确定所述渲染后的所述至少一个查询结果中的每个查询结果在所述第一查询请求中的顺序和层级;
根据所述渲染后的所述至少一个查询结果中的每个查询结果在所述第一查询请求中的顺序和层级,合并所述至少一个查询结果并发送给目标终端。
2.根据权利要求1所述的方法,其特征在于,所述解析所述第一查询请求,以确定所述第一查询请求是否查询第二数据库,包括:
解析所述第一查询请求中的统一资源定位符URL,获取所述URL中的索引index名称;
基于所述第二数据库的数据表与所述第一数据库的index名称列表的映射关系,确定所述第一查询请求是否查询第二数据库。
3.根据权利要求1所述的方法,其特征在于,所述根据所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求,包括:
判断所述第一查询请求是否为结构化查询语言SQL查询格式;
若是,则基于所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求;
若否,则将所述第一查询请求转换为SQL查询格式的至少一个查询命令;并根据所述至少一个查询命令,获取与所述第二数据库查询格式对应的至少一个第二查询请求。
4.根据权利要求3所述的方法,其特征在于,所述将所述第一查询请求转换为SQL查询格式的至少一个查询命令,包括:
基于所述第一数据库的查询语法,根据所述第一查询请求中的关键字信息,确定至少一个查询命令。
5.根据权利要求3所述的方法,其特征在于,所述根据所述至少一个查询命令,获取与所述第二数据库查询格式对应的至少一个第二查询请求,包括:
基于所述第二数据库的查询模板,将所述至少一个查询命令渲染为与所述第二数据库查询格式对应的至少一个第二查询请求;其中,所述至少一个第二查询请求中的每个查询请求均携带有标识信息,所述标识信息用于指示其对应的所述第二查询请求在所述第一查询请求中的顺序和层级。
6.根据权利要求1至5中任一项所述的方法,其特征在于,还包括:
构建第二数据库的数据表与所述第一数据库的index名称列表的映射关系。
7.一种数据查询装置,其特征在于,包括:
拦截模块,用于拦截目标终端向第一数据库发送的第一查询请求;
解析模块,用于解析所述第一查询请求,以确定所述第一查询请求是否查询第二数据库;
第一获取模块,用于若确定查询所述第二数据库,则根据所述第一查询请求,获取与所述第二数据库查询格式对应的至少一个第二查询请求;
第二获取模块,用于根据所述至少一个第二查询请求获取所述第二数据库的至少一个查询结果;
发送模块,用于基于所述第一数据库的查询结果模板,将所述至少一个查询结果渲染为所述第一查询请求对应的查询结果格式;其中,渲染后的所述至少一个查询结果中的每个查询结果均携带有标识信息,所述标识信息用于指示其对应的所述第二查询请求在所述第一查询请求中的顺序和层级;
根据所述渲染后的所述至少一个查询结果中的每个查询结果的标识信息,确定所述渲染后的所述至少一个查询结果中的每个查询结果在所述第一查询请求中的顺序和层级;
根据所述渲染后的所述至少一个查询结果中的每个查询结果在所述第一查询请求中的顺序和层级,合并所述至少一个查询结果并发送给目标终端。
8.一种电子设备,其特征在于,包括:
处理器和存储器,该存储器用于存储计算机程序,所述处理器用于调用并运行所述存储器中存储的计算机程序,执行如权利要求1至6中任一项所述的方法的步骤。
9.一种存储有计算机指令的非瞬时计算机可读存储介质,其特征在于,所述计算机指令用于使所述计算机执行如权利要求1至6中任一项所述的方法的步骤。
CN202310856225.6A 2023-07-13 2023-07-13 数据查询方法、装置、电子设备及存储介质 Active CN116578585B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310856225.6A CN116578585B (zh) 2023-07-13 2023-07-13 数据查询方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310856225.6A CN116578585B (zh) 2023-07-13 2023-07-13 数据查询方法、装置、电子设备及存储介质

Publications (2)

Publication Number Publication Date
CN116578585A CN116578585A (zh) 2023-08-11
CN116578585B true CN116578585B (zh) 2023-09-19

Family

ID=87541715

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310856225.6A Active CN116578585B (zh) 2023-07-13 2023-07-13 数据查询方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN116578585B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117407428B (zh) * 2023-11-21 2024-04-19 杭州沃趣科技股份有限公司 一种获取目标数据库的目标配置文件的数据处理系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112905595A (zh) * 2021-03-05 2021-06-04 腾讯科技(深圳)有限公司 一种数据查询方法、装置及计算机可读存储介质
CN113688148A (zh) * 2021-07-13 2021-11-23 交控科技股份有限公司 城轨数据查询方法、装置、电子设备及可读存储介质
CN115525671A (zh) * 2022-09-02 2022-12-27 上海奇夜语网络科技有限公司 数据查询方法、装置、设备及存储介质
CN116166700A (zh) * 2023-02-01 2023-05-26 阿里云计算有限公司 查询方法、装置、系统、电子设备及存储介质
WO2023116086A1 (zh) * 2021-12-23 2023-06-29 北京百度网讯科技有限公司 数据查询方法、装置、电子设备以及存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112559567A (zh) * 2020-12-10 2021-03-26 跬云(上海)信息科技有限公司 适用于olap查询引擎的查询方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112905595A (zh) * 2021-03-05 2021-06-04 腾讯科技(深圳)有限公司 一种数据查询方法、装置及计算机可读存储介质
CN113688148A (zh) * 2021-07-13 2021-11-23 交控科技股份有限公司 城轨数据查询方法、装置、电子设备及可读存储介质
WO2023116086A1 (zh) * 2021-12-23 2023-06-29 北京百度网讯科技有限公司 数据查询方法、装置、电子设备以及存储介质
CN115525671A (zh) * 2022-09-02 2022-12-27 上海奇夜语网络科技有限公司 数据查询方法、装置、设备及存储介质
CN116166700A (zh) * 2023-02-01 2023-05-26 阿里云计算有限公司 查询方法、装置、系统、电子设备及存储介质

Also Published As

Publication number Publication date
CN116578585A (zh) 2023-08-11

Similar Documents

Publication Publication Date Title
CN107506451B (zh) 用于数据交互的异常信息监控方法及装置
CN107133267B (zh) 查询elasticsearch集群的方法、装置、电子设备和可读存储介质
EP2616965B1 (en) Support for a parameterized query/view in complex event processing
US9930113B2 (en) Data retrieval via a telecommunication network
US11487742B2 (en) Consistency checks between database systems
CN114357276A (zh) 数据查询方法、装置、电子设备以及存储介质
CN116578585B (zh) 数据查询方法、装置、电子设备及存储介质
CN109284469B (zh) 网页开发框架
CN113962597A (zh) 一种数据分析方法、装置、电子设备及存储介质
CN110580170B (zh) 软件性能风险的识别方法及装置
CN117271584A (zh) 数据处理方法及装置、计算机可读存储介质和电子设备
CN116561208A (zh) 一种统一OpenAPI查询接口的方法、装置和设备
KR20100132752A (ko) 데이터베이스 분산을 통한 서비스 성능 향상을 위한 질의 데이터 분산 처리시스템
CN111694846A (zh) 一种基于Type 2 JDBC驱动的分离模式分布式存储过程实现方法
US11550556B1 (en) Efficient semantic analysis of program code
CN114064601B (zh) 存储过程转换方法、装置、设备和存储介质
CN114281842A (zh) 一种数据库分表查询的方法及设备
CN113010483A (zh) 一种海量日志管理方法和系统
EP2990960A1 (en) Data retrieval via a telecommunication network
CN113836164A (zh) 统一sql的方法、系统、设备及介质
CN115952203B (zh) 数据查询方法、设备、系统及存储介质
WO2020238597A1 (zh) 基于Hadoop的数据更新方法、装置、系统及介质
CN116795663B (zh) 一种跟踪分析trino引擎执行性能的方法
CN113157726B (zh) 一种数据库的处理方法及装置
CN115563183B (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
GR01 Patent grant
GR01 Patent grant