CN113961514A - 数据查询方法及装置 - Google Patents
数据查询方法及装置 Download PDFInfo
- Publication number
- CN113961514A CN113961514A CN202111557955.3A CN202111557955A CN113961514A CN 113961514 A CN113961514 A CN 113961514A CN 202111557955 A CN202111557955 A CN 202111557955A CN 113961514 A CN113961514 A CN 113961514A
- Authority
- CN
- China
- Prior art keywords
- file
- hash
- index
- target
- files
- 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
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/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
- G06F16/137—Hash-based
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/14—Details of searching files based on file metadata
- G06F16/148—File search processing
- G06F16/152—File search processing using file content signatures, e.g. hash values
-
- 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/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2246—Trees, e.g. B+trees
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Library & Information Science (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本公开提供了一种数据查询方法及装置。该方法应用于基于LSM树的数据库,LSM树包括多层结构,多层结构中的第K层包括M个文件,M个文件的文件索引与M个哈希范围存在一一映射关系,M个文件中的每个文件用于存储至少一个数据,且每个文件中存储的数据的key经过哈希运算后得到的哈希索引落入每个文件对应的哈希范围,该方法包括:接收查询请求,查询请求用于查询目标key对应的数据;对目标key进行哈希运算,得到目标key对应的第一哈希索引;根据第一哈希索引,从M个文件中确定第一目标文件的文件索引,其中,第一目标文件对应的哈希范围包含第一哈希索引;根据第一目标文件的文件索引,在第一目标文件中查询目标key对应的数据。
Description
技术领域
本公开涉及数据存储技术领域,具体涉及一种数据查询方法及装置。
背景技术
日志结构合并(Log Structured Merge,LSM)树经常被应用于非关系型数据库。在基于LSM树的存储系统中,数据通常是以key-value的形式进行存储。如果需要查询目标key在某层中的文件位置,则需要对该层的文件进行二分查找,以确定存储目标key的文件。
在上述查询方式中,不仅需要进行比较耗时的key字符串的比较,而且二分查找的时间复杂度为logN,也就是说,查询复杂度与该层的文件数量有关。该层的文件数量越多,查询所需要的时间可能越长。因此,采用上述二分查找的方式不利于提高查询速度。
发明内容
本公开实施例提供一种数据查询方法及装置,能够提高数据查询速度。
第一方面,提供了一种数据查询方法,所述方法应用于基于LSM树的数据库,所述LSM树包括多层结构,所述多层结构中的第K层包括M个文件,所述M个文件的文件索引与M个哈希范围存在一一映射关系,所述M个文件中的每个文件用于存储至少一个数据,且所述每个文件中存储的数据的key经过哈希运算后得到的哈希索引落入所述每个文件对应的哈希范围,所述方法包括:接收查询请求,所述查询请求用于查询目标key对应的数据;对所述目标key进行所述哈希运算,得到目标key对应的第一哈希索引;根据所述第一哈希索引,从所述M个文件中确定第一目标文件的文件索引,其中,所述第一目标文件对应的哈希范围包含所述第一哈希索引;根据所述第一目标文件的文件索引,在所述第一目标文件中查询所述目标key对应的数据。
第二方面,提供一种数据查询装置,所述装置应用于基于日志结构合并LSM树的数据库,所述LSM树包括多层结构,所述多层结构中的第K层包括M个文件,所述M个文件的文件索引与M个哈希范围存在一一映射关系,所述M个文件中的每个文件用于存储至少一个数据,且所述每个文件中存储的数据的key经过哈希运算后得到的哈希索引落入所述每个文件对应的哈希范围,所述装置包括:接收模块,用于接收查询请求,所述查询请求用于查询目标key对应的数据;哈希运算模块,用于对所述目标key进行所述哈希运算,得到目标key对应的第一哈希索引;第一确定模块,用于根据所述第一哈希索引,从所述M个文件中确定第一目标文件的文件索引,其中,所述第一目标文件对应的哈希范围包含所述第一哈希索引;查询模块,用于根据所述第一目标文件的文件索引,在所述第一目标文件中查询所述目标key对应的数据。
第三方面,提供一种数据查询装置,包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现如第一方面所述的方法。
第四方面,提供一种计算机可读存储介质,其上存储有可执行代码,当所述可执行代码被执行时,能够实现如第一方面所述的方法。
第五方面,提供一种计算机程序产品,包括可执行代码,当所述可执行代码被执行时,能够实现如第一方面所述的方法。
基于上述技术方案,本公开实施例通过建立key的哈希索引,并为每个文件设置对应的哈希范围,在查找时,可以通过将目标key的哈希索引与文件对应的哈希索引进行比较,来确定存储目标key的文件。key的哈希索引可以是对key进行哈希运算后得到的。由于哈希索引一般占用较少的比特位(小于或等于64比特),远小于key占用的比特位,因此,相比于将key进行比较的方案,采用哈希索引进行比较的方案可以大大降低查询时延,有利于提高查询速度。
另外,本公开实施例可以为每个文件设置对应的一个固定的哈希范围,如第K层的M个文件中每个文件都对应一个固定的哈希范围,即每个文件对应的哈希范围不会发生变化。因此,本公开实施例可以不使用二分查找的方式,而是可以通过计算的方式得到第一目标文件的文件索引,从而有利于提高查询速度。
附图说明
图1是本公开实施例提供的一种LSM树的架构示例图。
图2是本公开一实施例提供的数据查询方法的示意性流程图。
图3是本公开一实施例提供的LSM树的数据结构的示意图。。
图4是本公开一实施例提供的数据查询装置的结构示意图。
图5是本公开另一实施例提供的数据查询装置的结构示意图。
具体实施方式
下面将结合本公开实施例中的附图,对本公开实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅是本公开一部分实施例,而不是全部的实施例。
关系型数据库是支持关系模型的数据库系统,一般采用二维表结构的存储方式,数据以行和列的方式进行存储。关系型数据库按照结构化的方法存储数据,每个数据表都必须对各个字段定义好(也就是先定义好表的结构),再根据表的结构存入数据,这样做的好处就是由于数据的形式和内容在存入数据之前就已经定义好了,所以整个数据表就可以变得很清晰、一目了然,要读取和查询都十分方便,且可靠性和稳定性也比较高。但是,在写入新的数据后,修改数据表的结构就会十分困难,从而造成写效率比较低。由于关系型数据库中的数据表之间也有复杂的连接关系,因此数据表越多写效率越低。随着信息技术的高速发展和互联网的普及,数据量出现了飞跃式的增长,应用服务的数据存储规模和数据的访问量也随之增大,传统的关系型数据库已经无法满足需求,非关系型数据库(Not OnlySQL,NoSQL)应运而生。
NoSQL是非关系型数据存储的广义定义,NoSQL中的数据存储不需要固定的表结构,通常也不存在连接操作。NoSQL不使用传统的关系数据库模型,而是使用例如键值(key-value)存储、文档型的、列存储、图型数据库、xml等方式存储数据模型。其中,用的最多的是key-value存储。NoSQL数据库中的数据之间无关系,在架构的层面上带来了可扩展的能力。同样由于数据之间无关系,数据库的结构简单,在大数据量下,NoSQL表现出非常高的读写性能。
日志结构合并(The Log-Structured Merge,LSM)树常被应用于键值对(key-value)存储系统的设计。因此,LSM树在NoSQL系统里也非常常见,基本已经成为必选方案了。目前很多产品都使用了LSM树,GeaBase图数据库的底层key-value数据引擎使用的就是LSM树结构。直接或间接应用LSM树的产品例如还可以包括LevelDB,RocksDB,MongoDB,TiDB,HBase等。
LSM树可以包括两个或以上的独立的存储结构,每个结构都针对其各自的底层存储介质进行了优化,以使得数据可以在两个结构之间进行高效、批量的同步。为了便于理解,下面结合图1,对本公开实施例提及的LSM树的整体架构进行介绍。
比如在本公开中为了方便说明使用了最简单的两个存储结构。如图1所示,一个存储结构常驻内存中,保存了所有最近写入的键值对,并且可以随时原地更新,同时支持随时查询。另外一个存储结构常驻在非易失性存储设备中,该非易失性存储设备例如可以是硬盘或磁盘等。LSM树包括用于存储数据的多层结构,该多层结构例如可以表现为Level 0至Level N多个层级,其中Level N即为上述多层结构中的最后一个层级。LSM树的存储容量从Level 0至Level N逐渐增大,一般每一层的容量是上一层的10倍。每层可以包括一个或多个排序队列表(Sorted Sequence Table,SST),SST是一种拥有持久化,有序且不可变的键值存储结构,它的key和value都是任意的字节数组。每个SST文件内部的数据在key上是有序的,且每一层的数据都是在key上全局有序的。也就是说,在同一层级中,不同SST文件中的key互不重叠。但是,Level 0层是可以有重叠的。也就是说,Level 0只保证每个SST文件内部有序,同层多个SST文件之间可能会重叠,这是LSM树的构建机制决定的,本公开在此不做详细阐述。
在基于LSM树的存储系统中,随着内存中的数据不断的顺序追加写入,数据范围互相交叠的层越来越多,相同key的数据不断积累,从而引起读性能下降和空间膨胀。因此,合并(Compaction)机制被引入,通过不断的合并或删除数据,将多层进行合并的方式来优化读性能和空间问题。
下面以Level 0层向Level 1层进行合并为例,对合并过程进行描述。当Level 0层的数据达到预设阈值时,就需要将Level 0层和Level 1层进行合并,类似归并排序,这个过程就是合并。在合并过程中,Level 1层中所有与Level 0层存在key重叠的文件都需要参与合并。合并完成之后,会重新生成新的文件。合并出来的新的文件会顺序写入Level 1层,替换掉原来的老的Level 1层的文件。当Level 1层的数据达到预设阈值时,会继续和下层(如Level 2层)合并。合并完成之后,所有旧文件都可以删掉,而仅留下新的文件。
举例说明,当Level 0层的数据达到预设阈值后,可以选择Level 0层的一个或多个文件,假设选择Level 0层的文件0-1,然后在Level 1层中查询与该文件0-1 的key存在重叠的文件(如文件1-1、1-2),然后将文件0-1、文件1-1、文件1-2进行合并,得到新的文件1-1、1-2、1-3,并存储在Level 1层中。可以理解的是,文件1-1、1-2、1-3也是按照key的顺序进行排列后得到的。合并完成之后,可以删除Level 0层的文件0-1,以及原来的Level 0层的文件1-1、1-2。随后,Level 0层中继续写入数据,当Level 0层中的数据达到预设阈值后,重复上述步骤。选择Level 0层的一个或多个文件与Level 1层中存在key重叠的文件进行合并,继续生成新的文件。其他层的文件合并过程也是采用类似的原理,此处不再赘述。
在刚开始合并过程中,假设Level 0层的文件0-1的key的范围为1~100,且Level 0层的数据达到预设阈值,则将Level 0层的文件合并至Level 1层。由于Level 1层还没有文件,则可以将Level 0层的文件0-1合并至Level 1层的文件1-1,文件1-1对应的key的范围为1~100。Level 0层继续写入数据,当Level 0层的数据再次达到阈值后,继续将文件0-1与Level 1层的文件进行合并。假设此时Level 0层的文件0-1的key的范围为50~150,则Level1层中与key为50~150存在重叠的文件为文件1-1,则将文件1-1与Level 0层的文件0-1进行合并,生成新的文件1-1和文件1-2,文件1-1对应的key的范围为1~80,文件1-2对应的key的范围为81~150。将新生成的文件写入Level 1层,且删除原来旧的文件0-1和1-1。
由于上层文件中的数据总是最新的,越老的数据在越高的Level。用户在进行数据查询时,可以从最上层开始进行查询。只有最上层没有用户想要查询的数据时,再从下一层中进行查询。具体地,当用户想要查询目标key对应的数据时,可以先从内存中查询与该key对应的数据,当内存中没有目标key时,再从Level 0层中进行查询。如果Level 0层中没有目标key,则继续从Level 1层中查询,以此类推,直到找到目标key对应的数据。
在对任意一层进行数据查询的过程中,可以将目标key(或称为待查询key)与各个文件中的key进行比较,以确定各个文件中是否存在目标key。查找的方式例如可以为遍历的方式,例如可以按顺序将各个文件的key分别与目标key进行对比,以确定存储有目标key的文件。如果通过遍历的方式进行查询,需要将每个文件分别与目标key进行比较,确定每个文件中是否包括目标key,这势必会带来较大的复杂度。
为了降低复杂度,可以将key在每一层中进行有序(如从小到大的顺序)存储,在有序存储的情况下,可以使用二分查找的方式来快速定位目标key所在的文件位置。下面对二分查找的过程进行描述。
例如,LSM树可以将数据分散存储在多个SST文件中,并且记录每个SST文件的最大key的最小key。当需要在某层中查询目标key对应的数据时,可以先将目标key与该层中间的文件进行比较,比较目标key与该中间文件的最大key、最小key之间的关系。如果目标key介于最大key和最小key之间,即目标key小于最大key且大于最小key,或者目标key等于最大key或等于最小key,则该中间文件即为目标key所在的文件。进一步地,可以从该中间文件中查询与该目标key对应的数据。如果目标key大于最大key,则可以从该层的后半部分的文件中继续二分查找。如果目标key小于最小key,则可以从该层的前半部分的文件中继续二分查找。通过以上二分查找过程,可以定位到目标key在该层的哪个文件中。
不论是二分查找还是对文件进行遍历查找,都需要将目标key与文件中存储的key进行对比,而key通常都是较长的字符串,将key进行对比会消耗大量的时间,从而会影响查询速度。例如,以key为地址为例,由于一个汉字占用2个字节,因此,一个地址至少需要占用十几个甚至几十个字节。字节数越多,key比较的复杂度就越大。因此,以key进行比较不利于提高查询速度。
另外,对于文件的合并过程,由上文可知,上层中的某个文件合并到下层时,需要在下层中查找与上层文件存在key重叠的待合并文件。假设key在每一层中进行有序存储,则待合并文件的查找过程也可以采用二分查找的方式。例如,假设需要对上层文件中的文件1进行合并,文件1中key的范围是1~100,则从下层文件中查找包含key为1~100的文件。在进行查找时,需要将key=1和key=100分别作为目标key,按照上文描述的二分查找过程,确定下层中包含key=1和key=100的两个文件,这两个文件之间的文件(包括这两个文件)即为待合并文件。
通过上文的描述可知,在文件的合并过程中,也需要将目标key与文件中的key进行对比,而key的对比需要消耗大量的时间,从而影响合并速度。
为了解决上述问题,本公开实施例通过建立key的哈希索引(hash index),并为每个文件设置对应的哈希范围,在查找时,可以通过将目标key的哈希索引与文件对应的哈希索引进行比较,来确定存储目标key的文件。key的哈希索引可以是对key进行哈希运算后得到的。由于哈希索引一般都占用较少的比特位(小于或等于64比特),远小于key占用的比特位,因此,相比于将key进行比较的方案,采用哈希索引进行比较的方案可以大大降低查询时延,有利于提高查询速度。
另外,由于key是随机的且长度不固定的,因此,key的范围是无法预知的。以key为地址为例,key的取值范围是无法预知的,无法为每层文件预设一个固定范围以包含所有的key。另外,根据上文描述的文件合并过程可知,每个文件对应的key的范围是变化的,即某个key并不是存储在固定的文件中。仍以上文描述的合并过程为例,刚开始文件1-1对应的key的范围为1~100,随着数据不断写入,文件1-1对应的key的范围变为1~80。虽然上文描述的二分查找方式可以提高查询效率,但其查询复杂度仍为O(logN),N为某层的文件数量,也就是说,其复杂度会随着每层文件数量的增加而增加。因此,上述二分查找方式无法快速定位到目标文件。
基于此,本公开实施例提供一种数据查询方法,可以在不使用二分查找的情况下,快速定位每层中存储有目标key的文件。下面对本公开实施例的方法进行详细介绍。
前文提到,可以对key进行哈希运算来获得key对应的哈希索引。哈希运算后得到的数据为固定长度,也就是说,不同key对应的哈希索引的长度相同。换句话说,不论key的字符串有多长或者多短,都可以将key映射到固定长度的哈希索引上。该固定长度的哈希索引可以包含所有的key。例如,以哈希索引为10个比特为例,任何一个key经过哈希运算后,都可以对应到0~210-1之间的某个哈希索引。因此,本公开实施例可以为每个文件设置对应的固定哈希范围,从而可以不使用二分查找的方式,而是使用公式计算的方式快速定位存储有目标key的文件。
一个key可以对应唯一的一个哈希索引。不同的key可以对应不同的哈希索引,或者多个key可以对应一个哈希索引,本公开实施例对此不做具体限定。
key对应的哈希索引可以是直接使用哈希函数计算得到的。或者,为了降低哈希索引的比特位数,也可以先使用哈希函数得到第一结果,然后仅取第一结果的部分比特作为哈希索引。例如,以哈希索引为10比特为例,由于哈希函数计算的结果可能大于10个比特,因此可以将哈希函数的计算结果与(210-1)进行按位与操作,得到key对应的哈希索引。例如,key对应的哈希索引可以通过如下公式计算得到:
哈希索引=HashFunction(Key) & (2N – 1)
其中,HashFunction表示哈希函数,&表示按位与操作,N为哈希索引的比特位数。
由上述公式可知,任意一个key可以固定映射到0~2N–1之间的某个哈希值。当N等于10时,任意一个key可以固定映射到0~1023之间的某个哈希值。
由于任意一个key可以映射到一个固定的哈希范围内,因此,本公开实施例可以为每个文件设置对应的哈希范围,即每个文件对应的哈希范围可以是固定的。以LSM树的第K层为例,第K层为LSM树的任意一层,第K层可以包括M个文件,K和M均为整数,M个文件的文件索引与M个哈希范围存在一一映射关系,即一个文件对应一个哈希范围。该M个文件中的每个文件用于存储至少一个数据,且每个文件中存储的数据的key经过哈希运算后得到的哈希索引落入每个文件对应的哈希范围。以M个文件包括第一文件为例,第一文件对应的哈希范围为0~100,则只有key经过哈希运算后得到的哈希索引落入0~100之间,该key对应的数据才会被存储在第一文件中。
上述M个文件中可以存储key对应的哈希索引、key以及key对应的数据,也就是说,M个文件中除了存储key-value之外,还可以存储key对应的哈希索引。
下面结合图2,对本公开实施例的数据查询方法进行描述。图2所示的方法可应用于上文描述的LSM树。图2所示的方法可以包括步骤S210~S240。
在步骤S210、接收查询请求。该查询请求用于查询目标key对应的数据。
在步骤S220、对目标key进行哈希运算,得到目标key对应的第一哈希索引。
对目标key进行哈希运算的方式与文件中存储的key的哈希索引的运算方式一致。例如,如果在数据存储时,是采用第一哈希函数对key进行哈希运算,从而确定存储该key的文件位置,则在查询时,也同样使用第一哈希函数对目标key进行哈希运算,以得到目标key对应的第一哈希索引。
在步骤S230、根据第一哈希索引,从M个文件中确定第一目标文件的文件索引。其中,第一目标文件对应的哈希范围包含第一哈希索引。或者说,第一目标文件为存储有第一哈希索引的文件。
在本公开实施例中,由于M个文件中每个文件都对应一个固定的哈希范围,即每个文件对应的哈希范围不会发生变化,因此,可以不使用二分查找的方式,如可以通过计算的方式得到第一目标文件的文件索引,从而有利于提高查询速度。例如,如果M个文件对应的哈希范围具有一定的规律,则可以通过公式直接计算得到第一目标文件的文件索引。
在步骤S240、根据第一目标文件的文件索引,在第一目标文件中查询目标key对应的数据。
在第一目标文件中查询目标key对应的数据时,可以将第一哈希索引与第一目标文件中存储的哈希索引进行对比,如果与第一哈希索引对应的key有多个,则可以继续将该目标key与该多个key进行对比,以确定目标key对应的数据。
在查询目标key对应的数据时,可以从LSM树的首层开始进行查询,每一层的查询都可以按照上述步骤进行查询。下文将以第K层为例,对数据查询过程以及合并过程进行描述。
上述M个哈希范围可以不重叠。也就是说,该M个哈希范围包括的哈希索引不重叠或完全不相同。如果M个哈希范围不重叠,可以保证一个哈希索引对应的数据仅会被存储在同一层的一个文件中。
该M个哈希范围可以是将哈希索引按顺序排列后生成的,哈希索引可以按照从大到小或者从小到大的顺序进行排列。例如,在对哈希索引排序后,可以将连续的哈希索引设置为一个哈希范围。也就是说,M个哈希范围中每个哈希范围包含的哈希索引连续。如0~99为一个哈希范围,100~199为一个哈希范围,200~299为一个哈希范围等。又例如,一个哈希范围内的哈希索引也可以不连续。如该M个哈希范围中,一个哈希范围包含的哈希索引均为奇数,另一个哈希范围包含的哈希索引均为偶数。或者,一个哈希范围内的相邻哈希索引之间的差值还可以为2、3或4等。如果M个哈希范围中每个哈希范围包含的哈希索引连续,则将有利于提高文件的合并速度和查询速度。
该M个哈希范围包含的哈希索引的数量可以相等,也可以不相等。例如,上述M个哈希范围包含的哈希索引的数量相等,如一个哈希范围为0~99,一个哈希范围为100~199,一个哈希范围为200~299等。又例如,该M个哈希范围包含的哈希索引的数量可以依次递增或递减。如M个哈希范围中,一个哈希范围为0~99,一个哈希范围为100~249,一个哈希范围为250~449等。
为了使得任意一个key在第K层有其对应的文件,则该M个哈希范围可以包含全部数量的哈希索引。举例说明,如果哈希索引的比特位数为N,则该M个哈希范围能够包含0~2N–1之间的任意一个哈希索引。如果该M个哈希范围均分0~2N–1之间的哈希索引,则每个哈希范围包含的哈希索引的数量为(2N–1)/M。
以M=4,N=10为例,为了提高数据的查询速度和文件的合并速度,每个哈希范围都可以包括连续的且数量相等的哈希索引。如第一个哈希范围为0~255,第二个哈希范围为256~511,第三个哈希范围为512~767,第四个哈希范围为768~1023。
如果每个哈希范围都可以包括连续的且数量相等的哈希索引,则可以通过除法的计算公式计算第一目标文件的文件索引。例如,仍以上文描述的哈希索引的比特位数为N,每个哈希范围包含的哈希索引的数量为2N/M为例,在进行数据查询时,可以先计算目标key的第一哈希索引,记为X,然后可以使用公式,得到第一目标文件的文件索引。其中,⌊⌋表示向下取整。需要说明的是,本公开实施例是将第一个文件的文件索引记为0,第二个文件的文件索引记为1进行排序的。如果将第一个文件的文件索引记为1,第二个文件的文件索引记为2等,则可以使用公式,计算第一目标文件的文件索引,其中,⌈⌉表示向上取整。
考虑到计算机可以通过移位操作实现除法计算,而移位计算相比于除法计算能够进一步降低计算时延,提高查询速度。因此,本公开实施例可以将第K层的文件数量设置为2的指数幂,使得计算机可以通过移位实现除法计算。
如果文件数量为2的指数幂,则上述公式中所有的参数都可以表示为2的指数幂,从而可以通过移位实现除法计算。
假设第K层的文件数量为2m,即M=2m,则在确定第一目标文件的文件索引时,可以将第一哈希索引右移(n-m)位,得到第一目标文件的文件索引,其中,n为哈希索引的比特位数,m、n为整数,且n≥m。
下面结合图3,对本公开实施例的方案进行详细介绍。
图3所示的是本公开实施例提供的一种LSM树的数据结构。在LSM树的多层结构中,每层的文件数量均为2的指数幂。在LSM树的多层结构中,该多层结构中的文件数量从首层至最后一层逐渐增多。如L0层的文件数量为4,L1层的文件数量为16,L2层的文件数量为64。
假设n=10,则每层的多个文件对应的哈希范围可以包括0~1023之间的任意一个哈希索引。图3中一个方框表示一个文件,每个方框中的数字表示该文件对应的哈希范围。每层中的文件按顺序均分0~1023之间的哈希索引。
任意一个key在某一层中的文件索引可以通过以下公式计算得到:
文件索引=key的哈希索引>>(n-m)
其中,>>表示右移操作。也就是说,可以将第一哈希索引右移(n-m)个比特位,得到第一目标文件的文件索引。
假设第一哈希索引为100,100表示成10比特的二进制为0001100100。
由于L0层的文件数量为22,即m=2,则哈希索引100在L0层中的文件索引为0001100100>>(10-2)=0,即哈希索引100存储在L0层的文件0中。
由于L1层的文件数量为24,即m=4,则哈希索引100在L1层中的文件索引为0001100100>>(10-4)=1,即哈希索引100存储在L1层的文件1中。
由于L2层的文件数量为26,即m=6,则哈希索引100在L2层中的文件索引为0001100100>>(10-6)=6,即哈希索引100存储在L2层的文件6中。
由上文的描述可知,本公开实施例可以将哈希索引分为2m个哈希范围,在进行数据查询时,可以通过移位操作快速找到目标文件,有利于提高查询速度。
上文描述的是数据查询过程,下面对文件的合并过程进行描述。文件的合并过程同样也需要涉及哈希索引的查询,未详细描述的查询过程可以参见上文的描述,此处不再赘述。
仍以第K层为例,在进行文件合并时,可以先从第K层的M个文件中选择待合并文件。待合并文件可以是M个文件中数据量达到预设阈值的文件,或者待合并文件可以是M个文件中数据量最多的文件。当然,待合并文件也可以是M个文件中的任意一个文件,本公开实施例对此不做具体限定。
假设需要将第K层中的某个待合并文件与第S层的文件进行合并,S大于K,第S层的文件数量为N,则需要从N个文件中确定第二目标文件的文件索引,其中,第二目标文件对应的哈希范围与待合并文件对应的哈希范围一致,也就是说,第二目标文件对应的哈希范围包含待合并文件对应的哈希范围,或者,第二目标文件对应的哈希范围与待合并文件对应的哈希范围有重叠。优选地,第二目标文件对应的哈希范围刚好等于待合并文件对应的哈希范围。第二目标文件可以为一个或多个,在确定了第二目标文件之后,可以将待合并文件与第二目标文件进行合并,重新生成一个或多个文件。如果第二目标文件包括多个文件,则第二目标文件对应的哈希范围为该多个文件对应的哈希范围的叠加。
可以理解的是,第S层可以是与第K层相邻的层,或者,第S层与第K层之间还存在其他的层,本公开实施例对此不做具体限定。
在进行文件合并时,可以基于待合并文件对应的哈希范围,确定第S层中的第二目标文件,然后可以将待合并文件与第二目标文件进行合并。由于在确定第二目标文件过程中,不需要进行key的比较,而是进行哈希索引的比较,而哈希索引的比特位数通常较小,因此,通过哈希索引确定第二目标文件的方式有利于提高合并速度。
另外,由于每个文件对应的哈希范围是固定的,因此,可以通过公式计算的方式直接得到第二目标文件的文件索引,而不需要使用二分查找的方式来确定,从而可以进一步提高文件的合并速度。
在确定第二目标文件时,可以对待合并文件对应的最大哈希索引和最小哈希索引分别进行计算,确定第S层中包含最大哈希索引的文件以及包含最小哈希索引的文件,其确定方式可以与上文描述的数据查询方式类似。为方便描述,可以将包含最大哈希索引的文件称为最大文件,将包含最小哈希索引的文件称为最小文件。位于最大文件和最小文件之间的文件即为第二目标文件。
为了减少合并过程中的文件数量,可以将下层的文件数量设置为上层文件数量的整数倍。以上文中的第K层和第S层为例,第S层的文件数量N为第S层的文件数量M的整数倍。在该情况下,下层中的一个文件对应的哈希范围不会与上层中的多个文件对应的哈希范围重叠。
仍以图3为例,对本公开实施例的文件合并过程进行描述。
假设第K层的文件数量为2m,即M=2m,第S层的文件数量为2p,即N=2p,p>m。在确定第二目标文件的文件索引时,可以通过以下公式计算得到:
[i << (p - m), (i + 1) << (p - m))
其中,i表示待合并文件的文件索引,<<表示左移操作。也就是说,可以将待合并文件的文件索引以及待合并文件的下一个文件的文件索引分别左移(p-m)位,得到第二目标文件的文件索引。
继续参见图3,以待合并文件为L1层中的文件3为例进行说明。L1层的文件数量为22,L1层的文件3对应的哈希范围为192~255。第S层为L2层,L2层的文件数量24。在确定L2层的第二目标文件时,可以通过以下公式计算得到:
[3 << (6 - 4), (3 + 1) << (6 - 4))
由于3的二进制表示为11,11左移两位得到的二进制表示为1100,即12。由于4的二进制表示为100,则100右移两位得到的二进制表示为10000,即16。则第二目标文件的索引为[12,16),即第二目标文件的索引为12,13,14,15。
由上文的描述可知,在层与层之间的文件合并过程中,本公开实施例可以通过简单的移位操作,即可快速找到与待合并文件存在重叠的文件集合,而不需要复杂的二分查找过程,从而有利于提高文件的合并速度。
上文结合图1至图3,详细描述了本公开的方法实施例,下面结合图4至图5,详细描述本公开的装置实施例。应理解,方法实施例的描述与装置实施例的描述相互对应,因此,未详细描述的部分可以参见前面方法实施例。
图4是本公开实施例提供的数据查询装置的示意性结构图。图4的装置400可应用于基于LSM树的数据库,该LSM树可以为上文描述的任意一种LSM树。所述LSM树包括多层结构,所述多层结构中的第K层包括M个文件,所述M个文件的文件索引与M个哈希范围存在一一映射关系,所述M个文件中的每个文件用于存储至少一个数据,且所述每个文件中存储的数据的key经过哈希运算后得到的哈希索引落入所述每个文件对应的哈希范围。图4的装置400包括接收模块410、哈希运算模块420、第一确定模块430和查询模块440。
接收模块410,用于接收查询请求,所述查询请求用于查询目标key对应的数据.
哈希运算模块420,用于对所述目标key进行所述哈希运算,得到目标key对应的第一哈希索引。
第一确定模块430,用于根据所述第一哈希索引,从所述M个文件中确定第一目标文件的文件索引,其中,所述第一目标文件对应的哈希范围包含所述第一哈希索引。
查询模块440,用于根据所述第一目标文件的文件索引,在所述第一目标文件中查询所述目标key对应的数据。
可选地,所述M个哈希范围中的每个哈希范围包含的哈希索引连续,且所述M个哈希范围不重叠。
可选地,所述M个哈希范围包含相同数量的哈希索引。
可选地,所述M的取值为2m,所述第一确定模块430用于:将所述第一哈希索引右移(n-m)位,得到所述第一目标文件的文件索引,n为哈希索引的比特位数,m、n为整数,且n≥m。
可选地,所述多层结构的第S层包括N个文件,所述装置400还包括:选择模块,用于从所述M个文件中选择待合并文件;第二确定模块,用于根据所述待合并文件对应的哈希范围,从所述N个文件中确定第二目标文件的文件索引,所述第二目标文件对应的哈希范围与所述待合并文件对应的哈希范围一致;合并模块,用于根据所述第二目标文件的文件索引,将所述待合并文件与所述第二目标文件进行合并。
可选地,N为M的整数倍。
可选地,M的取值为2m,N的取值为2p,p>m,所述第二确定模块用于:将所述待合并文件的文件索引以及所述待合并文件的下一个文件的文件索引分别左移(p-m)位,得到所述第二目标文件的文件索引。
图5是本公开又一实施例提供的数据查询装置的结构示意图。该装置500可以为基于LSM树的数据库。装置500可以包括存储器510和处理器520。存储器510可用于存储可执行代码。处理器520可用于执行所述存储器510中存储的可执行代码,以实现前文描述的各个方法中的步骤。在一些实施例中,该装置500还可以包括网络接口530,处理器520与外部设备的数据交换可以通过该网络接口530实现。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其他任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本公开实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(Digital Subscriber Line,DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如,软盘、硬盘、磁带)、光介质(例如数字视频光盘(Digital Video Disc,DVD))、或者半导体介质(例如固态硬盘(Solid State Disk,SSD))等。
本领域普通技术人员可以意识到,结合本公开实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本公开的范围。
在本公开所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本公开各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
以上所述,仅为本公开的具体实施方式,但本公开的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应以所述权利要求的保护范围为准。
Claims (15)
1.一种数据查询方法,所述方法应用于基于日志结构合并LSM树的数据库,所述LSM树包括多层结构,所述多层结构中的第K层包括M个文件,所述M个文件的文件索引与M个哈希范围存在一一映射关系,所述M个文件中的每个文件用于存储至少一个数据,且所述每个文件中存储的数据的key经过哈希运算后得到的哈希索引落入所述每个文件对应的哈希范围,
所述方法包括:
接收查询请求,所述查询请求用于查询目标key对应的数据;
对所述目标key进行所述哈希运算,得到目标key对应的第一哈希索引;
根据所述第一哈希索引,从所述M个文件中确定第一目标文件的文件索引,其中,所述第一目标文件对应的哈希范围包含所述第一哈希索引;
根据所述第一目标文件的文件索引,在所述第一目标文件中查询所述目标key对应的数据。
2.根据权利要求1所述的方法,所述M个哈希范围中的每个哈希范围包含的哈希索引连续,且所述M个哈希范围不重叠。
3.根据权利要求2所述的方法,所述M个哈希范围包含相同数量的哈希索引。
4.根据权利要求3所述的方法,所述M的取值为2m,所述根据所述第一哈希索引,从所述M个文件中确定第一目标文件的文件索引,包括:
将所述第一哈希索引右移(n-m)位,得到所述第一目标文件的文件索引,n为哈希索引的比特位数,m、n为整数,且n≥m。
5.根据权利要求1所述的方法,所述多层结构的第S层包括N个文件,所述方法还包括:
从所述M个文件中选择待合并文件;
根据所述待合并文件对应的哈希范围,从所述N个文件中确定第二目标文件的文件索引,所述第二目标文件对应的哈希范围与所述待合并文件对应的哈希范围一致;
根据所述第二目标文件的文件索引,将所述待合并文件与所述第二目标文件进行合并。
6.根据权利要求5所述的方法,N为M的整数倍。
7.根据权利要求6所述的方法,M的取值为2m,N的取值为2p,p>m,所述根据所述待合并文件对应的哈希范围,从所述N个文件中确定第二目标文件的文件索引,包括:
将所述待合并文件的文件索引以及所述待合并文件的下一个文件的文件索引分别左移(p-m)位,得到所述第二目标文件的文件索引。
8.一种数据查询装置,所述装置应用于基于日志结构合并LSM树的数据库,所述LSM树包括多层结构,所述多层结构中的第K层包括M个文件,所述M个文件的文件索引与M个哈希范围存在一一映射关系,所述M个文件中的每个文件用于存储至少一个数据,且所述每个文件中存储的数据的key经过哈希运算后得到的哈希索引落入所述每个文件对应的哈希范围,
所述装置包括:
接收模块,用于接收查询请求,所述查询请求用于查询目标key对应的数据;
哈希运算模块,用于对所述目标key进行所述哈希运算,得到目标key对应的第一哈希索引;
第一确定模块,用于根据所述第一哈希索引,从所述M个文件中确定第一目标文件的文件索引,其中,所述第一目标文件对应的哈希范围包含所述第一哈希索引;
查询模块,用于根据所述第一目标文件的文件索引,在所述第一目标文件中查询所述目标key对应的数据。
9.根据权利要求8所述的装置,所述M个哈希范围中的每个哈希范围包含的哈希索引连续,且所述M个哈希范围不重叠。
10.根据权利要求9所述的装置,所述M个哈希范围包含相同数量的哈希索引。
11.根据权利要求10所述的装置,所述M的取值为2m,所述第一确定模块用于:
将所述第一哈希索引右移(n-m)位,得到所述第一目标文件的文件索引,n为哈希索引的比特位数,m、n为整数,且n≥m。
12.根据权利要求8所述的装置,所述多层结构的第S层包括N个文件,所述装置还包括:
选择模块,用于从所述M个文件中选择待合并文件;
第二确定模块,用于根据所述待合并文件对应的哈希范围,从所述N个文件中确定第二目标文件的文件索引,所述第二目标文件对应的哈希范围与所述待合并文件对应的哈希范围一致;
合并模块,用于根据所述第二目标文件的文件索引,将所述待合并文件与所述第二目标文件进行合并。
13.根据权利要求12所述的装置,N为M的整数倍。
14.根据权利要求13所述的装置,M的取值为2m,N的取值为2p,p>m,所述第二确定模块用于:
将所述待合并文件的文件索引以及所述待合并文件的下一个文件的文件索引分别左移(p-m)位,得到所述第二目标文件的文件索引。
15.一种数据查询装置,包括存储器和处理器,所述存储器中存储有可执行代码,所述处理器被配置为执行所述可执行代码,以实现权利要求1-7中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111557955.3A CN113961514B (zh) | 2021-12-20 | 2021-12-20 | 数据查询方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111557955.3A CN113961514B (zh) | 2021-12-20 | 2021-12-20 | 数据查询方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113961514A true CN113961514A (zh) | 2022-01-21 |
CN113961514B CN113961514B (zh) | 2022-03-08 |
Family
ID=79473285
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111557955.3A Active CN113961514B (zh) | 2021-12-20 | 2021-12-20 | 数据查询方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113961514B (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114416651A (zh) * | 2022-03-30 | 2022-04-29 | 支付宝(杭州)信息技术有限公司 | 数据存储方法及装置、数据查找方法及装置 |
CN114817147A (zh) * | 2022-07-01 | 2022-07-29 | 北京网藤科技有限公司 | 一种通过二级索引进行文件特征值快速检索的方法和系统 |
CN115061637A (zh) * | 2022-07-12 | 2022-09-16 | 平安科技(深圳)有限公司 | 磁盘数据索引方法、装置、计算机设备及存储介质 |
CN115145954A (zh) * | 2022-09-01 | 2022-10-04 | 北京奥星贝斯科技有限公司 | 一种数据查询方法、数据存储方法及装置 |
CN115576899A (zh) * | 2022-12-09 | 2023-01-06 | 深圳市木浪云科技有限公司 | 构建索引的方法和装置以及文件查找方法和装置 |
WO2023165272A1 (zh) * | 2022-03-03 | 2023-09-07 | 蚂蚁云创数字科技(北京)有限公司 | 数据存储及查询 |
CN117785890A (zh) * | 2024-02-27 | 2024-03-29 | 支付宝(杭州)信息技术有限公司 | 一种基于lsm树的数据遍历查询方法及相关设备 |
Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105608224A (zh) * | 2016-01-13 | 2016-05-25 | 广西师范大学 | 一种提高海量数据查询性能的正交多哈希映射索引方法 |
CN105787093A (zh) * | 2016-03-17 | 2016-07-20 | 清华大学 | 一种基于LSM-Tree结构的日志文件系统的构建方法 |
US9537972B1 (en) * | 2014-02-20 | 2017-01-03 | Fireeye, Inc. | Efficient access to sparse packets in large repositories of stored network traffic |
CN107526550A (zh) * | 2017-09-06 | 2017-12-29 | 中国人民大学 | 一种基于日志结构合并树的两阶段合并方法 |
CN107870970A (zh) * | 2017-09-06 | 2018-04-03 | 北京理工大学 | 一种数据存储查询方法及系统 |
US20180107402A1 (en) * | 2016-10-19 | 2018-04-19 | Acronis International Gmbh | System and method for data storage using log-structured merge trees |
CN109189759A (zh) * | 2018-08-01 | 2019-01-11 | 华为技术有限公司 | Kv存储系统中的数据读取方法、数据查询方法、装置及设备 |
CN110347852A (zh) * | 2019-06-06 | 2019-10-18 | 华中科技大学 | 嵌入横向扩展键值存储系统的文件系统及文件管理方法 |
CN112486994A (zh) * | 2020-11-30 | 2021-03-12 | 武汉大学 | 一种基于日志结构合并树的键值存储的数据快速读取方法 |
CN113051268A (zh) * | 2021-03-19 | 2021-06-29 | 中国工商银行股份有限公司 | 数据查询方法、数据查询装置、电子设备及存储介质 |
CN113157689A (zh) * | 2020-01-22 | 2021-07-23 | 腾讯科技(深圳)有限公司 | 数据索引方法、装置及电子设备 |
CN113553476A (zh) * | 2021-07-27 | 2021-10-26 | 南京邮电大学 | 一种利用哈希减少写停顿的键值存储方法 |
CN113626431A (zh) * | 2021-07-28 | 2021-11-09 | 浪潮云信息技术股份公司 | 一种基于lsm树的延迟垃圾回收的键值分离存储方法及系统 |
-
2021
- 2021-12-20 CN CN202111557955.3A patent/CN113961514B/zh active Active
Patent Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9537972B1 (en) * | 2014-02-20 | 2017-01-03 | Fireeye, Inc. | Efficient access to sparse packets in large repositories of stored network traffic |
CN105608224A (zh) * | 2016-01-13 | 2016-05-25 | 广西师范大学 | 一种提高海量数据查询性能的正交多哈希映射索引方法 |
CN105787093A (zh) * | 2016-03-17 | 2016-07-20 | 清华大学 | 一种基于LSM-Tree结构的日志文件系统的构建方法 |
US20180107402A1 (en) * | 2016-10-19 | 2018-04-19 | Acronis International Gmbh | System and method for data storage using log-structured merge trees |
CN107526550A (zh) * | 2017-09-06 | 2017-12-29 | 中国人民大学 | 一种基于日志结构合并树的两阶段合并方法 |
CN107870970A (zh) * | 2017-09-06 | 2018-04-03 | 北京理工大学 | 一种数据存储查询方法及系统 |
CN109189759A (zh) * | 2018-08-01 | 2019-01-11 | 华为技术有限公司 | Kv存储系统中的数据读取方法、数据查询方法、装置及设备 |
CN110347852A (zh) * | 2019-06-06 | 2019-10-18 | 华中科技大学 | 嵌入横向扩展键值存储系统的文件系统及文件管理方法 |
CN113157689A (zh) * | 2020-01-22 | 2021-07-23 | 腾讯科技(深圳)有限公司 | 数据索引方法、装置及电子设备 |
CN112486994A (zh) * | 2020-11-30 | 2021-03-12 | 武汉大学 | 一种基于日志结构合并树的键值存储的数据快速读取方法 |
CN113051268A (zh) * | 2021-03-19 | 2021-06-29 | 中国工商银行股份有限公司 | 数据查询方法、数据查询装置、电子设备及存储介质 |
CN113553476A (zh) * | 2021-07-27 | 2021-10-26 | 南京邮电大学 | 一种利用哈希减少写停顿的键值存储方法 |
CN113626431A (zh) * | 2021-07-28 | 2021-11-09 | 浪潮云信息技术股份公司 | 一种基于lsm树的延迟垃圾回收的键值分离存储方法及系统 |
Non-Patent Citations (5)
Title |
---|
CHEN LUO 等: "Efficient data ingestion and query processing for LSM-based storage systems", 《ACM》 * |
KAI ZHANG 等: "An Optimization of Key-Value Store Based on Segmented LSM-Tree", 《IEEE》 * |
付佳: "基于LSM树的NoSQL数据库索引研究", 《中国优秀博硕士学位论文全文数据库(硕士)信息科技辑》 * |
王海涛 等: "一种基于LSM树的键值存储系统性能优化方法", 《计算机研究与发展》 * |
郭涛: "LSM-trie存储系统性能优化研究", 《万方》 * |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2023165272A1 (zh) * | 2022-03-03 | 2023-09-07 | 蚂蚁云创数字科技(北京)有限公司 | 数据存储及查询 |
CN114416651A (zh) * | 2022-03-30 | 2022-04-29 | 支付宝(杭州)信息技术有限公司 | 数据存储方法及装置、数据查找方法及装置 |
CN114817147A (zh) * | 2022-07-01 | 2022-07-29 | 北京网藤科技有限公司 | 一种通过二级索引进行文件特征值快速检索的方法和系统 |
CN115061637A (zh) * | 2022-07-12 | 2022-09-16 | 平安科技(深圳)有限公司 | 磁盘数据索引方法、装置、计算机设备及存储介质 |
CN115145954A (zh) * | 2022-09-01 | 2022-10-04 | 北京奥星贝斯科技有限公司 | 一种数据查询方法、数据存储方法及装置 |
CN115576899A (zh) * | 2022-12-09 | 2023-01-06 | 深圳市木浪云科技有限公司 | 构建索引的方法和装置以及文件查找方法和装置 |
CN117785890A (zh) * | 2024-02-27 | 2024-03-29 | 支付宝(杭州)信息技术有限公司 | 一种基于lsm树的数据遍历查询方法及相关设备 |
Also Published As
Publication number | Publication date |
---|---|
CN113961514B (zh) | 2022-03-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113961514B (zh) | 数据查询方法及装置 | |
US9805079B2 (en) | Executing constant time relational queries against structured and semi-structured data | |
US11169978B2 (en) | Distributed pipeline optimization for data preparation | |
US11461304B2 (en) | Signature-based cache optimization for data preparation | |
US20160117354A1 (en) | Method and system for dynamically partitioning very large database indices on write-once tables | |
US20100106713A1 (en) | Method for performing efficient similarity search | |
EP2834943A1 (en) | Cryptographic hash database | |
CN104424219B (zh) | 一种数据文件的管理方法及装置 | |
KR20090048624A (ko) | 데이터 구조를 가지는 하나 이상의 장치 판독가능 매체, 및장치 실행가능 명령어를 구비한 하나 이상의 장치 판독가능 매체 | |
CN107153707A (zh) | 一种针对非易失内存的哈希表构建方法及系统 | |
US10642815B2 (en) | Step editor for data preparation | |
CN116450656B (zh) | 数据处理方法、装置、设备及存储介质 | |
CN113535670B (zh) | 一种虚拟化资源镜像存储系统及其实现方法 | |
EP3362808B1 (en) | Cache optimization for data preparation | |
WO2021016050A1 (en) | Multi-record index structure for key-value stores | |
CN113392040B (zh) | 一种地址映射方法、装置、设备 | |
US20200019539A1 (en) | Efficient and light-weight indexing for massive blob/objects | |
CN116382588A (zh) | 一种基于学习索引的LSM-Tree存储引擎读放大问题优化方法 | |
CN115145954A (zh) | 一种数据查询方法、数据存储方法及装置 | |
US20210056090A1 (en) | Cache optimization for data preparation | |
JP2015162042A (ja) | インデックス管理装置 | |
CN117131012B (zh) | 一种可持久化和可扩展的轻量级多版本有序键值存储系统 | |
US20220335030A1 (en) | Cache optimization for data preparation | |
CN117725096B (zh) | 关系型数据库的数据存储和查询方法、装置、设备及介质 | |
CN111949439B (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 |