CN112115150A

CN112115150A - 嵌入式内存数据库的数据管理方法、终端设备及介质

Info

Publication number: CN112115150A
Application number: CN202010768721.2A
Authority: CN
Inventors: 左若愚; 宫耀东; 夏之春; 朱鸿斌
Original assignee: Shanghai Kingstar Fintech Co Ltd
Current assignee: Shanghai Kingstar Fintech Co Ltd
Priority date: 2020-08-03
Filing date: 2020-08-03
Publication date: 2020-12-22
Anticipated expiration: 2040-08-03
Also published as: CN112115150B

Abstract

本申请适用于数据库技术领域，提供了一种嵌入式内存数据库的数据管理方法、终端设备及介质，所述方法包括：启动所述嵌入式内存数据库，并获取所述内存数据库中的结构化查询语言SQL引擎动态库的第一配置信息；加载与所述第一配置信息对应的SQL插件，建立第一SQL引擎；向所述第一SQL引擎发送SQL指令，以指示所述第一SQL引擎访问所述嵌入式内存数据库并在所述嵌入式内存数据库中执行所述SQL指令，获得执行结果；接收所述第一SQL引擎返回的所述执行结果。通过上述方法，可以在嵌入式内存数据库中实现标准SQL功能。

Description

嵌入式内存数据库的数据管理方法、终端设备及介质

技术领域

本申请属于数据库技术领域，尤其涉及一种嵌入式内存数据库的数据管理方法、终端设备及介质。

背景技术

内存数据库因其相较于使用磁盘存储的传统数据库，在数据的存取上有高出数个数量级的性能优势，而在各类内存数据库的细分领域中，嵌入式内存数据库作为能达到极致性能的一类，近年来在各类对活动事务有极高性能要求的技术领域得到了大量应用，如电信实时计费系统，程控电话交换机，证券类实时在线交易系统，工业物联网的实时数据采集系统如国家电网等，均有嵌入式内存数据库在其中充当着数据存取和处理的重要角色。与此同时，由于内存库数据在其发展过程中本身的特性以及其应用场景的特殊性，各类内存数据库仅对应用程序提供原生的数据读写编程接口，通常并不具备使用通用接口如结构化数据查询语言(StructuredQueryLanguage，SQL)访问数据的能力。

而极少数具备SQL查询能力的内存数据库，其SQL引擎是在限制或削减了标准SQL的大量功能，以及SQL引擎在运行时由自身所引入的巨大开销的基础上实现的。这使得在多业务混合的系统场景中，需要读写内存库数据的同时又对SQL依赖程度不高的部分业务，必须面临诸如系统设计过程中的解耦度下降，系统资源浪费等问题。

发明内容

本申请实施例提供了一种嵌入式内存数据库的数据管理方法、终端设备及介质，可以解决目前嵌入式内存数据库不具备完整的SQL功能的问题。

第一方面，本申请实施例提供了一种嵌入式内存数据库的数据管理方法，包括：

启动所述嵌入式内存数据库，并获取所述内存数据库中的结构化查询语言SQL引擎的第一配置信息；

加载与所述第一配置信息对应的SQL引擎插件，建立第一SQL引擎；

向所述第一SQL引擎发送SQL指令，以指示所述第一SQL引擎访问所述嵌入式内存数据库并在所述嵌入式内存数据库中执行所述SQL指令，获得执行结果；

接收所述第一SQL引擎返回的所述执行结果。

第二方面，本申请实施例提供了一种嵌入式内存数据库的数据管理装置，包括：

第一配置信息获取模块，用于启动所述嵌入式内存数据库，并获取所述内存数据库中的结构化查询语言SQL引擎的第一配置信息；

第一SQL引擎建立模块，用于加载与所述第一配置信息对应的SQL引擎插件，建立第一SQL引擎；

SQL指令发送模块，用于向所述第一SQL引擎发送SQL指令，以指示所述第一SQL引擎访问所述嵌入式内存数据库并在所述嵌入式内存数据库中执行所述SQL指令，获得执行结果；

结果接收模块，用于接收所述第一SQL引擎返回的所述执行结果。

第三方面，本申请实施例提供了一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面所述的方法。

第五方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面所述的方法。

本申请实施例与现有技术相比存在的有益效果是：在本申请实施例中，核心进程启动后，启动嵌入式内存数据库，所述内存数据库中的包含了是否启动SQL以及启动哪些SQL引擎插件的配置信息；根据该配置信息，核心进程可以决定是否加载SQL引擎插件；若需要加载SQL引擎插件，则根据配置信息加载SQL引擎插件，组成第一SQL引擎，第一SQL引擎能提供SQL所具备的功能，核心进程或系统的其他应用可以采用第一SQL引擎对嵌入式内存数据库采用SQL语句进行数据存取和数据更新。若根据启动选项中的配置信息，不需要启动SQL时，则系统可以通过嵌入式内存数据库提供的原生接口进行数据存取和数据更新。在本申请中，使用SQL引擎插件对SQL进行动态加载，为用户和应用程序提供了使用SQL语句对嵌入式内存数据库的数据访问能力，且动态加载SQL引擎插件，可以按照需要对SQL引擎进行加载，在实现标准SQL的功能的同时，不影响嵌入式内存数据库本身所具备的轻量，高效，低消耗的优势。

附图说明

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

图1是本申请实施例一提供的一种嵌入式内存数据库的数据管理方法的流程示意图；

图2是本申请实施例二提供的一种嵌入式内存数据库的数据管理方法的流程示意图；

图3是本申请实施例三提供的一种嵌入式内存数据库的数据管理方法的流程示意图；

图4是本申请实施例四提供的一种嵌入式内存数据库的数据管理方法的流程示意图；

图5是本申请实施例五提供的一种嵌入式内存数据库的数据管理装置的结构示意图；

图6是本申请实施例六提供的一种终端设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其他实施例中也可以实现本申请。在其他情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其他特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

图1是本申请实施例一提供的一种嵌入式内存数据库的数据管理方法的流程示意图，如图1所示，所述方法包括：

S101，启动所述嵌入式内存数据库，并获取所述内存数据库中的结构化查询语言SQL引擎的第一配置信息；

本申请实施例提供的方法可以应用于终端设备，上述终端设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备，本申请实施例对终端设备的具体类型不作任何限制。本申请的执行主体为终端设备，具体可以为终端设备中的处理器。

上述第一配置信息为所述内存数据库中的是否启动SQL以及启动哪些SQL引擎插件的参数，嵌入式内存数据库可以通过启动编程接口读取这些参数。核心进程即为系统的宿主进程。

嵌入式内存数据库本身提供了一些用于数据存取的原生接口，通过这些原生接口，系统和应用能够访问嵌入式内存数据库，并对数据进行存取和数据更新。一些情况下，只需要对数据库中数据进行简单的读取操作，此时，可以只采用这些原生接口进行数据管理。但是一些情况下，由于业务的逐渐增长，相关系统的逐渐演进，系统开发人员及运维人员使用SQL访问内存数据库中数据更为方便，SQL作为声明式的标准数据访问方式，其在易学性，便捷性，可操作性上无疑是远远优于直接使用内存库提供的原生C/C++编程接口的。因此，在需要对数据库中数据进行复杂的存取更新时，可以选择使用SQL。

在一个系统中，系统的宿主程序的开发人员可以判断是否需要启用SQL以及需要使用哪些SQL，然后将这些配置信息写入内存数据库中，嵌入式内存数据库的启动接口函数可以接收该启动选项的参数，来决定是否启用SQL以及启用SQL引擎插件中的哪些模块。

通常情况下，数据库的SQL引擎主要由SQL解释器，查询优化器，代码生成器，查询执行器等组成，此外还包括一些辅助的功能模块如元数据存储及管理，查询缓存，统计信息管理等。SQL引擎以插件形式在系统中运行，其中SQL引擎插件可以包括多个子插件，比如查询优化器子插件。一般地，SQL引擎中需要包括SQL解释器和查询执行器，因此一般若需要启动SQL时，均需启动由SQL解释器和查询执行器组成的子插件。

在核心进程启动期间，启动嵌入式内存数据库，嵌入式内存数据库的启动接口函数可以接收内存数据库中的参数。

在一种可能的实现方式中，配置信息中可以采用字段enable表示是否启用SQL引擎，采用optimization字段表示是否需要引擎对SQL语句做查询优化。查询优化器仅在对多表连接查询，复杂子查询，或包含聚合运算的查询进行优化时，会取得较高收益，对一般的简单查询的优化收益并不高，而查询优化器的存在又可能对以嵌入式架构运行的内存库带来难以预计的系统资源抖动。鉴于此，插件式的SQL执行器，给系统架构师，系统开发人员，系统运维人员等，在系统的设计，开发，运维等过程中均提供了自主的选择，如针对不具有复杂查询和大量计算任务的子系统或模块，或对查询效率不敏感的模块等，可选择不启用查询优化器对查询语句进行优化，而是简单地让其编译并执行。

S102，加载与所述第一配置信息对应的SQL引擎插件，建立第一SQL引擎；

具体地，第一配置信息中可以包括是否启用SQL以及加载SQL引擎插件的哪些子插件。根据第一配置信息，可以动态加载SQL引擎插件，在加载完SQL引擎插件后，需要对其中的元数据进行初始化。

若需要启用SQL，则需要加载SQL引擎，即需要加载SQL解释器和查询执行器。通过系统调用dlopen函数动态加载SQL引擎模块，加载完成后则初始化内存库的元数据，查询缓存区等。若启动选项还指明需要查询优化器，则加载查询优化器模块，并在加载完成后首次执行数据统计任务，统计嵌入式内存数据库中存储的数据的分布情况，索引信息等，便于进行之后的查询优化。

另外，第一配置信息中还可以包括统计数据存储路径、非持久化统计数据是私有还是共享等信息，根据这些信息，可以配置统计数据存储路径以及非持久化统计数据的存储区域。将统计数据存放在共享内存区时，可供其他独立运行的模块如监控子系统等启用SQL引擎时使用。例如，第一配置信息中可以包括如下信息：

[SQL]

//是否启用SQL

enable＝1

//是否启用查询优化

optimization＝1

//是否持久化存储统计信息

persist_statistics＝1

//统计数据存储路径

persist_statistic_dir＝/usr/lib/ksmdb

//非持久化统计数据是私有还是共享

statistic_sharing＝true

当宿主进程启动时，若SQL引擎以及查询优化器被设置为需挂载(enable＝1，optimization＝1)，则配置读取过程将继续检查persist_statistics等配置项，若该项为“1”，则统计数据将被存储在persist_statistics_dir项所指向的目录下，若该项不为“1”，则检查statistic_sharing项以决定是将统计数据放入共享内存区还是放在进程私有内存区。

在一种可能的实现方式中，当enable为0时，即不启用SQL，此时[SQL]域中其他所有字段均被忽略。当enable为1时，即启用SQL，此时可以加载SQL引擎，即加载SQL解释器和执行器。当optimization为0时，不需要使用从查询优化器，若optimization为1，则需要加载查询优化器。

在另一种可能的实现方式中，也可以采用一个字段表示是否需要启动SQL；然后分别为SQL解释器插件，查询优化器插件，代码生成器插件，查询执行器设置一个变量，对应的变量值可以反映是否需要加载该插件。当然，还可以包括其他插件。

另外，系统中独立运行的其他非核心业务模块，如运维，监控等，也可以在进程启动时通过读取进程的配置信息来决定是否启用SQL以及启用哪些SQL，而此时的内存库已经处于运行期。

S103，向所述第一SQL引擎发送SQL指令，以指示所述第一SQL引擎访问所述嵌入式内存数据库并在所述嵌入式内存数据库中执行所述SQL指令，获得执行结果；

具体地，当建立起第一SQL引擎之后，核心进程可以利用第一SQL引擎进行数据存取。内存库宿主进程向第一SQL引擎发送SQL命令，第一SQL引擎根据接收到的SQL命令访问内存数据库，执行SQL命令，然后再将执行结果返回至内存数据库核心进程。

另外，系统的其他进程也可以通过该第一SQL引擎访问嵌入式内存数据库，采用SQL语句实现数据存取和更新。

S104，接收所述第一SQL引擎返回的所述执行结果。

系统核心进程接收SQL动态库集合所返回的执行结果，完成对嵌入式内存数据库的数据查询或数据更新。示例性地，第一SQL引擎接收到数据存储指令后，将数据根据配置好的存储路径存放在数据库中，并将执行结果返回给核心进程。第一SQL引擎接收到数据查询指令后，从数据库中查找对应的数据，并将查询结果返回给核心进程。

在本实施例中，嵌入式内存数据库可以根据内存数据库中的配置信息，选择是否启动SQL以及是否加载查询优化器，然后通过动态加载SQL引擎插件来建立SQL引擎，基于该SQL引擎实现在嵌入式内存数据库中采用SQL语句进行数据访问和数据存取，实现标准SQL功能，同时，动态加载插件的方式减少了需要消耗的内存资源，保持了嵌入式内存数据库本身具有的高效性。

图2是本申请实施例二提供的一种嵌入式内存数据库的数据管理方法的流程示意图，如图2所示，所述方法包括：

S201，通过所述嵌入式内存数据库的编程接口启动所述嵌入式内存数据库；

本申请实施例提供的方法可以应用于终端设备，上述终端设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备，本申请实施例对终端设备的具体类型不作任何限制。

具体地，系统核心进程在启动时，通过内存数据库提供的编程接口启动内存数据库实例。

S202，向操作系统申请共享内存区作为所述嵌入式内存数据库的数据存储区域，并初始化所述数据存储区域；

具体地，嵌入式内存数据库需要包括数据存储空间，因此可以向终端设备的操作系统申请共享内存区用于内存库的数据存储区域，并初始化内存库中所有对象，包括表，索引等。

S203，获取所述内存数据库中的结构化查询语言SQL引擎的第一配置信息；

具体地，内存数据库可以通过启动接口函数(Create或Open)接收启动选项中的配置信息，来决定是否启用SQL执行器以及启用哪些组件。

具体地，配置信息中可以采用字段enable表示是否启用SQL引擎，采用optimization字段表示是否需要引擎对SQL语句做查询优化。

通常情况下，系统的设计，开发，以及运维人员最为清楚其设计开发或运营的系统模块所涉及业务的数据读写场景，因而他们可以根据其业务数据读写场景的特定，来决定是否需要使用SQL，并将配置信息写入启动选项中。如证券类交易核心中，其对数据读写的要求是高效低延时的事务执行能力，内存库提供的原生C++接口提供的功能已经完全满足，且最为高效稳定，因而交易核心模块通常是不需要使用SQL的，此时系统的开发运维人员则可以将SQL配置项中的enable置为“0”，内存库便不会加载并启动SQL引擎。而如果需要访问数据的是实时报表或系统运维监控等以读和分析计算为主的模块，则使用SQL是最为方便的，且这类业务中可能出现的大量多表查询，以及带有聚合运算的查询语句等，则是需要SQL查询优化器的介入来极大地提高查询效率，因而这种情况下，开发运维人员可以将SQL配置项中enable和optimization同时置为“1”来使用SQL进行查询。

S204，依次读取所述插件配置值；

具体地，第一配置信息中包括SQL引擎插件的插件配置值。SQL引擎集合中可以为各个子插件均在代码中设置一个变量名，然后根据变量值来确定是否加载插件。示例性地，若变量值为0，则不需要加载该SQL插件；若变量值为1，则需要加载该插件。一般地，SQL引擎即SQL解释器和查询执行器，为进行SQL查询所必需的组件，因此，SQL引擎对应的变量名的变量值可以表示是否需要启动SQL。若变量值为1，则需要启动SQL；若变量值为0，则不需要启动SQL。该变量值即为插件配置值。

具体地，通过编程接口读取内存数据库中的各个插件配置值，来确定是否需要启动SQL以及加载SQL引擎插件中的哪些子插件。

S205，加载所述插件配置值为第一数值的至少一个SQL引擎插件，所述至少一个SQL引擎插件组成所述第一SQL引擎；

上述第一数值可以为1。具体地，若插件配置值为1，则加载该插件；若插件配置值为0，则不需要加载该插件。

加载SQL引擎的实现方式具体可以如下：

另外，第一数值也可以选择其他字符串或者数值，可以自由设定。

S206，为所述第一SQL引擎建立对应的SQL接口；

具体地，为第一SQL引擎建立各个SQL接口，这些接口可以用于系统进程或应用使用SQL对数据库进行数据存取。例如，可以包括查询接口、结果返回接口、数据更新接口等等。

S207，通过所述SQL接口，向所述第一SQL引擎发送SQL指令，以指示所述第一SQL引擎访问所述嵌入式内存数据库并在所述嵌入式内存数据库中执行所述SQL指令，获得执行结果；

具体地，系统的核心进程可以通过SQL接口，向第一SQL引擎发送SQL指令，然后第一SQL引擎集合访问内存数据库，执行该SQL指令，获得执行结果。该SQL指令可以是数据的增删查改等任意的SQL标准功能所具有的指令。

S208，接收所述第一SQL引擎返回的所述执行结果。

具体地，第一SQL引擎集合执行完SQL指令后，将指定结果返回至核心进程，核心进程可以通过SQL接口获取SQL执行结果。

在本实施例中，根据是否需要SQL以及是否需要查询优化器，来决定SQL的插件配置值，根据SQL引擎插件配置值可以动态地加载需要的SQL引擎插件，减少嵌入式内存数据库的消耗，保持了内存数据库本身具有的轻量，高效，低消耗的优势，同时，又可以通过SQL语言对嵌入式内存数据库进行数据管理。

图3是本申请实施例三提供的一种嵌入式内存数据库的数据管理方法的流程示意图，如图3所示，所述方法包括：

S301，启动所述嵌入式内存数据库，并获取所述内存数据库中的结构化查询语言SQL引擎的第一配置信息；

S302，加载与所述第一配置信息对应的SQL引擎插件，建立第一SQL引擎；

S303，向所述第一SQL引擎发送SQL指令，以指示所述第一SQL引擎访问所述嵌入式内存数据库并在所述嵌入式内存数据库中执行所述SQL指令，获得执行结果；

S304，接收所述第一SQL引擎返回的所述执行结果；

本实施例中的S301-S304与前述实施例一中的S101-S104类似，可以相互参考，在此不赘述。

S305，当检测到所述第一SQL引擎的第一配置信息改变时，读取所述第一配置信息的改变信息；

具体地，SQL引擎插件一旦被挂载，可以在进程整个生命周期内始终作为整个宿主进程的一部分持续运行，为系统提供持续的通过SQL访问数据的能力，亦可由运维人员通过修改配置等手工操作进行插拔。

具体地，若需要对SQL引擎插件进行插拔时，可以更改内存数据库中SQL引擎插件的配置信息，因此终端设备可以检测SQL引擎插件的配置值，从而判断是否需要对SQL引擎插件进行拔插。

S306，若所述改变信息为所述插件配置值由第二数值变为第一数值，则加载所述插件配置值变更为所述第一数值的SQL引擎插件；

一般地，第一数值可以为1，第二数值可以为0，当然，也可以使用其他的字符串或者数值来表示是否需要拔插SQL引擎插件。

具体地，若某一插件的插件配置值由1变为0，则加载该SQL引擎插件，并初始化该SQL引擎插件所需要的数据。

S307，若所述改变信息为所述插件配置值由第一数值变为第二数值，则去除所述插件配置值变更为所述第二数值的SQL引擎插件。

若某一插件的插件配置值由0变为1，则去除该SQL引擎插件。

S308，启动内存库管理工具，并获取所述内存库管理工具所携带的SQL引擎的第二配置信息；

具体地，若系统核心进程启动时，并没有启动SQL，在系统运行过程中，SQL引擎也可以作为插件随内存库管理工具同时启动。内存库管理工具具有对应的第二配置信息，第二配置信息可以包括是否启动SQL引擎插件SQL引擎，以及可选择性的加载SQL引擎中哪几个具体的模块。

具体地，嵌入式内存数据库提供的独立运行的数据库管理工具(ksmdbmanage)启动时，可以读取内存库管理配置文件ksmdb.ini中的配置项，从而决定是否在该管理工具中启用SQL。一个典型的ksmdb.ini配置文件格式如下，其中[SQL]域即为SQL引擎相关配置，如字段enable即为是否启用SQL，optimization字段表示是否需要引擎对SQL语句做查询优化。当enable为0时，即不启用SQL，此时[SQL]域中其他所有字段均被忽略。

[SQL]

[SYSTEM]

//数据库名

name＝qzh

//数据文件所在路径

path＝.

//单位MB

size＝1000

//库结构对应的脚本

script＝itsmdb.script

port＝5000

remotewrite＝1

rwmode＝0

dbsesion_mode＝0

[SQL]

//是否启用SQL

enable＝1

//是否启用查询优化

optimization＝1

内存库管理工具启动后，可以获取内存库实例的共享内存句柄或网络连接句柄，而一旦SQL配置项enable被置为“1”，进程将通过获得内存数据库访问句柄，向对应的内存数据库实例申请并加载或计算SQL各组件所需的所有元数据或统计数据，统计数据需由查询优化器或独立的数据服务进程在第一次运行时扫描内存数据进行计算。

另外，当使用数据库管理工具ksmdbmanage启动SQL后，由于ksmdbmanage以远程接口的方式提供了跨进程跨网络的访问手段，这种方式相当于实现了SQL执行器插件以热插拔的形式运行于系统中，系统开发人员和运维人员可随时通过启动ksmdbmanage来对外提供SQL访问的途径，且需要用到SQL执行器的哪些功能和特性，均可以灵活的通过启动项选择加载或不加载而弹性地运行，实现运行期的系统资源开销可定制化。

S309，加载与所述第二配置信息对应的SQL引擎插件，建立第二SQL引擎，所述第二SQL引擎用于所述内存库管理工具对所述嵌入式内存数据库进行数据管理。

根据第二配置信息，加载对应的SQL引擎插件，然后采用第二SQL引擎可以实现对嵌入式内存数据库使用标准SQL功能。

本实施例中，系统启动时，可以根据启动选项决定是否启用SQL以及加载哪些SQL引擎插件；也可以在系统运行期间，由内存数据库提供的是独立运行的数据库管理工具启动时，根据配置信息决定是否启用SQL以及加载哪些SQL引擎插件，这两种方法都能够实现在嵌入式内存库中使用SQL语言进行数据存取；另外，当需要时，启动SQL，可以节省资源；动态地加载SQL引擎插件，能够使系统中只包括需要的SQL引擎插件，从而减少系统负担。

图4是本申请实施例四提供的一种嵌入式内存数据库的数据管理方法的流程示意图，如图4所示，本实施例中，可以用两种方法实现启动SQL。

第一种方法是通过核心进程启动。系统核心进程，即内存库的宿主进程，可以启动内存数据。在内存数据库启动过程中，判断是否需要SQL，若需要启用SQL，则动态加载各个SQL引擎插件形成SQL执行器动态库集合，SQL执行器动态库集合中可以包括SQL解释器(或编译器)、代码生成器、查询优化器以及查询执行器，但并不是每次都需要加载所有插件，可以根据需要动态加载SQL引擎插件。之后系统核心进程可以通过SQL执行器动态库集合进行SQL查询，当然也可以实现其他SQL功能。

第二种方法是在系统运行期，由内存库提供的独立运行的数据库管理工具启动时，可以读取内存库管理配置文件ksmdb.ini中的配置项，从而决定是否在该管理工具中启用SQL，若需要启用SQL，则动态加载各个SQL引擎插件形成SQL执行器动态库集合，从而各个客户端、远程程序以及系统的其他独立进程均可以通过内存库管理工具实现SQL查询。

在本实施例中，能够提供完整的SQL执行器，可以编译，优化，并执行SQL语句来为用户和应用程序提供在嵌入式内存数据库中的访问数据能力；且SQL执行器以插件形式存在，可以热插拔运行；SQL执行器自身的各组件所具有的可选择性，热插拔运行的特点，实现了SQL执行器的可配置化和轻量化；通过SQL执行器的插件式运行，可对系统模块按照对嵌入式内存数据库访问需求的轻重进行解耦，实现系统资源的弹性化管理。

图5是本申请实施例五提供的一种嵌入式内存数据库的数据管理装置5的结构示意图，如图5所示，所述装置5包括：

第一配置信息获取模块51，用于启动所述嵌入式内存数据库，并获取所述内存数据库中的结构化查询语言SQL引擎的第一配置信息；

第一SQL引擎建立模块52，用于加载与所述第一配置信息对应的SQL引擎插件，建立第一SQL引擎；

SQL指令发送模块53，用于向所述第一SQL引擎发送SQL指令，以指示所述第一SQL引擎访问所述嵌入式内存数据库并在所述嵌入式内存数据库中执行所述SQL指令，获得执行结果；

结果接收模块54，用于接收所述第一SQL引擎返回的所述执行结果。

上述第一配置信息获取模块51包括：

启动子模块，用于通过所述嵌入式内存数据库的编程接口启动所述嵌入式内存数据库；

内存数据库核心子模块，用于向操作系统申请共享内存区作为所述嵌入式内存数据库的数据存储区域，并初始化所述数据存储区域。

上述装置中，所述第一配置信息中包括多个插件配置信息，所述插件配置信息具有对应的插件配置值，所述第一SQL引擎建立模块52包括：

读取子模块，用于依次读取所述插件配置值；

加载子模块，用于加载所述插件配置值为第一数值的至少一个SQL引擎中的子模块，所述至少一个SQL引擎中的子模块组成所述第一SQL引擎；

接口建立子模块，用于为所述第一SQL引擎建立对应的SQL接口。

上述SQL指令发送模块53包括：

发送子模块，用于通过所述SQL接口，向所述第一SQL引擎发送SQL指令。

上述嵌入式内存数据库的数据管理装置5还包括：

改变信息读取模块，用于当检测到所述第一SQL引擎的第一配置信息改变时，读取所述第一配置信息的改变信息；

SQL引擎插件加载模块，用于若所述改变信息为所述插件配置值由第二数值变为第一数值，则加载所述插件配置值变更为所述第一数值的SQL引擎插件；

SQL引擎插件去除模块，用于若所述改变信息为所述插件配置值由第一数值变为第二数值，则去除所述插件配置值变更为所述第二数值的SQL引擎插件。

上述嵌入式内存数据库的数据管理装置5还包括：

第二配置信息获取模块，用于启动内存库管理工具，并获取所述内存库管理工具所携带的SQL引擎的第二配置信息；

第二SQL引擎建立模块，用于加载与所述第二配置信息对应的SQL引擎插件，建立第二SQL引擎，所述第二SQL引擎用于所述内存库管理工具对所述嵌入式内存数据库进行数据管理。

图6为本申请实施例六提供的一种终端设备的结构示意图。如图6所示，该实施例的终端设备6包括：至少一个处理器60(图6中仅示出一个)处理器、存储器61以及存储在所述存储器61中并可在所述至少一个处理器60上运行的计算机程序62，所述处理器60执行所述计算机程序62时实现上述任意各个方法实施例中的步骤。

所述终端设备6可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。该终端设备可包括，但不仅限于，处理器60、存储器61。本领域技术人员可以理解，图6仅仅是终端设备6的举例，并不构成对终端设备6的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备等。

所称处理器60可以是中央处理单元(CentralProcessingUnit，CPU)，该处理器60还可以是其他通用处理器、数字信号处理器(DigitalSignalProcessor，DSP)、专用集成电路(ApplicationSpecificIntegratedCircuit，ASIC)、现成可编程门阵列(Field-ProgrammableGateArray，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器61在一些实施例中可以是所述终端设备6的内部存储单元，例如终端设备6的硬盘或内存。所述存储器61在另一些实施例中也可以是所述终端设备6的外部存储设备，例如所述终端设备6上配备的插接式硬盘，智能存储卡(SmartMediaCard，SMC)，安全数字(SecureDigital，SD)卡，闪存卡(FlashCard)等。进一步地，所述存储器61还可以既包括所述终端设备6的内部存储单元也包括外部存储设备。所述存储器61用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器61还可以用于暂时地存储已经输出或者将要输出的数据。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行时实现可实现上述各个方法实施例中的步骤。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/终端设备的任何实体或装置、记录介质、计算机存储器、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其他实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，可以通过其他的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其他的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

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

Claims

1.一种嵌入式内存数据库的数据管理方法，其特征在于，包括：

启动所述嵌入式内存数据库，并获取所述内存数据库中的所述内存数据库中的结构化查询语言SQL引擎的第一配置信息；

接收所述第一SQL引擎返回的所述执行结果。

2.如权利要求1所述的方法，其特征在于，所述启动所述嵌入式内存数据库，包括：

通过所述嵌入式内存数据库的编程接口启动所述嵌入式内存数据库；

向操作系统申请共享内存区作为所述嵌入式内存数据库的数据存储区域，并初始化所述数据存储区域。

3.如权利要求1所述的方法，其特征在于，所述SQL引擎插件包括多个子插件，所述多个子插件分别具有对应的插件配置值，所述加载与所述第一配置信息对应的SQL引擎插件，建立所述第一SQL引擎，包括：

依次读取所述插件配置值；

加载所述插件配置值为第一数值的至少一个子插件，所述至少一个子插件组成所述第一SQL引擎；

为所述第一SQL引擎建立对应的SQL接口。

4.如权利要求3所述的方法，其特征在于，所述SQL引擎包括SQL解释器、查询执行器和查询优化器，所述SQL解释器和所述查询执行器组成所述SQL引擎插件的第一子插件，所述查询优化器为所述SQL引擎插件的第二子插件，所述SQL引擎至少包括所述第一子插件。

5.如权利要求3所述的方法，其特征在于，所述向所述第一SQL引擎发送SQL指令，包括：

通过所述SQL接口，向所述第一SQL引擎发送SQL指令。

6.如权利要求3所述的方法，其特征在于，所述方法还包括：

当检测到所述第一SQL引擎的第一配置信息改变时，读取所述第一配置信息的改变信息；

若所述改变信息为所述插件配置值由第二数值变为第一数值，则加载所述插件配置值变更为所述第一数值的SQL引擎插件；

若所述改变信息为所述插件配置值由第一数值变为第二数值，则去除所述插件配置值变更为所述第二数值的SQL引擎插件。

7.如权利要求1所述的方法，其特征在于，所述方法还包括：

启动内存库管理工具，并获取所述内存库管理工具所携带的SQL引擎的第二配置信息；

加载与所述第二配置信息对应的SQL引擎插件，建立第二SQL引擎，所述第二SQL引擎用于所述内存库管理工具对所述嵌入式内存数据库进行数据管理。

8.一种嵌入式内存数据库的数据管理装置，其特征在于，包括：

9.一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述的方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的方法。