CN103761248A - 利用内存数据库进行数据查询的方法及*** - Google Patents

利用内存数据库进行数据查询的方法及*** Download PDF

Info

Publication number
CN103761248A
CN103761248A CN201310717225.4A CN201310717225A CN103761248A CN 103761248 A CN103761248 A CN 103761248A CN 201310717225 A CN201310717225 A CN 201310717225A CN 103761248 A CN103761248 A CN 103761248A
Authority
CN
China
Prior art keywords
entity
memory database
loading
load
data
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.)
Granted
Application number
CN201310717225.4A
Other languages
English (en)
Other versions
CN103761248B (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.)
Yuanguang Software Co Ltd
Original Assignee
Yuanguang Software 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 Yuanguang Software Co Ltd filed Critical Yuanguang Software Co Ltd
Priority to CN201310717225.4A priority Critical patent/CN103761248B/zh
Publication of CN103761248A publication Critical patent/CN103761248A/zh
Application granted granted Critical
Publication of CN103761248B publication Critical patent/CN103761248B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/245Query processing
    • G06F16/2453Query optimisation
    • G06F16/24534Query rewriting; Transformation
    • G06F16/24539Query rewriting; Transformation using cached or materialised query results

Landscapes

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

Abstract

本发明具体涉及利用内存数据库进行数据查询的方法及***,其中,方法包括以下步骤:1)建立监控服务,在监控服务中设置实体,以及实体的加载SQL、加载策略,加载SQL为实体加载时在该实体所在的业务库执行的SQL,加载策略为实体的数据选择条件;2)针对每一个实体,结合对应的加载策略,使用对应的加载SQL从该实体所在的业务库中选择该实体中相应的数据,加载到内存数据库中,所述内数据库采用异机部署;3)接收查询命令,在内存数据库中找出与查询命令相应的数据返回。本发明加快了数据查询的速度。

Description

利用内存数据库进行数据查询的方法及***
【技术领域】
本发明属于企业信息管理***领域(ERP),涉及信息管理***领域中关于稽核、审计及相关监控业务的标准数据管理技术,具体涉及利用内存数据库进行数据查询的方法及***。
【背景技术】
在数据监控过程中,有时候需要对多个业务库的数据进行查询,业务库为数据库,业务库中存有至少一个实体,实体中含有多个业务数据;目前的查询方法在以往的一些方案中一般采用如下方式:
1、在数据库中(如Oracle),通过DBLINK来将需要查询的数据表通过链接表的方式创建到主业务库,因链接表的创建会占用数据库连接,会造成数据库连接资源过多,在有限的连接资源情况下产生过多的连接会导致查询性能低下,严重的情况会导致数据库崩溃,同时创建链接表需要提升当前用户在Oracle中的权限,存在一定的安全隐患;
2、将多个业务库的数据查询到内存中,然后在内存中对多个数据集做计算,这样当数据量过多时(如百万条、千万条)会占用大量的内存空间,影响生产***的性能,严重会导致生产***宕机的情况,而且针对每一个查询需要处理单独的业务逻辑,扩展性较差。
【发明内容】
本发明要解决的第一个技术问题是提供一种利用内存数据库进行数据查询的方法,其加快了数据查询的速度。
本发明要解决的第二个技术问题是提供一种利用内存数据库进行数据查询的***,其加快了数据查询的速度。
上述第一个技术问题通过以下技术方案解决:
利用内存数据库进行数据查询的方法,其特征在于,包括以下步骤:
1)建立监控服务,在监控服务中设置实体,以及实体的加载SQL、加载策略,加载SQL为实体加载时在该实体所在的业务库执行的SQL,加载策略为实体的数据选择条件;
2)针对每一个实体,结合对应的加载策略,使用对应的加载SQL从该实体所在的业务库中选择该实体中相应的数据,加载到内存数据库中,所述内数据库采用异机部署;
3)接收查询命令,在内存数据库中找出与查询命令相应的数据返回。
在步骤2)中,内存数据库中相应地生成一实体状态表,该实体状态表记载有被加载到内存数据库中的每个实体的属性,属性包括实体名称、加载SQL、加载策略。
在步骤2)具体为监控服务中的每个实体进行以下操作:首先根据实体名称来判断该实体在实体状态表中有没有记录,如果没有记录则将该实体相应的数据加载到内存数据库中,在实体状态表记载该实体的属性;如果有记录则判断该实体的此次加载策略是否与实体状态表中对应实体的加载策略一致;如果一致,则该实体的此次加载不需要进行;如果不一致,则将内存数据库中该实体的数据删除,并将该实体此次需要加载的数据加载到内存数据库中,同时更新实体状态表中该实体的加载次数、最近加载时间、加载SQL、加载策略。
在步骤1)中的监控服务中设置实体的加载次序;在步骤2)中,按所述加载次序对每个实体进行有次序地加载。
在步骤1)和步骤2)之间还包括步骤1’):遍历实体表上所有实体,根据实体的最近加载时间、加载次数、实体大小计算出每一个实体的加载频率,然后根据加载频率从高到底依次将实体加载进内存数据库。
所述属性还包括加载实体的实体行记录数、实体行记录大小;在步骤2)中,在每一次加载实体之前,判断实体的预加载量与内存数据库的当前使用量之和是否大于内存阀值,如果大于则从内存数据库中将符合删除条件的实体删除,同时在实体状态表中将与这些实体对应的属性删除;实体预加载量=当前加载实体的实体行记录数×实体行记录大小×计算误差比率,计算误差比=实际耗用内存与计算值的比率。
还包括定时删除数据步骤:每隔一定时间,当判断到内存数据库的当前使用量大于内存阀值从内存数据库中将符合删除条件的实体的数据删除,同时在实体状态表中将与这些符合删除条件的实体对应的属性删除。
上述第二个技术问题通过以下技术方案解决:
利用内存数据库进行数据查询的***,其特征在于,包括:
1)设置模块,用于建立监控服务,在监控服务中设置实体,以及实体的加载SQL、加载策略,加载SQL为实体加载时在该实体所在的业务库执行的SQL,加载策略为实体的数据选择条件;
2)加载模块,用于对每一个实体,结合对应的加载策略,使用对应的加载SQL从该实体所在的业务库中选择该实体中相应的数据,加载到内存数据库中,所述内数据库采用异机部署;
3)查询模块,用于接收查询命令,在内存数据库中找出与查询命令相应的数据返回。
在加载模块中,内存数据库中相应地生成一实体状态表,该实体状态表记载有被加载到内存数据库中的每个实体的属性,属性包括实体名称、加载SQL、加载策略。
在加载模块中为监控服务中的每个实体进行以下操作:首先根据实体名称来判断该实体在实体状态表中有没有记录,如果没有记录则将该实体相应的数据加载到内存数据库中,在实体状态表记载该实体的属性;如果有记录则判断该实体的此次加载策略是否与实体状态表中对应实体的加载策略一致;如果一致,则该实体的此次加载不需要进行;如果不一致,则将内存数据库中该实体的数据删除,并将该实体此次需要加载的数据加载到内存数据库中,同时更新实体状态表中该实体的加载次数、最近加载时间、加载SQL、加载策略。
在设置模块中的监控服务中设置实体的加载次序;在加载步骤中,按所述加载次序对每个实体进行有次序地加载。
还包括智能排序模块:遍历实体表上所有实体,根据实体的最近加载时间、加载次数、实体大小计算出每一个实体的加载频率,然后根据加载频率从高到底依次将实体加载进内存数据库。
所述属性还包括加载实体的实体行记录数、实体行记录大小;在加载模块中,在每一次加载实体之前,判断实体的预加载量与内存数据库的当前使用量之和是否大于内存阀值,如果大于则从内存数据库中将符合删除条件的实体删除,同时在实体状态表中将与这些实体对应的属性删除;实体预加载量=当前加载实体的实体行记录数×实体行记录大小×计算误差比率,计算误差比=实际耗用内存与计算值的比率。
还包括定时删除数据步骤:每隔一定时间,当判断到内存数据库的当前使用量大于内存阀值从内存数据库中将符合删除条件的实体的数据删除,同时在实体状态表中将与这些符合删除条件的实体对应的属性删除。
由上述技术方案可见,本发明采用内存数据库作为中间库,在查询之前将各个业务库的数据通过ETL抽取到内存数据库,然后在内存数据库中执行查询,这样就可以做到多业务库跨库查询,解决了跨库查询与查询性能较慢的问题,如图4所示,实验数据证明,本发明方法比传统规则业务查询的效率要高几个数量级。通过加载策略减少ETL抽取的数据量,提升查询性能。跨业务库查询,与传统跨库方案比较,采用内存数据库的方式效率更高、可扩展性更好,而且更安全,在以往的解决方案中采用DBLINK链接表的方式因为占用了数据库的连接资源,会导致数据库连接过多而无法响应新的请求,而且用户也要另外赋予更新的权限,会存在安全隐患,而采用内存数据库的方案能最大程度的减轻应用服务器与业务数据库的压力,即使内存数据库宕机也不影响应用服务的正常运行,只需要重启内存数据库服务即可,而整个过程完全通过UI操作。查询效率,因为所涉及到的业务数据全部在内存数据库中,省去了传统数据库的磁盘I/O时间,查询效率要比传统数据库要高几个数量级,只要保证数据加载的高命中率,***的查询性能较大大提高。
【附图说明】
图1为实施例一本发明方法的流程图;
图2为内存数据库的异机部署图;
图3为实体状态表的具体示例图;
图4为采用与不采用内存数据库进行数据查询的结果对比图;
图5为实体加载的规则图;
图6为实施例二本发明***的结构框图。
【具体实施方式】
实施例一
如图1所示,利用内存数据库进行数据查询的方法,包括以下步骤:
1)设置步骤:建立监控服务,在监控服务中设置实体,以及实体的加载SQL、加载策略,加载SQL为实体加载时在该实体所在的业务库执行的SQL,加载策略为实体的数据选择条件,加载策略根据当前上下文环境不同而不同;
2)加载步骤:针对每一个实体,结合对应的加载策略,使用对应的加载SQL从该实体所在的业务库中选择该实体中相应的数据,加载到内存数据库中,所述内数据库采用异机部署;
3)查询步骤:接收查询命令,在内存数据库中找出与查询命令相应的数据返回。上述内存数据库的物理部署说明:搭建专用的内存数据库服务器(通常,机器配置要求64位操作***、32G内存以上、4核及以上主流CPU、千兆/万兆网络带宽,64位JDK),所有涉及到跨业务库的业务数据都先加载至内存数据库中(支持Oracle、SqlServer、DB2等数据库),后续查询在内存数据库执行。实际应用中,内存数据库服务器支持内嵌(嵌入到应用服务)、同机(与应用服务在同一台服务器)、异机部署(与应用服务在两台不同的服务器)三种模式;见图2,本发明采用异机部署,部署同时支持Windows、Linux***。
其中,在步骤2)中,内存数据库中相应地生成一实体状态表,该实体状态表记载有针对每个实体的属性,如图3所示,属性包括实体名称、最后加载时间、加载次数、实体行记录数、实体行记录大小、加载策略和加载SQL,实体名称包括实体英文名称、实体中文名称。
实体英文名称:实体的英文描述,在内存数据库中会以实体名称为表名建立实体表。
实体中文名称:实体的中文描述。
最后加载时间:实体最后一次加载的时间。
加载次数:实体总共加载的次数。
实体行记录数:该实体中被加载的数据共有多少条行记录。
实体行记录大小:实体的行记录的大小,计算方法为实体所有属性的字段耗用大小之和。
加载策略:记载该实体的加载策略;
加载SQL:实体加载时在其该实体所在的业务库执行的SQL。
为了更好地进行数据查询,本实施例中从以下各方面进行改进。
一、提高加载实体效率
在实际运行中,会存在某些实体需要多次加载的情况,***为提升加载效率,节省加载时间,每次加载实体时会进行以下操作,因此,在上述步骤2)中每次加载实体时会进行以下操作:首先根据实体名称来判断该实体在实体状态表中有没有记录,如果没有记录则将该实体相应的数据加载到内存数据库中,在实体状态表记载该实体的属性;如果有记录则判断该实体的此次加载策略是否与实体状态表中对应实体的加载策略一致;如果一致,则该实体的此次加载不需要进行;如果不一致,则将内存数据库中该实体的数据删除,并将该实体此次需要加载的数据加载到内存数据库中,同时更新实体状态表中该实体的加载次数、最近加载时间、加载SQL、加载策略。
该步骤避免了相同加载策略的实体在下次用到时不再加载,减少加载的数据量,提高查询的效率。
二、实体加载方式
有两者方案:
1、人工规划:在步骤1)中的监控服务中设置实体的加载次序;在步骤2)中,按所述加载次序对每个实体进行有次序地加载。这根据需要进行人工安排,便于灵活地应对需要。
2、智能安排:在步骤1)和步骤2)之间还包括步骤1’):遍历实体表上所有实体,根据实体的最近加载时间、加载次数、实体大小计算出每一个实体的加载频率,然后根据加载频率从高到底依次将实体加载进内存数据库,这样就将访问频率相对较高的实体都加载进内存,此加载通过调度程序在非业务活动期(如晚上)加载,这样在第二天就免去了加载的过程,从而缩短查询时间、提升查询效率。
三、基于内存数据库的垃圾回收动作
由于内存是有限资源,在实体加载时要有相关的安全机制,以控制内存的余留量。具体有两种方案:
3.1实体加载时删除:在步骤2)中,在每一次加载实体之前,判断实体的预加载量与内存数据库的当前使用量之和是否大于内存阀值(内存数据库最大使用内存值,可以根据实际情况自由设定),如果大于则从内存数据库中将符合删除条件的实体删除,同时在实体状态表中将与这些实体对应的属性删除;实体预加载量=当前加载实体的实体行记录数×实体行记录大小×计算误差比率,计算误差比=实际耗用内存与计算值的比率。
3.2定时删除:每隔一定时间(例如10分钟,可以根据实际情况自由设定),当判断到内存数据库的当前使用量大于内存阀值,采用“遗传算法”从内存数据库中将符合删除条件的实体删除,同时在实体状态表中将与这些实体对应的属性删除。
上述删除条件通常是根据实体使用时间、使用次数、使用频率进行设定,目的是将不常用的实体删除。
四、可视化UI
内存数据库的配置、运行、维护操作全部可视化,提供了专门的UI界面进行操作,提高用户体验,同时提供了内存数据库的操作控制台,类似于PL/SQL,通过用户登录授权后,可以直接在内存数据库中执行DML、DDL、DCL操作语句,同时查询实体的加载情况,方便实施/开发人员进行维护与问题跟踪。
实施例二
如图6所示,利用内存数据库进行数据查询的***,包括:
1)设置模块,用于建立监控服务,在监控服务中设置实体,以及实体的加载SQL、加载策略,加载SQL为实体加载时在该实体所在的业务库执行的SQL,加载策略为实体的数据选择条件,加载策略根据当前上下文环境不同而不同;
2)加载模块,用于对每一个实体,结合对应的加载策略,使用对应的加载SQL从该实体所在的业务库中选择该实体中相应的数据,加载到内存数据库中,所述内数据库采用异机部署;
3)查询模块,用于接收查询命令,在内存数据库中找出与查询命令相应的数据返回。
上述内存数据库的物理部署说明:搭建专用的内存数据库服务器(通常,机器配置要求64位操作***、32G内存以上、4核及以上主流CPU、千兆/万兆网络带宽,64位JDK),所有涉及到跨业务库的业务数据都先加载至内存数据库中(支持Oracle、SqlServer、DB2等数据库),后续查询在内存数据库执行。实际应用中,内存数据库服务器支持内嵌(嵌入到应用服务)、同机(与应用服务在同一台服务器)、异机部署(与应用服务在两台不同的服务器)三种模式;见图2,本发明采用异机部署,部署同时支持Windows、Linux***。
其中,在加载模块中,内存数据库中相应地生成一实体状态表,该实体状态表记载有针对每个实体的属性,如图3所示,属性包括实体名称、最后加载时间、加载次数、实体行记录数、实体行记录大小、加载策略和加载SQL,实体名称包括实体英文名称、实体中文名称。
实体英文名称:实体的英文描述,在内存数据库中会以实体名称为表名建立实体表。
实体中文名称:实体的中文描述。
最后加载时间:实体最后一次加载的时间。
加载次数:实体总共加载的次数。
实体行记录数:该实体中被加载的数据共有多少条行记录。
实体行记录大小:实体的行记录的大小,计算方法为实体所有属性的字段耗用大小之和。
加载策略:记载该实体的加载策略;
加载SQL:实体加载时在其该实体所在的业务库执行的SQL。
为了更好地进行数据查询,本实施例中从以下各方面进行改进。
一、提高加载实体效率
在实际运行中,会存在某些实体需要多次加载的情况,***为提升加载效率,节省加载时间,每次加载实体时会进行以下操作,因此,在上述加载模块中每次加载实体时会进行以下操作:首先根据实体名称来判断该实体在实体状态表中有没有记录,如果没有记录则将该实体相应的数据加载到内存数据库中,在实体状态表记载该实体的属性;如果有记录则判断该实体的此次加载策略是否与实体状态表中对应实体的加载策略一致;如果一致,则该实体的此次加载不需要进行;如果不一致,则将内存数据库中该实体的数据删除,并将该实体此次需要加载的数据加载到内存数据库中,同时更新实体状态表中该实体的加载次数、最近加载时间、加载SQL、加载策略。
该步骤避免了相同加载策略的实体在下次用到时不再加载,减少加载的数据量,提高查询的效率。
二、实体加载方式
有两者方案:
1、人工规划:在设置模块中的监控服务中设置实体的加载次序;在加载模块中,按所述加载次序对每个实体进行有次序地加载。这根据需要进行人工安排,便于灵活地应对需要。
2、智能安排:还包括智能排序模块:遍历实体表上所有实体,根据实体的最近加载时间、加载次数、实体大小计算出每一个实体的加载频率,然后根据加载频率从高到底依次将实体加载进内存数据库,这样就将访问频率相对较高的实体都加载进内存,此加载通过调度程序在非业务活动期(如晚上)加载,这样在第二天就免去了加载的过程,从而缩短查询时间、提升查询效率。
三、基于内存数据库的垃圾回收动作
由于内存是有限资源,在实体加载时要有相关的安全机制,以控制内存的余留量。具体有两种方案:
3.1实体加载时删除:在加载模块中,在每一次加载实体之前,判断实体的预加载量与内存数据库的当前使用量之和是否大于内存阀值(内存数据库最大使用内存值,可以根据实际情况自由设定),如果大于则从内存数据库中将符合删除条件的实体删除,同时在实体状态表中将与这些实体对应的属性删除;实体预加载量=当前加载实体的实体行记录数×实体行记录大小×计算误差比率,计算误差比=实际耗用内存与计算值的比率。
3.2定时删除:每隔一定时间(例如10分钟,可以根据实际情况自由设定),当判断到内存数据库的当前使用量大于内存阀值,采用“遗传算法”从内存数据库中将符合删除条件的实体删除,同时在实体状态表中将与这些实体对应的属性删除。
上述删除条件通常是根据实体使用时间、使用次数、使用频率进行设定,目的是将不常用的实体删除。
四、可视化UI
内存数据库的配置、运行、维护操作全部可视化,提供了专门的UI界面进行操作,提高用户体验,同时提供了内存数据库的操作控制台,类似于PL/SQL,通过用户登录授权后,可以直接在内存数据库中执行DML、DDL、DCL操作语句,同时查询实体的加载情况,方便实施/开发人员进行维护与问题跟踪。
本发明不局限于上述实施例,基于上述实施例的、未做出创造性劳动的简单替换,应当属于本发明揭露的范围。

Claims (14)

1.利用内存数据库进行数据查询的方法,其特征在于,包括以下步骤:
1)建立监控服务,在监控服务中设置实体,以及实体的加载SQL、加载策略,加载SQL为实体加载时在该实体所在的业务库执行的SQL,加载策略为实体的数据选择条件;
2)针对每一个实体,结合对应的加载策略,使用对应的加载SQL从该实体所在的业务库中选择该实体中相应的数据,加载到内存数据库中,所述内数据库采用异机部署;
3)接收查询命令,在内存数据库中找出与查询命令相应的数据返回。
2.根据权利要求1所述的利用内存数据库进行数据查询的方法,其特征在于,在步骤2)中,内存数据库中相应地生成一实体状态表,该实体状态表记载有被加载到内存数据库中的每个实体的属性,属性包括实体名称、加载SQL、加载策略。
3.根据权利要求2所述的利用内存数据库进行数据查询的方法,其特征在于,在步骤2)具体为监控服务中的每个实体进行以下操作:首先根据实体名称来判断该实体在实体状态表中有没有记录,如果没有记录则将该实体相应的数据加载到内存数据库中,在实体状态表记载该实体的属性;如果有记录则判断该实体的此次加载策略是否与实体状态表中对应实体的加载策略一致;如果一致,则该实体的此次加载不需要进行;如果不一致,则将内存数据库中该实体的数据删除,并将该实体此次需要加载的数据加载到内存数据库中,同时更新实体状态表中该实体的加载次数、最近加载时间、加载SQL、加载策略。
4.根据权利要求1至3任意一项所述的利用内存数据库进行数据查询的方法,其特征在于,在步骤1)中的监控服务中设置实体的加载次序;在步骤2)中,按所述加载次序对每个实体进行有次序地加载。
5.根据权利要求1至3任意一项所述的利用内存数据库进行数据查询的方法,其特征在于,在步骤1)和步骤2)之间还包括步骤1’):遍历实体表上所有实体,根据实体的最近加载时间、加载次数、实体大小计算出每一个实体的加载频率,然后根据加载频率从高到底依次将实体加载进内存数据库。
6.根据权利要求2所述的利用内存数据库进行数据查询的方法,其特征在于,所述属性还包括加载实体的实体行记录数、实体行记录大小;在步骤2)中,在每一次加载实体之前,判断实体的预加载量与内存数据库的当前使用量之和是否大于内存阀值,如果大于则从内存数据库中将符合删除条件的实体删除,同时在实体状态表中将与这些实体对应的属性删除;实体预加载量=当前加载实体的实体行记录数×实体行记录大小×计算误差比率,计算误差比=实际耗用内存与计算值的比率。
7.根据权利要求1所述的利用内存数据库进行数据查询的方法,其特征在于,还包括定时删除数据步骤:每隔一定时间,当判断到内存数据库的当前使用量大于内存阀值从内存数据库中将符合删除条件的实体的数据删除,同时在实体状态表中将与这些符合删除条件的实体对应的属性删除。
8.利用内存数据库进行数据查询的***,其特征在于,包括:
1)设置模块,用于建立监控服务,在监控服务中设置实体,以及实体的加载SQL、加载策略,加载SQL为实体加载时在该实体所在的业务库执行的SQL,加载策略为实体的数据选择条件;
2)加载模块,用于对每一个实体,结合对应的加载策略,使用对应的加载SQL从该实体所在的业务库中选择该实体中相应的数据,加载到内存数据库中,所述内数据库采用异机部署;
3)查询模块,用于接收查询命令,在内存数据库中找出与查询命令相应的数据返回。
9.根据权利要求8所述的利用内存数据库进行数据查询的***,其特征在于,在加载模块中,内存数据库中相应地生成一实体状态表,该实体状态表记载有被加载到内存数据库中的每个实体的属性,属性包括实体名称、加载SQL、加载策略。
10.根据权利要求9所述的利用内存数据库进行数据查询的***,其特征在于,在加载模块中为监控服务中的每个实体进行以下操作:首先根据实体名称来判断该实体在实体状态表中有没有记录,如果没有记录则将该实体相应的数据加载到内存数据库中,在实体状态表记载该实体的属性;如果有记录则判断该实体的此次加载策略是否与实体状态表中对应实体的加载策略一致;如果一致,则该实体的此次加载不需要进行;如果不一致,则将内存数据库中该实体的数据删除,并将该实体此次需要加载的数据加载到内存数据库中,同时更新实体状态表中该实体的加载次数、最近加载时间、加载SQL、加载策略。
11.根据权利要求8至10任意一项所述的利用内存数据库进行数据查询的***,其特征在于,在设置模块中的监控服务中设置实体的加载次序;在加载步骤中,按所述加载次序对每个实体进行有次序地加载。
12.根据权利要求8至10任意一项所述的利用内存数据库进行数据查询的***,其特征在于,还包括智能排序模块:遍历实体表上所有实体,根据实体的最近加载时间、加载次数、实体大小计算出每一个实体的加载频率,然后根据加载频率从高到底依次将实体加载进内存数据库。
13.根据权利要求9所述的利用内存数据库进行数据查询的***,其特征在于,所述属性还包括加载实体的实体行记录数、实体行记录大小;在加载模块中,在每一次加载实体之前,判断实体的预加载量与内存数据库的当前使用量之和是否大于内存阀值,如果大于则从内存数据库中将符合删除条件的实体删除,同时在实体状态表中将与这些实体对应的属性删除;实体预加载量=当前加载实体的实体行记录数×实体行记录大小×计算误差比率,计算误差比=实际耗用内存与计算值的比率。
14.根据权利要求8所述的利用内存数据库进行数据查询的***,其特征在于,还包括定时删除数据步骤:每隔一定时间,当判断到内存数据库的当前使用量大于内存阀值从内存数据库中将符合删除条件的实体的数据删除,同时在实体状态表中将与这些符合删除条件的实体对应的属性删除。
CN201310717225.4A 2013-12-23 2013-12-23 利用内存数据库进行数据查询的方法及*** Active CN103761248B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201310717225.4A CN103761248B (zh) 2013-12-23 2013-12-23 利用内存数据库进行数据查询的方法及***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201310717225.4A CN103761248B (zh) 2013-12-23 2013-12-23 利用内存数据库进行数据查询的方法及***

Publications (2)

Publication Number Publication Date
CN103761248A true CN103761248A (zh) 2014-04-30
CN103761248B CN103761248B (zh) 2018-04-17

Family

ID=50528487

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201310717225.4A Active CN103761248B (zh) 2013-12-23 2013-12-23 利用内存数据库进行数据查询的方法及***

Country Status (1)

Country Link
CN (1) CN103761248B (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106202080A (zh) * 2015-04-30 2016-12-07 ***通信集团公司 一种网页渲染方法、服务器及终端设备
CN110888939A (zh) * 2018-09-06 2020-03-17 北京京东尚科信息技术有限公司 一种数据管理方法和装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101221585A (zh) * 2008-02-03 2008-07-16 华为技术有限公司 数据存储方法及装置
CN101320392A (zh) * 2008-07-17 2008-12-10 中兴通讯股份有限公司 内存数据库的大容量数据存取方法及装置
CN101329685A (zh) * 2008-07-30 2008-12-24 烽火通信科技股份有限公司 一种家庭网关上内存数据库的实现方法
CN101414917A (zh) * 2007-10-19 2009-04-22 华为技术有限公司 节省内存空间的方法、数据管理网元及网络***
CN102054034A (zh) * 2010-12-27 2011-05-11 华中科技大学 企业信息***的业务基础数据持久化实现方法
CN102279885A (zh) * 2011-08-16 2011-12-14 中兴通讯股份有限公司 内存数据库对数据的操作方法及装置
US20120096233A1 (en) * 2005-12-05 2012-04-19 Tianlong Chen Apparatus and Method for On-Demand In-Memory Database Management Platform

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120096233A1 (en) * 2005-12-05 2012-04-19 Tianlong Chen Apparatus and Method for On-Demand In-Memory Database Management Platform
CN101414917A (zh) * 2007-10-19 2009-04-22 华为技术有限公司 节省内存空间的方法、数据管理网元及网络***
CN101221585A (zh) * 2008-02-03 2008-07-16 华为技术有限公司 数据存储方法及装置
CN101320392A (zh) * 2008-07-17 2008-12-10 中兴通讯股份有限公司 内存数据库的大容量数据存取方法及装置
CN101329685A (zh) * 2008-07-30 2008-12-24 烽火通信科技股份有限公司 一种家庭网关上内存数据库的实现方法
CN102054034A (zh) * 2010-12-27 2011-05-11 华中科技大学 企业信息***的业务基础数据持久化实现方法
CN102279885A (zh) * 2011-08-16 2011-12-14 中兴通讯股份有限公司 内存数据库对数据的操作方法及装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106202080A (zh) * 2015-04-30 2016-12-07 ***通信集团公司 一种网页渲染方法、服务器及终端设备
CN110888939A (zh) * 2018-09-06 2020-03-17 北京京东尚科信息技术有限公司 一种数据管理方法和装置

Also Published As

Publication number Publication date
CN103761248B (zh) 2018-04-17

Similar Documents

Publication Publication Date Title
CN109144994A (zh) 索引更新方法、***及相关装置
CN102930062B (zh) 一种数据库快速水平扩展的方法
CN103365929B (zh) 一种数据库连接的管理方法及***
CN104462185B (zh) 一种基于混合结构的数字图书馆云存储***
CN102651007A (zh) 一种管理数据库索引的方法和装置
CN103593422A (zh) 一种异构数据库的虚拟访问管理方法
CN103455540A (zh) 从数据仓库模型生成内存模型的***和方法
CN105069149A (zh) 一种面向结构化列式数据的分布式并行数据导入方法
CN103425762A (zh) 基于Hadoop平台的电信运营商海量数据处理方法
CN104216962A (zh) 一种基于HBase的海量网管数据索引设计方法
CN105608224A (zh) 一种提高海量数据查询性能的正交多哈希映射索引方法
CN105989015B (zh) 一种数据库扩容方法和装置以及访问数据库的方法和装置
CN102663007A (zh) 一种支持敏捷开发和横向扩展的数据存储与查询方法
CN107153701A (zh) 一种基于元数据的it***管理及监控管理方法
CN109669975B (zh) 一种工业大数据处理***及方法
CN105608126A (zh) 一种建立海量数据库二级索引的方法和装置
CN104376109A (zh) 一种基于数据分布库的多维度数据分布方法
CN111917834A (zh) 一种数据同步方法、装置、存储介质及计算机设备
US11249968B2 (en) Large object containers with size criteria for storing mid-sized large objects
CN106780157B (zh) 基于Ceph的电网多时态模型存储与管理***及方法
CN105786877B (zh) 一种数据存储方法、***及查询方法
CN105138638A (zh) 一种基于应用层的数据库分布方法
CN103365923A (zh) 用于评估数据库的分区方案的方法和装置
CN103761248A (zh) 利用内存数据库进行数据查询的方法及***
CN111752539A (zh) Bi服务集群***及其搭建方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant