CN114218277A - 一种关系数据库的高效查询方法和装置 - Google Patents
一种关系数据库的高效查询方法和装置 Download PDFInfo
- Publication number
- CN114218277A CN114218277A CN202111544353.4A CN202111544353A CN114218277A CN 114218277 A CN114218277 A CN 114218277A CN 202111544353 A CN202111544353 A CN 202111544353A CN 114218277 A CN114218277 A CN 114218277A
- Authority
- CN
- China
- Prior art keywords
- dimensional table
- timestamp
- relational database
- redis
- updated
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2315—Optimistic concurrency control
- G06F16/2322—Optimistic concurrency control using timestamps
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种关系数据库的高效查询方法和装置,该方法包括以下步骤:将查询关系数据库获得的记录写入Redis生成第二二维表作为缓存,所述关系数据库上保存有第一二维表的第一时间戳;所述第二二维表中保存有所述第二二维表的第二时间戳;通过比较所述第一时间戳与所述第二时间戳的时间先后,判断所述第二二维表是否需要生成或更新,并从关系数据库或Redis查询满足指定条件的记录。本发明,由于部分记录可以从Redis缓存的二维表中查询获得,因此,减轻了关系数据库的压力,提高了查询效率。
Description
技术领域
本发明涉及数据库技术领域,具体涉及一种关系数据库的高效查询方法和装置。
背景技术
数据库的应用领域非常广泛,不管是家庭、公司或大型企业,还是政府部门,都需要使用数据库来存储数据信息。其中,应用最多的是关系型数据库,如Oracle、Mysql、SqlServer等。
关系型数据库基于单一关系模型,结构化存储,有完整性约束,和常见的表格比较相似,通过二维表建立数据之间的联系,采用结构化查询语言(SQL)做数据读写。其优点在于,通过事务处理保持数据的一致性,数据更新的开销很小,可以进行Join等复杂查询。然而,关系型数据库使用select语句对二维表进行查询,如果直接对关系型数据库进行查询,会对数据库造成较大压力,查询效率较低。
有鉴于此,急需对现有的关系型数据库查询方法进行改进,以减轻查询关系型数据库的压力,提升查询效率。
发明内容
针对上述缺陷,本发明所要解决的技术问题在于提供一种关系数据库的高效查询方法和装置,以解决现有的关系型数据库查询方法,对数据库造成较大压力,查询效率较低的问题。
为此,本发明提供的一种关系数据库的高效查询方法,包括以下步骤:
将查询关系数据库获得的记录写入第一二维表并将所述第一二维表写入Redis生成第二二维表,所述第二二维表作为所述第一二维表的缓存,所述关系数据库上保存有第一二维表生成或更新时的第一时间戳;所述第二二维表中保存有所述第二二维表生成或更新时的第二时间戳;根据所述第一时间戳更新所述第二时间戳;
通过比较所述第一时间戳与所述第二时间戳的时间先后,判断所述二维表是否需要生成或更新,无所述第二时间戳视为所述第一时间戳在后;
如果所述第二二维表需要生成或更新,则根据查询条件从关系数据库读取满足查询条件的记录,然后将该记录以及查询索引写入Redis生成或更新所述第二二维表;否则,不更新所述第二二维表,从所述第二二维表中查询满足查询条件的记录。
在上述方法中,将关系数据库中的记录写入所述第一二维表时,生成所述第一时间戳,并将所述第一时间戳与所述第二二维表的映射关系构造第三二维表,保存在关系数据库中;
关系数据库上设有触发器,当所述第一二维表发生***、更新或删除操作时,更新所述第一时间戳。
在上述方法中,优选地,判断是否需要生成或更新所述第二二维表包括以下步骤:
从关系数据库读取所述第一二维表的第一时间戳,从Redis读取与所述第一二维表对应的第二二维表的第二时间戳;
判断所述第二时间戳是否存在,如果所述第二时间戳不存在,则将所述第一二维表写入Redis生成所述第二二维表,并将所述第一时间戳写入所述第二二维表,形成所述第二时间戳;否则比较所述第一时间戳与所述第二时间戳的时间先后,如果所述第一时间戳在后,则根据所述第一二维表更新所述第二二维表及所述第二时间戳;如果所述第一时间戳与所述第二时间戳相同,则不需要更新所述第二二维表。
在上述方法中,优选地,将查询关系数据库获得的所述记录以及查询索引写入Redis生成或更新所述第二二维表,包括以下内容:
第二时间戳,用于标识是否需要更新所述第二二维表;
记录总数,用于查询所述第二二维表;
列名称;
记录内容,其键为所述第二二维表中的记录的下标;
查询索引,用于快速定位所述第二二维表中满足指定的列的记录。
在上述方法中,优选地,在Redis上存储所述第二二维表的列名称时,使用分隔符将所述第二二维表中所有的列名称拼接起来作为一个字符串进行存储;将所述第二二维表中的每行记录的键设置为下标,各个字段的值使用分隔符,将各个字段的值拼接起来作为一个字符串进行存储。
在上述方法中,优选地,开始向Redis写入第二二维表时,首先使用WATHCH命令,写入完成后使用EXEX提交事务。
在上述方法中,优选地,查询所述第二二维表的方法如下:先读取所述第二二维表的记录总数,接着取出字段名称,根据所述第二二维表的记录总数,对记录下标进行循环遍历,取出所述第二二维表中的所有记录。
在上述方法中,根据列对所述第二二维表进行查询的方法如下:先根据查询条件使用所述第二二维表的查询索引获取记录下标,接着取出字段名称,最后根据记录下标取出指定的记录。
本发明还提供了一种关系数据库的高效查询装置,包括:
二维表创建模块,用于将查询关系数据库获得的记录写入第一二维表并将所述第一二维表写入Redis生成第二二维表,所述第二二维表作为所述第一二维表的缓存;
时间戳生成模块,用于在生成所述第一二维表时生成第一时间戳,并将所述第一时间戳与所述第一二维表的映射关系构造第三二维表保存在关系数据库中;将所述第一时间戳写入所述第二二维表,形成所述第二时间戳;
时间戳更新模块,用于所述第一二维表发生***、更新或删除操作时,更新所述第一时间戳;根据所述第一时间戳,更新所述第二时间戳;
比较模块,用于比较所述第一时间戳与所述第二时间戳的时间先后,判断所述第二二维表是否需要生成或更新,无所述第二时间戳视为所述第一时间戳在后;
第二二维表更新模块,用于根据比较模块得出的所述第二二维表是否需要生成或更新的结果,如果所述第二二维表需要更新,则根据查询条件从关系数据库读取满足查询条件的记录,然后将该记录以及查询索引写入Redis更新所述第二二维表;否则,不更新所述第二二维表。
在上述装置中,优选地,关系数据库上设有触发器,当所述第一二维表发生***、更新或删除操作时,通过所述触发器更新所述第一时间戳。
由上述技术方案可知,本发明提供的一种关系数据库的高效查询方法和装置,解决了现有关系型数据库查询方法,对数据库造成较大压力,查询效率较低的问题。与现有技术相比,本发明具有以下有益效果:
在Redis上创建二维表作为关系数据库的缓存,通过比较Redis上的二维表的时间戳和关系数据库上的二维表的时间戳的先后,判断是否需要更新Redis上的二维表,如果需要,则根据查询条件从读取关系数据库二维表,获取满足查询条件的记录,然后将关系数据库二维表以及查询索引等数据写入Redis;否则,直接从Redis查询满足指定条件的记录。由于部分记录可以从Redis缓存的二维表中查询获得,因此,减轻了关系数据库的压力,提高了查询效率。
附图说明
为了更清楚地说明本发明的实施例或现有技术中的技术方案,下面将对本发明实施例或现有技术描述中所需要使用的附图做出简单地介绍和说明。显而易见地,下面描述中的附图仅仅是本发明的部分实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明提供的一种关系数据库的高效查询方法流程图;
图2为本发明中判断Redis上的第二二维表是否需要生成或更新的流程图。
具体实施方式
下面将结合本发明实施例附图,对本发明实施例的技术方案进行清楚、完整地描述,显然,以下所描述的实施例,仅仅是本发明的一部分实施例,而不是全部的实施例。基于本发明的实施例,本领域普通技术人员在没有做出创造性劳动的前提下,所获得的所有其他实施例,都属于本发明保护的范围。
本发明的实现原理是:
在Redis上创建二维表作为Oracle的缓存,通过比较Redis上的二维表的时间戳和Oracle上的二维表的时间戳的先后,从Oracle或Redis查询满足指定条件的记录。由于部分记录可以从Redis缓存的二维表中查询获得,因此,减轻了Oracle关系数据库的压力,提高了查询效率。
为了对本发明的技术方案和实现方式做出更清楚地解释和说明,以下介绍实现本发明技术方案的几个优选的具体实施例。
需要说明的是,本文中“内、外”、“前、后”及“左、右”等方位词是以产品使用状态为基准对象进行的表述,显然,相应方位词的使用对本方案的保护范围并非构成限制。
以下描述中,以Oracle数据库为例进行说明,可以理解的是,本申请方案并不局限于仅适用于Oracle数据库,还可适用于Mysql、SqlServer等所有的关系数据库。
另外,在以下的描述中,Oracle数据库简称为Oracle,Redis数据库简称为Redis。
请参见图1,图1为本发明提供的一种关系数据库的高效查询方法流程图。
如图1所示,本发明提供的一种关系数据库的高效查询方法,包括以下步骤:
步骤110,将查询Oracle获得的记录写入第一二维表R1,并将第一二维表R1写入Redis生成第二二维表R2,第二二维表R2作为第一二维表R1的缓存,以便后续快速查询。
Oracle上保存有第一二维表R1生成或更新时的第一时间戳T1,第二二维表R2中保存有第二二维表生成或更新时的第二时间戳T2。
具体地,生成第一二维表R1时会同时记录第一二维表R1的生成时间,记为第一时间戳T1。将第一时间戳T1与第一二维表R1的映射关系构造第三二维表保存在Oracle中,形成第三二维表,通过查询第三二维表可以获得第一二维表R1的第一时间戳T1(第一二维表R1的最新的修改时间)。
同时,将第一二维表R1写Redis生成第二二维表R2时,会将第一时间戳T1同时写入第二二维表R2,形成第二时间戳T2。
Redis上存储有与第一二维表R1对应的第二二维表R2,第二二维表R2作为Oracle的缓存,且第二二维表R2中存储每一个第二二维表的第二时间戳T2。
Redis是一个高性能的key-value数据库,属于键值数据库,性能高,支持通过键来查询,但不支持按照值来查询,不支持二维表按列查询。应用场景包括:缓存***(“热点”数据:高频读、低频写)、计数器、消息队列***、排行榜、社交网络和实时***等。
Oracle上设有触发器,当第一二维表T1发生***、更新、删除等操作时,触发器将触发更新第一二维表R1中第一时间戳T1的操作,将第一时间戳T1更新为第一二维表R1的最新修改时间。
第二时间戳T2的更新方式可以采用以下两种方式实现。
第一种方式是:定时轮询第一时间戳T1,并与第二时间戳T2进行对比,如果二者不同,则用第一时间戳T1更新第二时间戳T2。
第二种方式是:每次查询第二二维表R2时,首先获取第二二维表R2中的第二时间戳T2,然后再获取第一二维表R1中的第一时间戳T1,对比第一时间戳T1和第二时间戳T2是否相同,如果二者相同,则不更新第二时间戳T2,如果二者不同,则用第一时间戳T1更新第二时间戳T2。
步骤120,当执行Oracle查询时,通过比较Redis上的第二二维表的第二时间戳T2和Oracle上的第一二维表的第一时间戳T1的时间先后,判断是否需要生成或更新Redis上的第二二维表,如果需要,则执行步骤130;否则,执行步骤140。
具体地,如图2所示,判断是否需要生成或更新Redis上的第二二维表T2包括以下步骤:
步骤121,从Oracle读取第一二维表的第一时间戳T1,从Redis读取与第一二维表对应的第二二维表的第二时间戳T2。
步骤122,判断第二时间戳T2是否存在,如果第二时间戳T2不存在,说明Redis不存在与第一二维表对应的第二二维表,需要更新Redis,于是将查询Oracle获得的记录以及查询索引写入Redis生成第二二维表R2,并将第一时间戳T1写入第二二维表R2,形成第二时间戳T2。
如果第二时间戳T2存在,则执行步骤123,比较第一时间戳T1与第二时间戳T2的时间先后,如果第一时间戳T1在后,即第一时间戳T1的时间晚于第二时间戳T2的时间,则说明第一二维表R1是较新的,需要更新Redis上的第二二维表,于是根据Oracle上的第一二维表R1更新Redis上的第二二维表R2,同时用第一时间戳T1更新第二时间戳T2;如果第一时间戳T1与第二时间戳T2相同,则说明Oracle上的第一二维表R1与Redis上的第二二维表R2相同,Oracle上的第一二维表T1没有更新,不需要更新Redis上的第二二维表。
步骤130,根据查询条件从Oracle读取获得满足查询条件的记录写入第一二维表R1,然后将第一二维表R1以及查询索引等数据写入Redis,这样就在Redis生成了与第一二维表R1对应的第二二维表R2,本次查询结束。
步骤140,直接从Redis上的第二二维表R2中查询满足查询条件的记录。
在上述方法的步骤130中,根据查询条件从Oracle读取获得满足查询条件的记录写入第一二维表的过程如下:
使用select语句从Oracle读取数据,可以是直接读取整个完整的二维表,或者使用sql查询语句查询满足一定条件的记录,并将读取到的记录写入第一二维表。
假设应用程序使用C++语言实现,则可使用vector<map<string,string>>在内存中保存读取到的整个完整的二维表,或者保存使用sql查询语句查询满足一定条件的记录,写入第一二维表。
步骤130中,将查询Oracle获得的第一二维表以及查询索引写入Redis生成或更新第二二维表,包括以下内容:
第二时间戳,用于标识是否需要更新第二二维表。第二时间戳使用string对象存储,往Redis写入Oracle上第一二维表的缓存数据或更新第二二维表时,会将Oracle上对应的第一二维表的第一时间戳T1写入Redis,作为第二时间戳T2。
记录总数,使用string对象存储,用于查询第二二维表;
列名称,使用string对象存储,存储第二二维表的列名称时,由于第二二维表可能包含多列,使用“|”作为分隔符,将所有的列名称拼接起来作为一个字符串进行存储。使用“|”作为分隔符,是因为假定列名称中不包含该字符。例如,第二二维表T2包含两列,F1和F2,则在Redis存储为T2:FIELDS->F1|F2。
记录内容,其键为第二二维表R2中的记录的下标,使用string对象存储。由于已独立存储第二二维表的列名称,故存储第二二维表记录时,不再需要存储列名称。将每行记录的键设置为下标,各个字段的值使用“|”作为分隔符,将各个字段的值拼接起来作为一个字符串进行存储。应当理解,使用“|”作为分隔符,假定各个字段的值不包含该字符。
查询索引,使用hash对象存储,用于快速定位第二二维表中满足指定列的记录。
往Redis写入第二二维表时,先清除Redis中第二二维表的旧数据,清除的数据包括该第二二维表中相关的第二时间戳,记录总数,列名称,记录以及查询索引数据。
二维表查询索引用来满足快速定位到指定列值的二维表记录下标。假设需要对二维表T(第一二维表或第二二维表)的列F1进行查询(T可以包含更多的列),二维表在列F1字段的值存在V1,V2,V3,...,当F1的值为V1时的二维表记录的下标有1,4;当F1的值为V2时的二维表记录下标有2,5;当F1的值为V3时的二维表记录下标有3,6,7,则对于F1字段构造的索引为:
T:F1:V1->1|4
T:F1:V2->2|5
T:F1:V3->3|6|7
采用string对象来存储记录下标,且下标之间使用“|”分隔。为提高存储效率,使用Redis的hash对象来存储以上关系。其中,键为T:F1,字段分别为V1,V2,V3,值分别为1|4,2|5,3|6|7。
同理,假设对字段F2构造的索引如下:
T:F2:T1->1|4|7
T:F2:T2->2|3|5|6
则构造好查询索引后,既可以单独对列F1或者F2进行查询,也可以同时指定列F1和列F2的条件。
例如,需要查询二维表T中满足列F1值为V2,列F2值为T2所有记录。由索引T:F1:V2->2|5可以知道列F1值为V2的记录下标有2,5,由索引T:F2:T2->2|3|5|6可以知道列F2的值为T2的记录下标有2,3,5,6,对两个记录下标求交集,得到下标2,5,即记录2和记录5满足查询条件。
往Redis写入第二二维表的过程涉及多步操作,为避免在写入数据的过程中其他应用程序对该第二二维表数据进行修改,本申请使用了Redis的事务机制。
开始向Redis写入第二二维表记录时,首先使用Redis的WATHCH命令,最后一步则使用Redis的EXEX提交事务。如果在执行WATHCH命令后,有其他应用程序对该第二二维表数据进行了修改,则事务执行失败,无法往Redis写入该第二二维表相关数据,而由其他应用程序写入。
往Redis写入最新的第二二维表以及相关的查询索引后,就可以进行查询满足指定条件的记录了,步骤140中,从Redis查询第二二维表记录的过程如下:
查询时,区分是否需要读取整个第二二维表。如果需要查询整个第二二维表,则先读取该第二二维表记录总数,接着取出字段名称,根据第二二维表的记录总数,对记录下标进行循环遍历,取出第二二维表的所有记录。
如果需要根据列对第二二维表进行查询,则先根据查询条件使用第二二维表的查询索引获取记录下标,接着取出字段名称,最后根据记录下标取出指定的记录。获取满足指定查询条件的记录下标,可以参考上文有关查询索引的构造与使用。
往Redis读取第二二维表的过程涉及多步操作,为避免在读取数据的过程中其他应用程序对该第二二维表数据进行修改,本申请同样使用Redis的事务机制。读取整个第二二维表数据后,首先执行WATCH命令,获取记录总数或记录下标后,执行MULTI命令,执行所有Redis查询命令后,执行EXEC命令。如果读取第二二维表数据过程中,其他应用程序修改了该第二二维表的数据,则读取失败。这时应用程序可以根据实际需要再次读取,或者提示报错。
本申请提供的关系数据库的高效查询方法,使用Redis存储与查询二维表的缓存,不是简单地根据查询条件来构造Redis缓存,而是将整个二维表以及查询条件索引缓存起来,提高了查询命中Redis缓存的概率,可以充分利用了Redis高性能的特点,将大部分请求落在Redis上处理,有利于减轻Oracle数据库的压力,并提升查询效率。
综合以上具体实施例的描述,本发明提供的一种关系数据库的高效查询方法和装置,与现有技术相比,具有如下优点:
第一,在Redis上创建二维表作为Oracle的缓存,可以从Redis缓存的二维表中查询获得记录,减轻了Oracle关系数据库的压力,提高了查询效率。。
第二,通过比较Redis上的二维表的时间戳和Oracle上的二维表的时间戳的先后,判断是否需要更新Redis上的二维表,保证数据记录的准确性和一致性。
第三,在Oracle上的二维表发生***、更新或删除操作时,使用触发器更新Oracle上的第一二维表的第一时间戳,并通过轮询或读取Redis上第二二维表时,根据第一时间戳更新第二时间戳,由此进一步保证数据记录的准确性和一致性。
第四,使用Redis的事务机制,避免读取和写入数据的过程中其他应用程序对二维表数据进行修改。
最后,还需要说明的是,在本文中使用的术语"包括"、"包含"或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句"包括一个…"限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本发明并不局限于上述最佳实施方式,任何人应该得知在本发明的启示下做出的结构变化,凡是与本发明具有相同或相近的技术方案,均落入本发明的保护范围之内。
Claims (10)
1.一种关系数据库的高效查询方法,其特征在于,包括以下步骤:
将查询关系数据库获得的记录写入第一二维表并将所述第一二维表写入Redis生成第二二维表,所述第二二维表作为所述第一二维表的缓存,所述关系数据库上保存有第一二维表生成或更新时的第一时间戳;所述第二二维表中保存有所述第二二维表生成或更新时的第二时间戳;根据所述第一时间戳更新所述第二时间戳;
通过比较所述第一时间戳与所述第二时间戳的时间先后,判断所述二维表是否需要生成或更新,无所述第二时间戳视为所述第一时间戳在后;
如果所述第二二维表需要生成或更新,则根据查询条件从关系数据库读取满足查询条件的记录,然后将该记录以及查询索引写入Redis生成或更新所述第二二维表;否则,不更新所述第二二维表,从所述第二二维表中查询满足查询条件的记录。
2.根据权利要求1所述的方法,其特征在于,
将关系数据库中的记录写入所述第一二维表时,生成所述第一时间戳,并将所述第一时间戳与所述第一二维表的映射关系构造第三二维表,保存在关系数据库中;
关系数据库上设有触发器,当所述第一二维表发生***、更新或删除操作时,更新所述第一时间戳。
3.根据权利要求2所述的方法,其特征在于,判断是否需要生成或更新所述第二二维表包括以下步骤:
从关系数据库读取所述第一二维表的第一时间戳,从Redis读取与所述第一二维表对应的第二二维表的第二时间戳;
判断所述第二时间戳是否存在,如果所述第二时间戳不存在,则将所述第一二维表写入Redis生成所述第二二维表,并将所述第一时间戳写入所述第二二维表,形成所述第二时间戳;否则比较所述第一时间戳与所述第二时间戳的时间先后,如果所述第一时间戳在后,则根据所述第一二维表更新所述第二二维表及所述第二时间戳;如果所述第一时间戳与所述第二时间戳相同,则不需要更新所述第二二维表。
4.根据权利要求1所述的方法,其特征在于,将查询关系数据库获得的所述记录以及查询索引写入Redis生成或更新所述第二二维表,包括以下内容:
第二时间戳,用于标识是否需要更新所述第二二维表;
记录总数,用于查询所述第二二维表;
列名称;
记录内容,其键为所述第二二维表中的记录的下标;
查询索引,用于快速定位所述第二二维表中满足指定的列的记录。
5.根据权利要求4所述的方法,其特征在于,
在Redis上存储所述第二二维表的列名称时,使用分隔符将所述第二二维表中所有的列名称拼接起来作为一个字符串进行存储;
将所述第二二维表中的每行记录的键设置为下标,各个字段的值使用分隔符,将各个字段的值拼接起来作为一个字符串进行存储。
6.根据权利要求1所述的方法,其特征在于,开始向Redis写入第二二维表时,首先使用WATHCH命令,写入完成后使用EXEX提交事务。
7.根据权利要求1所述的方法,其特征在于,查询所述第二二维表的方法如下:先读取所述第二二维表的记录总数,接着取出字段名称,根据所述第二二维表的记录总数,对记录下标进行循环遍历,取出所述第二二维表中的所有记录。
8.根据权利要求1所述的方法,其特征在于,根据列对所述第二二维表进行查询的方法如下:先根据查询条件使用所述第二二维表的查询索引获取记录下标,接着取出字段名称,最后根据记录下标取出指定的记录。
9.一种关系数据库的高效查询装置,其特征在于,包括:
二维表创建模块,用于将查询关系数据库获得的记录写入第一二维表并将所述第一二维表写入Redis生成第二二维表,所述第二二维表作为所述第一二维表的缓存;
时间戳生成模块,用于在生成所述第一二维表时生成第一时间戳,并将所述第一时间戳与所述第一二维表的映射关系构造第三二维表保存在关系数据库中;将所述第一时间戳写入所述第二二维表,形成所述第二时间戳;
时间戳更新模块,用于所述第一二维表发生***、更新或删除操作时,更新所述第一时间戳;根据所述第一时间戳,更新所述第二时间戳;
比较模块,用于比较所述第一时间戳与所述第二时间戳的时间先后,判断所述第二二维表是否需要生成或更新,无所述第二时间戳视为所述第一时间戳在后;
第二二维表更新模块,用于根据比较模块得出的所述第二二维表是否需要生成或更新的结果,如果所述第二二维表需要更新,则根据查询条件从关系数据库读取满足查询条件的记录,然后将该记录以及查询索引写入Redis更新所述第二二维表;否则,不更新所述第二二维表。
10.根据权利要求9所述的装置,其特征在于,关系数据库上设有触发器,当所述第一二维表发生***、更新或删除操作时,通过所述触发器更新所述第一时间戳。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111544353.4A CN114218277A (zh) | 2021-12-16 | 2021-12-16 | 一种关系数据库的高效查询方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111544353.4A CN114218277A (zh) | 2021-12-16 | 2021-12-16 | 一种关系数据库的高效查询方法和装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114218277A true CN114218277A (zh) | 2022-03-22 |
Family
ID=80703047
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111544353.4A Pending CN114218277A (zh) | 2021-12-16 | 2021-12-16 | 一种关系数据库的高效查询方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114218277A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116166671A (zh) * | 2023-04-21 | 2023-05-26 | 南方电网数字电网研究院有限公司 | 一种内存数据库表格预关联的处理方法、***和介质 |
-
2021
- 2021-12-16 CN CN202111544353.4A patent/CN114218277A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116166671A (zh) * | 2023-04-21 | 2023-05-26 | 南方电网数字电网研究院有限公司 | 一种内存数据库表格预关联的处理方法、***和介质 |
CN116166671B (zh) * | 2023-04-21 | 2023-08-15 | 南方电网数字电网研究院有限公司 | 一种内存数据库表格预关联的处理方法、***和介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11182356B2 (en) | Indexing for evolving large-scale datasets in multi-master hybrid transactional and analytical processing systems | |
US8868512B2 (en) | Logging scheme for column-oriented in-memory databases | |
US8051045B2 (en) | Archive indexing engine | |
US8140495B2 (en) | Asynchronous database index maintenance | |
US8924365B2 (en) | System and method for range search over distributive storage systems | |
US7836037B2 (en) | Selection of rows and values from indexes with updates | |
CN112363979B (zh) | 一种基于图数据库的分布式索引方法和*** | |
WO2017070234A1 (en) | Create table for exchange | |
US20130218843A1 (en) | Intelligent data archiving | |
US8108431B1 (en) | Two-dimensional data storage system | |
CN105373541A (zh) | 数据库的数据操作请求的处理方法和*** | |
CN110928882B (zh) | 一种基于改进红黑树的内存数据库索引方法及*** | |
US20090106216A1 (en) | Push-model based index updating | |
US9594784B2 (en) | Push-model based index deletion | |
JPWO2010084754A1 (ja) | データベースシステム、データベース管理方法、及びデータベース構造 | |
CN114218277A (zh) | 一种关系数据库的高效查询方法和装置 | |
CN111666302A (zh) | 用户排名的查询方法、装置、设备及存储介质 | |
US10817507B2 (en) | Document store export/import | |
CN111125129A (zh) | 数据处理方法和装置、存储介质及处理器 | |
US11068451B2 (en) | Database column refresh via replacement | |
CN112463837B (zh) | 一种关系型数据库数据存储查询方法 | |
CN113407538A (zh) | 一种多源异构关系型数据库数据的增量采集方法 | |
Nørväg | Efficient use of signatures in object-oriented database systems | |
JP2003030040A (ja) | オブジェクトデータベースシステムの複数ハッシュインデックスおよび非ユニークインデックス管理方式 | |
CN117786164A (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 |