CN104715039B - 基于硬盘和内存的列式存储和查询方法及设备 - Google Patents

基于硬盘和内存的列式存储和查询方法及设备 Download PDF

Info

Publication number
CN104715039B
CN104715039B CN201510128015.0A CN201510128015A CN104715039B CN 104715039 B CN104715039 B CN 104715039B CN 201510128015 A CN201510128015 A CN 201510128015A CN 104715039 B CN104715039 B CN 104715039B
Authority
CN
China
Prior art keywords
data
column
index
hard disk
row
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
CN201510128015.0A
Other languages
English (en)
Other versions
CN104715039A (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.)
Transwarp Technology Shanghai Co Ltd
Original Assignee
Star Link Information Technology (shanghai) 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 Star Link Information Technology (shanghai) Co Ltd filed Critical Star Link Information Technology (shanghai) Co Ltd
Priority to CN201510128015.0A priority Critical patent/CN104715039B/zh
Publication of CN104715039A publication Critical patent/CN104715039A/zh
Application granted granted Critical
Publication of CN104715039B publication Critical patent/CN104715039B/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/245Query processing
    • G06F16/2453Query optimisation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/1737Details of further file system functions for reducing power consumption or coping with limited storage space, e.g. in mobile devices
    • 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/22Indexing; Data structures therefor; Storage structures
    • G06F16/221Column-oriented storage; Management thereof

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)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请提供一种基于硬盘和内存的列式存储和查询方法及设备,通过创建数据源对应的数据表的元信息,在内存中对数据源创建数据表的结构,根据所述元信息把当前的数据行生成为一个列式数据块并存储到硬盘,能够更加有效地使用内存,实现后续在硬盘上查询数据的性能达到与在内存上查询数据相近的性能,能够进一步支持后续以高速的查询效率为基础的强大的数据分析能力。进一步的,所述列为索引列时,通过对每个索引列建立一个倒排索引,并采用RadixTree结构将索引列存储到固态硬盘的对应位置的文件中,能够提高后续数据查询的效率。

Description

基于硬盘和内存的列式存储和查询方法及设备
技术领域
本申请涉及通信及计算机领域,尤其涉及一种基于硬盘和内存的列式存储和查询方法及设备。
背景技术
随着传统企业业务的快速发展,大数据的处理需求成为了所有行业不可避免的问题。传统数据库是行式存储,会将一个个完整的数据行存储在文件系统中,行存储适合查询时需要用到大部分数据列的场景,例如OLTP(On-Line Transaction Processing,联机事务处理系统)查询。但是对于OLAP(On-Line Analytical Processing,联机分析处理),用户只需要查询少数几个数据列,利用行式存储会加载很多无用的数据列,导致性能下降。为了解决这个问题,列式数据库由此诞生,列式存储是将同一个数据列存放在一起,在查询时只需要读取相应的数据列,因此列式存储能够大大提高OLAP的查询效率。
近年来,为了能高效地处理海量数据,把数据放在内存做快速地迭代处理成了一个非常重要的技术手段,因此Spark等内存框架计算逐渐占据了大数据处理市场。但是在现实生活中,生产系统的数据量往往达到上TB或者PB级别,数据不能完全存放在内存中。随着硬件技术的发展,硬盘如SSD(固态硬盘)的读写性能不断提升,用硬盘替代内存作为数据缓存成了一种趋势,然而现阶段硬盘的读写还不能和内存相比,因此设计针对硬盘的存储,尤其是设计高效的列式存储是一个很有意义和挑战的问题。
发明内容
本申请的目的是提供一种基于硬盘和内存的列式存储和查询方法及设备,能够更加有效地使用内存,实现后续在硬盘上查询数据的性能达到与在内存上查询数据相近的性能。
有鉴于此,本申请提供一种基于硬盘和内存的列式存储方法,包括:
创建数据源对应的数据表的元信息,元信息包含每个数据表所包含的所有文件在硬盘上的所在位置信息;
在硬盘中创建数据表的结构,包括文件的结构和组成所述文件的列式数据块的结构,所述列式数据块的结构包括列和对于应于每列的过滤器;
每当内存中数据源的数据的行数等于一个列式数据块的大小最大范围时,根据所述元信息把当前的数据行生成为一个列式数据块并存储到硬盘的对应位置的文件中,更新对应数据表的元信息。
进一步的,每个列式数据块的所述大小最大范围为最多包含不超过Short类型所表示的数据行数。
进一步的,当所述列包括非索引列时,根据所述元信息把当前的数据行生成为一个列式数据块并存储到硬盘的对应位置的文件中包括:
采用编码压缩的方式将非索引列存储到硬盘的对应位置的文件中。
进一步的,所述编码压缩的方式包括字典编码。
进一步的,所述编码压缩的方式还包括Run-Length编码或Delta编码。
进一步的,当所述列还包括索引列时,把当前的数据行生成为一个列式数据块并存储到硬盘的对应的文件中包括:
对每个索引列建立一个倒排索引,并采用RadixTree结构将索引列存储到硬盘的对应位置的文件中。
进一步的,所述过滤器包括Min-MaxFilter。
进一步的,所述过滤器还包括BloomFilter。
进一步的,创建数据源对应的数据表的元信息中,所述元信息的创建于Zookeeper中。
根据本申请的另一面还提供一种基于硬盘和内存的列式查询方法,用于对采用上述存储方法存储的数据进行查询,包括:
根据数据源对应的数据表的元信息获取该数据表的所有文件在硬盘上所在的位置;
根据查询条件生成条件表达式,利用过滤器对固态硬盘上的所述位置的数据表中的每个文件的每个列式数据块进行过滤,得到符合条件表达式的列式数据块并加载到内存中。
进一步的,当列式数据块的列包括非索引列,且非索引列采用编码压缩的方式存储到固态硬盘的对应的文件中时,得到符合条件表达式的列式数据块并加载到内存中之后,还包括:
对加载到内存中的列式数据块中的非索引列通过反编码的方式进行解压;
根据所述条件表达式对解压的非索引列进行扫描,从而得到查询结果。
进一步的,当列式数据块的列包括索引列,且每个索引列建立一个倒排索引,并采用RadixTree结构存储在固态硬盘的对应的文件中时,得到符合条件表达式的列式数据块并加载到内存中之后,还包括:
根据查询条件对加载到内存中的列式数据块中的索引列进行二分查找得到对应的查询值;
根据查询值对应的倒排索引生成Bitmap索引,根据所述Bitmap索引得到查询值所在的所有行。
进一步的,当所述元信息创建于Zookeeper中时,根据数据表的元信息获取该数据表的所有文件在硬盘上所在的位置中,所述数据表的元信息从Zookeeper中获取。
根据本申请的另一面还提供一种基于硬盘和内存的列式存储设备,包括:
第一一装置,用于创建数据源对应的数据表的元信息,元信息包含每个数据表所包含的所有文件在硬盘上的所在位置信息;
第一二装置,用于在硬盘中创建数据表的结构,包括文件的结构和组成所述文件的列式数据块的结构,所述列式数据块的结构包括列和对于应于每列的过滤器;
第一三装置,用于每当内存中数据源的数据的行数等于一个列式数据块的大小最大范围时,根据所述元信息把当前的数据行生成为一个列式数据块并存储到硬盘的对应位置的文件中,更新对应数据表的元信息。
进一步的,每个列式数据块的所述大小最大范围为最多包含不超过Short类型所表示的数据行数。
进一步的,所述第一三装置,用于当所述列包括非索引列时,采用编码压缩的方式将非索引列存储到硬盘的对应位置的文件中。
进一步的,所述编码压缩的方式包括字典编码。
进一步的,所述编码压缩的方式还包括Run-Length编码或Delta编码。
进一步的,所述第一三装置,用于当所述列还包括索引列时,对每个索引列建立一个倒排索引,并采用RadixTree结构将索引列存储到硬盘的对应位置的文件中。
进一步的,所述过滤器包括Min-MaxFilter。
进一步的,所述过滤器还包括BloomFilter。
进一步的,所述第一一装置,用于将所述元信息的创建于Zookeeper中。
根据本申请的另一面还提供一种基于硬盘和内存的列式查询设备,用于对采用上述相信设备存储的数据进行查询,其中,包括:
第二一装置,用于根据数据表的元信息获取该数据表的所有文件在硬盘上所在的位置;
第二二装置,用于根据查询条件生成条件表达式,利用过滤器对固态硬盘上的所述位置的数据表中的每个文件的每个列式数据块进行过滤,得到符合条件表达式的列式数据块并加载到内存中。
进一步的,当列式数据块的列包括非索引列,且非索引列采用编码压缩的方式存储到固态硬盘的对应的文件中时,所述设备还包括:
第二三装置,用于对加载到内存中的列式数据块中的非索引列通过反编码的方式进行解压;
第二四装置,用于根据所述条件表达式对解压的非索引列进行扫描,从而得到查询结果。
进一步的,当列式数据块的列包括索引列,且每个索引列建立一个倒排索引,并采用RadixTree结构存储在固态硬盘的对应的文件中时,所述设备还包括:
第二五装置,根据查询条件对加载到内存中的列式数据块中的索引列进行二分查找得到对应的查询值;
第二六装置,根据查询值对应的倒排索引生成Bitmap索引,根据所述Bitmap索引得到查询值所在的所有行。
进一步的,当所述元信息创建于Zookeeper中时,所述第二一装置用于从Zookeeper中获取所述数据表的元信息。
与现有技术相比,本申请通过创建数据源对应的数据表的元信息,在内存中对数据源创建数据表的结构,根据所述元信息把当前的数据行生成为一个列式数据块并存储到硬盘,能够更加有效地使用内存,实现后续在硬盘上查询数据的性能达到与在内存上查询数据相近的性能,能够进一步支持后续以高速的查询效率为基础的强大的数据分析能力。
进一步的,通过将每个列式数据块的大小最大范围设定为最多包含不超过Short类型所表示的数据行数,能够既有利于数据压缩的同时,又有利于Block过滤。
进一步的,所述列为非索引列时,通过编码压缩的方式将非索引列存储到硬盘的对应位置的文件中,从而节省硬盘上的数据存储空间。另外,通过字典编码的压缩方式不仅能高效地对数据压缩,还能保证高效地插入固态硬盘的效率,另外,通过Run-Length编码或Delta编码的压缩方式,能够保证好的压缩率的条件下,能极大地节省内存消耗,且不会消耗太多CPU资源用于进行解压,保证了系统的执行效率。
进一步的,所述列为索引列时,通过对每个索引列建立一个倒排索引,并采用RadixTree结构将索引列存储到固态硬盘的对应位置的文件中,能够提高后续数据查询的效率,其中,索引列采用RadixTree结构进行组织存储,RadixTree不仅能对具有公共前缀的字符串进行压缩,而且可以对输入的字符串排序,从而可以利用二分查找快速查询所需数据的位置,能够快速响应数据的查询任务,另外,对每个索引列建立一个倒排索引,后续查询时可根据该倒排索引利用查询条件生成Bitmap索引,根据Bitmap索引可以快速定位索引满足查询条件某列中的所有行。
进一步的,通过Min-MaxFilter的过滤器可以减少后续查询数据时的数据访问总量,查询时利用Min-MaxFilter来过滤无用的列式数据块,提高任务查询效率。另外,通过BloomFilter的过滤器在Min-MaxFilter过滤得到的数据的基础上进一步进行过滤,减少查询数据时的数据访问总量,查询时利用Min-MaxFilter和BloomFilter的结合来过滤无用的列式数据块,进一步提高任务查询效率。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本申请的其它特征、目的和优点将会变得更明显:
图1示出根据本申请一个方面的一种基于硬盘和内存的列式存储方法流程图;
图2示出本申请一实施例的文件的存储格式示意图;
图3示出本申请一实施例的列式数据块的存储格式示意图;
图4(a)示出本申请一实施例的原数据示意图;
图4(b)示出本申请一实施例的对应于图4(a)的Min-MaxFilter示意图;
图4(c)示出本申请一实施例的对应于图4(a)的BloomFilter示意图;
图5示出本申请一实施例的包含Zookeeper的组件交互逻辑架构图;
图6示出根据本申请另一个方面的一种基于硬盘和内存的列式查询方法流程图;
图7示出本申请一优选的实施例的基于硬盘和内存的列式查询方法流程图;
图8示出本申请另一优选的实施例的基于硬盘和内存的列式查询方法流程图;
图9示出本申请一实施例的Bitmap索引示意图;
图10示出根据本申请另一个方面的一种基于硬盘和内存的列式存储设备的模块图;
图11示出根据本申请另一个方面的一种基于硬盘和内存的列式查询设备的模块图;
图12示出本申请一优选的实施例的基于硬盘和内存的列式查询设备的模块图;
图13示出本申请另一优选的实施例的基于硬盘和内存的列式查询设备的模块图。
附图中相同或相似的附图标记代表相同或相似的部件。
具体实施方式
在本申请一个典型的配置中,终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
如图1所示,本申请一实施例提供一种基于硬盘和内存的列式存储方法,包括:
步骤S11,创建数据源对应的数据表的元信息,元信息包含每个数据源对应的数据表所包含的所有文件(FileSegment)在硬盘上的所在位置信息;在此,所述硬盘可以是固态硬盘(SSD),在内存不失电的情况下,可将每个数据表的元信息存储于内存中;
步骤S12,在内存中对数据源创建数据表的结构,包括文件的结构和组成所述文件的列式数据块的结构,所述列式数据块的结构包括列和对于应于每列的过滤器(Filter);在此,本实施例可通过一列式存储平台实现,所述数据表的来源即数据源包括数据交互源和/或流数据源等,列式存储平台存储数据时将数据存储至硬盘如SSD的对应数据表中的若干个文件(FileSegment)中,每个文件划又包含若干个列式数据块(Block)列式数据块,例如,如图2所示的数据表中包含一个FileSegment,该FileSegment包含3个Block,每个Block包含5列分别为col1~col5和若干行,另外,列式存储平台在每个列式数据块的头部加上过滤器(Filter),后续可通过过滤器减少查询数据时的数据访问总量,查询时利用过滤器来过滤无用的列式数据块,提高任务查询效率;
步骤S13,每当内存中数据源的数据行数等于一个列式数据块(Block)的大小最大范围时,根据所述元信息把当前的数据行生成为一个列式数据块并存储到硬盘如固态硬盘(SSD)的对应位置的文件中,更新数据源对应的数据表的元信息。在此,在内存中的数据可以都是字节数组,当输入的数据行数等于Block的最大范围,列式存储平台把当前的数据行数作为一个Block输出到SSD中对应的FileSegment中的末尾后删除内存中已输出到SSD中的数据行数,具体的,如果当前的FileSegment超过FileSegment的大小最大范围,则新建一个FileSegment作为该Block对应的FileSegment,每次新建一个FileSegment存储新的Block时,需要更新对应数据源的元信息,以便后续查询时根据元数据快速定位于相应的文件。本实施中列式存储平台可将数据序列化成字节数组存储到SSD上,后续数据查询时从SSD上读取将字节数组反序列化成数据进行处理。本实施例能够更加有效地使用内存,实现后续在硬盘上查询数据的性能达到与在内存上查询数据相近的性能,能够进一步支持后续以高速的查询效率为基础的强大的数据分析能力。
本申请的一种基于硬盘和内存的列式存储方法的一优选的实施中,每个列式数据块(Block)的所述大小最大范围为最多包含不超过Short类型所表示的数据行数。具体的,例如,每个列式数据块最多包含数据为65000条,每个文件的数据不超过512M,在此,每个Block越大,越有利于数据压缩,但不利于过滤Block;每个Block越小,越利于Block过滤,但不利于数据压缩,因此,这里每个列式数据块(Block)的大小设定为最多包含不超过Short类型所表示的数据行数,能够既有利于数据压缩的同时,又有利于Block过滤。本领域技术人员应能理解上述列式数据块的大小的描述仅为举例,其他现有的或今后可能出现的列式数据块的大小的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储方法的一优选的实施中,步骤S12中的所述列包括非索引列,
对应的,步骤S13中的根据所述元信息把当前的数据行生成为一个列式数据块并存储到硬盘的对应位置的文件中列式数据块包括:
采用编码压缩的方式将非索引列存储到硬盘的对应位置的文件中,从而节省硬盘上的数据存储空间。本领域技术人员应能理解上述非索引列的描述仅为举例,其他现有的或今后可能出现的非索引列的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储方法的一优选的实施中,所述编码压缩的方式包括字典编码(Dictionary Encoding)。在此,对于不需要构建索引的数据列采用字典编码的方式,字典编码不仅能高效地对数据压缩,还能保证高效地插入固态硬盘的效率。本领域技术人员应能理解上述编码的描述仅为举例,其他现有的或今后可能出现的编码的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储方法的一更优选的实施中,所述编码压缩的方式还包括Run-Length编码或Delta编码,从而对字典编码后的每个列式数据块进行进一步压缩,在此,针对不同的数据类型可采用Run-Length编码或Delta编码的压缩方案,Run-Length编码或Delta编码都能够保证好的压缩率的条件下,能极大地节省内存消耗,且不会消耗太多CPU资源用于进行解压,保证了系统的执行效率。本领域技术人员应能理解上述编码的描述仅为举例,其他现有的或今后可能出现的编码的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储方法的一优选的实施中,步骤S12中的所述列还包括索引列时,
对应的步骤S13中的根据所述元信息把当前的数据行生成为一个列式数据块并存储到硬盘的对应位置的文件中列式数据块包括:
对每个索引列建立一个倒排索引,并采用RadixTree结构将索引列存储到固态硬盘的对应位置的文件中。在此,列式存储平台根据表结构对数据源的数据构建索引列和非索引列,其中,为了提高后续数据查询的效率,列式存储平台可根据查询条件的谓词属性对每个列式数据块的对应列构建数据索引即构建索引列,索引列采用RadixTree结构进行组织存储,RadixTree不仅能对具有公共前缀的字符串进行压缩,而且可以对输入的字符串排序,从而可以利用二分查找快速查询所需数据的位置,能够快速响应数据的查询任务,另外,列式存储平台对每个索引列建立一个倒排索引,每个倒排索引可以是一个short类型的数据列表,后续查询时可根据该倒排索引利用查询条件生成Bitmap索引,根据Bitmap索引可以快速定位索引满足查询条件某列中的所有行;此外,对非索引列可采用字典编码的方式进行组织存储。例如,本申请的向硬盘插入列式数据的实际应用中,需要指定列式数据块的每列是否需要构建索引,默认是按照无索引的字典编码进行构建。如图3所示,每个Block的头部(head)含有每个列的MinMaxFilter和BloomFilter,每个Block的主体(body)含有字典(Dic)和对应的值如(a,b,c),字典用Byte数组存储,该列的每个值用short存储。对于需要构建索引的列,额外引入一个倒排索引用来优化查询速度,图3中,第一例为索引列,倒排索引为a=>(1,4),b=>(3,5),c=>(2),第二至第四例为非索引列。对于倒排索引采用Delta编码进行压缩,对于不同类型的字典分别采用RunLength编码或者Delta编码进行压缩。本领域技术人员应能理解上述索引列的描述仅为举例,其他现有的或今后可能出现的索引列的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储方法的一优选的实施中,步骤S12中的所述过滤器包括Min-MaxFilter。在此,Min-MaxFilter用于记录每个Block的最大值和最小值,如图4(a)所示,原数据是1,4,5,7,8,10,如图4(b)所示,Min-MaxFilter是1和10,通过1和10可以快速过滤掉小于1或者大于10的数据,通过Min-MaxFilter可以减少后续查询数据时的数据访问总量,查询时利用Min-MaxFilter来过滤无用的列式数据块,提高任务查询效率。本领域技术人员应能理解上述过滤器的描述仅为举例,其他现有的或今后可能出现的过滤器的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储方法的一更优选的实施中,步骤S12中的所述过滤器还包括BloomFilter。在此,BloomFilter是一种非常省空间的二进制向量数据结构,用来检测一个数据是否在一个数据文件中,如图4(c)所示,BloomFilter通过检查该位置是否为1来检测该数据是否在数据文件中从而用来过滤数据,图4(a)中没有2,3,6和9共四个数据,对应的,图4(c)中对应的四个位置为0,其它位置均为1,这里后续可以通过BloomFilter在Min-MaxFilter过滤得到的数据的基础上进一步进行过滤,减少查询数据时的数据访问总量,查询时利用Min-MaxFilter和BloomFilter的结合来过滤无用的列式数据块,进一步提高任务查询效率。例如,一具体应用中,列式存储平台实现使用SQL谓词下推技术,将查询的谓词条件与数据表中的列式数据块头部的Min-MaxFilter和BloomFilter做比较,不满足谓词条件条件的列式数据块不需要加载读取到内存中,由于每个列式数据块最多包含65000条数据,所以利用列式数据块头部的Min-MaxFilter和BloomFilter可以过滤很多无用的列式数据块,从而优化查询效率。本领域技术人员应能理解上述过滤器的描述仅为举例,其他现有的或今后可能出现的过滤器的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储方法的一优选的实施中,步骤S11的创建数据源对应的数据表的元信息中,所述元信息的(Meta信息)创建于Zookeeper中,相应的,步骤S13中,更新对应数据表的元信息中是对Zookeeper中的元信息进行更新,如果将元信息记录于内存中,内存失电后元信息会丢失,而将元信息存储于Zookeeper可以防止无信息的丢失,另外,Zookeeper还可以在对硬盘插入数据时对硬盘中的插入位置进行加锁,实现向硬盘中动态追加数据和各数据源的数据共享和交互。在此,ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、名字服务、分布式同步、组服务等。具体的,如图5所示,列式存储平台(Holodesk)将数据表的元信息(Meta信息)放在Zookeeper中,列式存储平台通过Zookeeper获取各数据源(Inceptor、Streaming和Hyperbase)的对应数据表的元信息(Meta),即获得数据表在SSD的存取位置,以便对SSD上的该数据表进行数据存储和查询。利用Zookeeper管理数据表的元信息,可实现与流数据源进行了深入地整合,支持将流数据实时地插入交互数据源,满足后续实时分析的业务的需求,进而满足ODS(Operational Data Store,是数据仓库体系结构中的一个可选部分)市场的应用需求。本领域技术人员应能理解上述元信息的描述仅为举例,其他现有的或今后可能出现的元信息的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
如图6所示,本申请还提供一种对采用上述基于硬盘和内存的列式存储方法存储的数据进行列式查询的方法,包括:
步骤S21,根据数据源对应的数据表的元信息获取对应数据表的所有文件在固态硬盘上所在的位置;
步骤S22,根据查询条件生成条件表达式,利用过滤器对固态硬盘上的所述位置的数据表中的每个文件的每个列式数据块进行过滤,得到符合条件表达式的列式数据块并加载到内存中,从而初步得到查询数据的结果,后续可基于此得到更为精确的查询数据的结果;在此,本实施也可由所述列式存储平台来实现,例如,查询条件是col1>=b&&col2=d,则可以生成两个条件表达式,col1的表达式为(b,NULL),col2的表达式为(d,d),然后列式存储平台从硬盘上读取每个文件(FileSegment)的列式数据块(Block),利用每个Block的过滤器(Filter)并根据条件表达式判断该Block是否需要加载到内存中进行处理,如果符合条件表达式,则列式存储平台加载该Block到内存中,否则直接跳过该Block继续判断下一Block。较佳的,列式存储平台可采取了批量读取技术,即一次读一个的列的多个值,从而提高了列式存储平台在硬盘上的吞吐量。
本申请的基于硬盘和内存的列式查询方法一优选的实施例中,当列式数据块的列包括非索引列,且非索引列采用编码压缩的方式存储到固态硬盘的对应的文件中时,
如图7所示,步骤S22之后,还包括:
步骤S23,对加载到内存中的列式数据块中的非索引列通过反编码的方式进行解压;
步骤S24,根据所述条件表达式对解压的非索引列进行扫描,从而得到更精确的查询结果。本领域技术人员应能理解上述非索引列查询的描述仅为举例,其他现有的或今后可能出现的非索引列查询的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的基于硬盘和内存的列式查询方法一优选的实施例中,当列式数据块的列包括索引列,且每个索引列建立一个倒排索引,并采用RadixTree结构存储在固态硬盘的对应的文件中时,
如图8所示,步骤S22之后,还包括:
步骤S25,根据查询条件对加载到内存中的列式数据块中的索引列进行二分查找得到对应的查询值;在此,由于索引列采用RadixTree结构进行组织存储,RadixTree不仅能对具有公共前缀的字符串进行压缩,而且可以对输入的字符串排序,从而此刻查询时可利用二分查找快速查询所需数据的位置,使用二分查找能高效地找到查询值即相应列式数据块的单值或者列式数据块的两个值的区间范围,从而满足查询需求;
步骤S26,根据查询值对应的倒排索引生成Bitmap索引,根据所述Bitmap索引得到查询值所在的所有行。在此,由于列式存储平台对每个索引列建立一个倒排索引,此刻查询时可根据该倒排索引利用查询条件生成Bitmap索引,BitMap索引可采用Concise压缩算法,BitMap可以进行高效的OR和AND操作,利用这种特性可以快速地对条件表达式求值,根据Bitmap索引可以快速定位索引满足查询条件某列中的所有行。例如,如图9所示,查询条件为col1>=b&&col2=d,列式存储平台为col1和col2分别生成一个Bitmap索引,col1的Bitmap索引为(0,1,1,0,1),col2的Bitmap索引为(1,0,0,0,1),然后利用and操作把两个Bitmap生成一个新的Bitmap索引(0,0,0,0,1),新生成的Bitmap表示了该Block上满足该查询条件所有行。更详细的,如图3所示,图3中第一列为索引列,输入字符串按照字母序排序(a,b,c),图3中第二、三和四列为非索引列,当按照第一列查询等于b(查询值)的所有行数时,首先通过二分查找找到b(查询值),然后通过倒排索引得知第三行和第五行符合查询条件。本领域技术人员应能理解上述索引列查询的描述仅为举例,其他现有的或今后可能出现的索引列查询的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的基于硬盘和内存的列式查询方法一优选的实施例中,当所述元信息创建于Zookeeper中时,步骤S21的根据数据表的元信息获取该数据表的所有文件在硬盘上所在的位置中,所述数据表的元信息从Zookeeper中获取,从而实现各数据源的数据共享和交互。本领域技术人员应能理解上述元信息获取的描述仅为举例,其他现有的或今后可能出现的元信息获取的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
如图10所示,本申请还提供一种基于硬盘和内存的列式存储设备100,包括:
第一一装置11,用于创建数据源对应的数据表的元信息,元信息包含每个数据表所包含的所有文件(FileSegment)在硬盘上的所在位置信息;
第一二装置12,用于在硬盘中创建数据表的结构,包括文件的结构和组成所述文件的列式数据块的结构,所述列式数据块的结构包括列和对于应于每列的过滤器(Filter);在此,所述数据表的来源即数据源包括数据交互源和/或流数据源等,列式存储平台存储数据时将数据存储至硬盘如SSD的对应数据表中的若干个文件(FileSegment)中,每个文件划又包含若干个列式数据块(Block)列式数据块,例如,如图2所示的数据表中包含一个FileSegment,该FileSegment包含3个Block,每个Block包含5列分别为col1~col5和若干行,另外,列式存储平台在每个列式数据块的头部加上过滤器(Filter),后续可通过过滤器减少查询数据时的数据访问总量,查询时利用过滤器来过滤无用的列式数据块,提高任务查询效率;
第一三装置13,用于每当内存中数据源的数据的行数等于一个列式数据块(Block)的大小最大范围时,根据所述元信息把当前的数据行生成为一个列式数据块并存储到硬盘的对应位置的文件中,更新对应数据表的元信息。在此,在内存中的数据可以都是字节数组,当输入的数据行数等于Block的最大范围,第一三装置把当前的数据行数作为一个Block输出到SSD中对应的FileSegment中的末尾后删除内存中已输出到SSD中的数据行数,具体的,如果当前的FileSegment超过FileSegment的大小最大范围,则新建一个FileSegment作为该Block对应的FileSegment,每次新建一个FileSegment存储新的Block时,需要更新对应数据源的元信息,以便后续查询时根据元数据快速定位于相应的文件。本实施中可将数据序列化成字节数组存储到SSD上,后续数据查询时从SSD上读取将字节数组反序列化成数据进行处理。本实施例能够更加有效地使用内存,实现后续在SSD上查询数据的性能达到与在内存上查询数据相近的性能,能够进一步支持后续以高速的查询效率为基础的强大的数据分析能力。
本申请的一种基于硬盘和内存的列式存储设备的一优选的实施中,每个列式数据块(Block)的所述大小最大范围为最多包含不超过Short类型所表示的数据行数。具体的,例如,每个列式数据块最多包含数据为65000条,每个文件的数据不超过512M,在此,每个Block越大,越有利于数据压缩,但不利于过滤Block;每个Block越小,越利于Block过滤,但不利于数据压缩,因此,这里每个列式数据块(Block)的大小设定为最多包含不超过Short类型所表示的数据行数,能够既有利于数据压缩的同时,又有利于Block过滤。本领域技术人员应能理解上述列式数据块的大小的描述仅为举例,其他现有的或今后可能出现的列式数据块的大小的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储设备的一优选的实施中,所述第一三装置13,用于当所述列包括非索引列时,采用编码压缩的方式将非索引列存储到硬盘的对应位置的文件中,从而节省硬盘上的数据存储空间。本领域技术人员应能理解上述非索引列的描述仅为举例,其他现有的或今后可能出现的非索引列的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储设备的一优选的实施中,所述编码压缩的方式包括字典编码。在此,对于不需要构建索引的数据列采用字典编码的方式,字典编码不仅能高效地对数据压缩,还能保证高效地插入固态硬盘的效率。本领域技术人员应能理解上述编码的描述仅为举例,其他现有的或今后可能出现的编码的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储设备的一更优选的实施中,所述编码压缩的方式还包括Run-Length编码或Delta编码,从而对字典编码后的每个列式数据块进行进一步压缩,在此,针对不同的数据类型可采用Run-Length编码或Delta编码的压缩方案,Run-Length编码或Delta编码都能够保证好的压缩率的条件下,能极大地节省内存消耗,且不会消耗太多CPU资源用于进行解压,保证了系统的执行效率。本领域技术人员应能理解上述编码的描述仅为举例,其他现有的或今后可能出现的编码的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储设备的一优选的实施中,所述第一三装置13,用于当所述列还包括索引列时,对每个索引列建立一个倒排索引,并采用RadixTree结构将索引列存储到硬盘的对应位置的文件中。在此,第一二装置12根据表结构对数据源的数据构建索引列和非索引列,其中,为了提高后续数据查询的效率,第一二装置12可根据查询条件的谓词属性对每个列式数据块的对应列构建数据索引即构建索引列,第一三装置13对索引列采用RadixTree结构进行组织存储,RadixTree不仅能对具有公共前缀的字符串进行压缩,而且可以对输入的字符串排序,从而可以利用二分查找快速查询所需数据的位置,能够快速响应数据的查询任务,另外,第一三装置13对每个索引列建立一个倒排索引,每个倒排索引可以是一个short类型的数据列表,后续查询时可根据该倒排索引利用查询条件生成Bitmap索引,根据Bitmap索引可以快速定位索引满足查询条件某列中的所有行;此外,对非索引列可采用字典编码的方式进行组织存储。例如,本申请的向硬盘插入列式数据的实际应用中,需要指定列式数据块的每列是否需要构建索引,默认是按照无索引的字典编码进行构建。如图3所示,每个Block的头部(head)含有每个列的MinMaxFilter和BloomFilter,每个Block的主体(body)含有字典(Dic)和对应的值如(a,b,c),字典用Byte数组存储,该列的每个值用short存储。对于需要构建索引的列,额外引入一个倒排索引用来优化查询速度,图3中,第一例为索引列,倒排索引为a=>(1,4),b=>(3,5),c=>(2),第二至第四例为非索引列。对于倒排索引采用Delta编码进行压缩,对于不同类型的字典分别采用RunLength编码或者Delta编码进行压缩。本领域技术人员应能理解上述索引列的描述仅为举例,其他现有的或今后可能出现的索引列的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储设备的一优选的实施中,所述过滤器包括Min-MaxFilter。在此,Min-MaxFilter用于记录每个Block的最大值和最小值,如图4(a)所示,原数据是1,4,5,7,8,10,如图4(b)所示,Min-MaxFilter是1和10,通过1和10可以快速过滤掉小于1或者大于10的数据,通过Min-MaxFilter可以减少后续查询数据时的数据访问总量,查询时利用Min-MaxFilter来过滤无用的列式数据块,提高任务查询效率。本领域技术人员应能理解上述过滤器的描述仅为举例,其他现有的或今后可能出现的过滤器的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储设备的一优选的实施中,所述过滤器还包括BloomFilter。在此,BloomFilter是一种非常省空间的二进制向量数据结构,用来检测一个数据是否在一个数据文件中,如图4(c)所示,BloomFilter通过检查该位置是否为1来检测该数据是否在数据文件中从而用来过滤数据,图4(a)中没有2,3,6和9共四个数据,对应的,图4(c)中对应的四个位置为0,其它位置均为1,这里后续可以通过BloomFilter在Min-MaxFilter过滤得到的数据的基础上进一步进行过滤,减少查询数据时的数据访问总量,查询时利用Min-MaxFilter和BloomFilter的结合来过滤无用的列式数据块,进一步提高任务查询效率。例如,一具体应用中,列式存储平台实现使用SQL谓词下推技术,将查询的谓词条件与数据表中的列式数据块头部的Min-MaxFilter和BloomFilter做比较,不满足谓词条件条件的列式数据块不需要加载读取到内存中,由于每个列式数据块最多包含65000条数据,所以利用列式数据块头部的Min-MaxFilter和BloomFilter可以过滤很多无用的列式数据块,从而优化查询效率。本领域技术人员应能理解上述过滤器的描述仅为举例,其他现有的或今后可能出现的过滤器的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式存储设备的一优选的实施中,第一一装置,用于将所述元信息的创建于Zookeeper中。相应的,第一三装置13更新对应数据表的元信息时是对Zookeeper中的元信息进行更新,如果将元信息记录于内存中,内存失电后元信息会丢失,而将元信息存储于Zookeeper可以防止无信息的丢失,另外,Zookeeper还可以在对硬盘插入数据时对硬盘中的插入位置进行加锁,实现向硬盘中动态追加数据和各数据源的数据共享和交互。在此,ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、名字服务、分布式同步、组服务等。具体的,如图5所示,列式存储平台(Holodesk)将数据表的元信息(Meta信息)放在Zookeeper中,列式存储平台通过Zookeeper获取各数据源(Inceptor、Streaming和Hyperbase)的对应数据表的元信息(Meta),即获得数据表在SSD的存取位置,以便对SSD上的该数据表进行数据存储和查询。利用Zookeeper管理数据表的元信息,可实现与流数据源进行了深入地整合,支持将流数据实时地插入交互数据源,满足后续实时分析的业务的需求,进而满足ODS(Operational Data Store,是数据仓库体系结构中的一个可选部分)市场的应用需求。本领域技术人员应能理解上述元信息的描述仅为举例,其他现有的或今后可能出现的元信息的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式查询设备的一优选的实施中,所述基于硬盘和内存的列式查询设备用于对采用上述基于硬盘和内存的列式查询设备所存储的数据进行查询,其中,如图11所示,所述设备200包括:
第二一装置21,用于根据数据表的元信息获取该数据表的所有文件在硬盘上所在的位置;
第二二装置22,用于根据查询条件生成条件表达式,利用过滤器对固态硬盘上的所述位置的数据表中的每个文件的每个列式数据块进行过滤,得到符合条件表达式的列式数据块并加载到内存中,从而初步得到查询数据的结果,后续可基于此得到更为精确的查询数据的结果;例如,查询条件是col1>=b&&col2=d,则可以生成两个条件表达式,col1的表达式为(b,NULL),col2的表达式为(d,d),然后第二二装置22从硬盘上读取每个文件(FileSegment)的列式数据块(Block),利用每个Block的过滤器(Filter)并根据条件表达式判断该Block是否需要加载到内存中进行处理,如果符合条件表达式,则第二二装置22加载该Block到内存中,否则直接跳过该Block继续判断下一Block。较佳的,第二二装置22可采取了批量读取技术,即一次读一个的列的多个值,从而提高了列式存储平台在硬盘上的吞吐量。
本申请的一种基于硬盘和内存的列式查询设备的一优选的实施中,当列式数据块的列包括非索引列,且非索引列采用编码压缩的方式存储到固态硬盘的对应的文件中时,如图12所示,所述设备200还包括:
第二三装置23用于对加载到内存中的列式数据块中的非索引列通过反编码的方式进行解压;
第二四装置24,用于根据所述条件表达式对解压的非索引列进行扫描,从而得到更精确的查询结果。本领域技术人员应能理解上述非索引列查询的描述仅为举例,其他现有的或今后可能出现的非索引列查询的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式查询设备的一优选的实施中,当列式数据块的列包括索引列,且每个索引列建立一个倒排索引,并采用RadixTree结构存储在固态硬盘的对应的文件中时,如图13所示,所述设备200还包括:
第二五装置25,根据查询条件对加载到内存中的列式数据块中的索引列进行二分查找得到对应的查询值;在此,由于索引列采用RadixTree结构进行组织存储,RadixTree不仅能对具有公共前缀的字符串进行压缩,而且可以对输入的字符串排序,从而此刻查询时可利用二分查找快速查询所需数据的位置,使用二分查找能高效地找到查询值即相应列式数据块的单值或者列式数据块的两个值的区间范围,从而满足查询需求;
第二六装置26,根据查询值对应的倒排索引生成Bitmap索引,根据所述Bitmap索引得到查询值所在的所有行。在此,由于列式存储平台对每个索引列建立一个倒排索引,此刻查询时可根据该倒排索引利用查询条件生成Bitmap索引,BitMap索引可采用Concise压缩算法,BitMap可以进行高效的OR和AND操作,利用这种特性可以快速地对条件表达式求值,根据Bitmap索引可以快速定位索引满足查询条件某列中的所有行。例如,如图9所示,查询条件为col1>=b&&col2=d,列式存储平台为col1和col2分别生成一个Bitmap索引,col1的Bitmap索引为(0,1,1,0,1),col2的Bitmap索引为(1,0,0,0,1),然后利用and操作把两个Bitmap生成一个新的Bitmap索引(0,0,0,0,1),新生成的Bitmap表示了该Block上满足该查询条件所有行。更详细的,如图3所示,图3中第一列为索引列,输入字符串按照字母序排序(a,b,c),图3中第二、三和四列为非索引列,当按照第一列查询等于b(查询值)的所有行数时,首先通过二分查找找到b(查询值),然后通过倒排索引得知第三行和第五行符合查询条件。本领域技术人员应能理解上述索引列查询的描述仅为举例,其他现有的或今后可能出现的索引列查询的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
本申请的一种基于硬盘和内存的列式查询设备的一优选的实施中,当所述元信息创建于Zookeeper中时,第二一装置21,用于从Zookeeper中获取所述数据表的元信息,从而实现各数据源的数据共享和交互。本领域技术人员应能理解上述元信息获取的描述仅为举例,其他现有的或今后可能出现的元信息获取的描述如可适用于本申请,也应包含在本申请保护范围以内,并在此以引用方式包含于此。
综上所述,本申请通过创建数据源对应的数据表的元信息,在内存中对数据源创建数据表的结构,根据所述元信息把当前的数据行生成为一个列式数据块并存储到硬盘,能够更加有效地使用内存,实现后续在硬盘上查询数据的性能达到与在内存上查询数据相近的性能,能够进一步支持后续以高速的查询效率为基础的强大的数据分析能力。
进一步的,通过将每个列式数据块的大小最大范围设定为最多包含不超过Short类型所表示的数据行数,能够既有利于数据压缩的同时,又有利于Block过滤。
进一步的,所述列为非索引列时,通过编码压缩的方式将非索引列存储到硬盘的对应位置的文件中,从而节省硬盘上的数据存储空间。另外,通过字典编码的压缩方式不仅能高效地对数据压缩,还能保证高效地插入固态硬盘的效率,另外,通过Run-Length编码或Delta编码的压缩方式,能够保证好的压缩率的条件下,能极大地节省内存消耗,且不会消耗太多CPU资源用于进行解压,保证了系统的执行效率。
进一步的,所述列为索引列时,通过对每个索引列建立一个倒排索引,并采用RadixTree结构将索引列存储到固态硬盘的对应位置的文件中,能够提高后续数据查询的效率,其中,索引列采用RadixTree结构进行组织存储,RadixTree不仅能对具有公共前缀的字符串进行压缩,而且可以对输入的字符串排序,从而可以利用二分查找快速查询所需数据的位置,能够快速响应数据的查询任务,另外,对每个索引列建立一个倒排索引,后续查询时可根据该倒排索引利用查询条件生成Bitmap索引,根据Bitmap索引可以快速定位索引满足查询条件某列中的所有行。
进一步的,通过Min-MaxFilter的过滤器可以减少后续查询数据时的数据访问总量,查询时利用Min-MaxFilter来过滤无用的列式数据块,提高任务查询效率。另外,通过BloomFilter的过滤器在Min-MaxFilter过滤得到的数据的基础上进一步进行过滤,减少查询数据时的数据访问总量,查询时利用Min-MaxFilter和BloomFilter的结合来过滤无用的列式数据块,进一步提高任务查询效率。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
需要注意的是,本申请可在软件和/或软件与硬件的组合体中被实施,例如,可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中,本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地,本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中,例如,RAM存储器,磁或光驱动器或软磁盘及类似设备。另外,本申请的一些步骤或功能可采用硬件来实现,例如,作为与处理器配合从而执行各个步骤或功能的电路。
另外,本申请的一部分可被应用为计算机程序产品,例如计算机程序指令,当其被计算机执行时,通过该计算机的操作,可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令,可能被存储在固定的或可移动的记录介质中,和/或通过广播或其他信号承载媒体中的数据流而被传输,和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此,根据本申请的一个实施例包括一个装置,该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器,其中,当该计算机程序指令被该处理器执行时,触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。
对于本领域技术人员而言,显然本申请不限于上述示范性实施例的细节,而且在不背离本申请的精神或基本特征的情况下,能够以其他的具体形式实现本申请。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本申请的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外,显然“包括”一词不排除其他单元或步骤,单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一,第二等词语用来表示名称,而并不表示任何特定的顺序。

Claims (14)

1.一种基于硬盘和内存的列式存储方法,其中,包括:
创建数据源对应的数据表的元信息,元信息包含每个数据表所包含的所有文件在硬盘上的所在位置信息;
在硬盘中创建数据表的结构,包括文件的结构和组成所述文件的列式数据块的结构,所述列式数据块的结构包括列和对于应于每列的过滤器,每个列式数据块的大小最大范围为最多包含不超过Short类型所表示的数据行数;
每当内存中数据源的数据的行数等于一个列式数据块的大小最大范围时,根据所述元信息把当前的数据行生成为一个列式数据块并存储到硬盘的对应位置的文件中,更新对应数据表的元信息,其中,当所述列还包括索引列时,把当前的数据行生成为一个列式数据块并存储到硬盘的对应的文件中包括:
对每个索引列建立一个倒排索引,并采用RadixTree结构将索引列存储到硬盘的对应位置的文件中;
当所述列包括非索引列时,根据所述元信息把当前的数据行生成为一个列式数据块并存储到硬盘的对应位置的文件中包括:
采用编码压缩的方式将非索引列存储到硬盘的对应位置的文件中,所述编码压缩的方式包括字典编码,及采用Run-Length编码或Delta编码对字典编码后的每个列式数据块进行进一步压缩。
2.如权利要求1所述的方法,其中,所述过滤器包括Min-MaxFilter。
3.如权利要求2所述的方法,其中,所述过滤器还包括BloomFilter。
4.如权利要求1至3任一项所述的方法,其中,创建数据源对应的数据表的元信息中,所述元信息的创建于Zookeeper中。
5.一种基于硬盘和内存的列式查询方法,用于对采用权利要求1至4任项一项所述方法存储的数据进行查询,其中,包括:
根据数据源对应的数据表的元信息获取该数据表的所有文件在硬盘上所在的位置;
根据查询条件生成条件表达式,利用过滤器对固态硬盘上的所述位置的数据表中的每个文件的每个列式数据块进行过滤,得到符合条件表达式的列式数据块并加载到内存中;
当列式数据块的列包括索引列,且每个索引列建立一个倒排索引,并采用RadixTree结构存储在固态硬盘的对应的文件中时,得到符合条件表达式的列式数据块并加载到内存中之后,还包括:
根据查询条件对加载到内存中的列式数据块中的索引列进行二分查找得到对应的查询值;
根据查询值对应的倒排索引生成Bitmap索引,根据所述Bitmap索引得到查询值所在的所有行。
6.如权利要求5所述的方法,其中,当列式数据块的列包括非索引列,且非索引列采用编码压缩的方式存储到固态硬盘的对应的文件中时,得到符合条件表达式的列式数据块并加载到内存中之后,还包括:
对加载到内存中的列式数据块中的非索引列通过反编码的方式进行解压;
根据所述条件表达式对解压的非索引列进行扫描,从而得到查询结果。
7.如权利要求5至6任一项所述的方法,当所述元信息创建于Zookeeper中时,根据数据表的元信息获取该数据表的所有文件在硬盘上所在的位置中,所述数据表的元信息从Zookeeper中获取。
8.一种基于硬盘和内存的列式存储设备,其中,包括:
第一一装置,用于创建数据源对应的数据表的元信息,元信息包含每个数据表所包含的所有文件在硬盘上的所在位置信息;
第一二装置,用于在硬盘中创建数据表的结构,包括文件的结构和组成所述文件的列式数据块的结构,所述列式数据块的结构包括列和对于应于每列的过滤器,每个列式数据块的大小最大范围为最多包含不超过Short类型所表示的数据行数;
第一三装置,用于每当内存中数据源的数据的行数等于一个列式数据块的大小最大范围时,根据所述元信息把当前的数据行生成为一个列式数据块并存储到硬盘的对应位置的文件中,更新对应数据表的元信息,其中,当所述列还包括索引列时,对每个索引列建立一个倒排索引,并采用RadixTree结构将索引列存储到硬盘的对应位置的文件中;当所述列包括非索引列时,采用编码压缩的方式将非索引列存储到硬盘的对应位置的文件中,所述编码压缩的方式包括字典编码,及采用Run-Length编码或Delta编码对字典编码后的每个列式数据块进行进一步压缩。
9.如权利要求8所述的设备,其中,所述过滤器包括Min-MaxFilter。
10.如权利要求9所述的设备,其中,所述过滤器还包括BloomFilter。
11.如权利要求8至10任一项所述的设备,其中,所述第一一装置,用于将所述元信息的创建于Zookeeper中。
12.一种基于硬盘和内存的列式查询设备,用于对采用权利要求8至11任项一项所述设备存储的数据进行查询,其中,包括:
第二一装置,用于根据数据表的元信息获取该数据表的所有文件在硬盘上所在的位置;
第二二装置,用于根据查询条件生成条件表达式,利用过滤器对固态硬盘上的所述位置的数据表中的每个文件的每个列式数据块进行过滤,得到符合条件表达式的列式数据块并加载到内存中,其中,当列式数据块的列包括索引列,且每个索引列建立一个倒排索引,并采用RadixTree结构存储在固态硬盘的对应的文件中时,根据查询条件对加载到内存中的列式数据块中的索引列进行二分查找得到对应的查询值;根据查询值对应的倒排索引生成Bitmap索引,根据所述Bitmap索引得到查询值所在的所有。
13.如权利要求12所述的设备,其中,当列式数据块的列包括非索引列,且非索引列采用编码压缩的方式存储到固态硬盘的对应的文件中时,所述设备还包括:
第二三装置,用于对加载到内存中的列式数据块中的非索引列通过反编码的方式进行解压;
第二四装置,用于根据所述条件表达式对解压的非索引列进行扫描,从而得到查询结果。
14.如权利要求12至13任一项所述的设备,当所述元信息创建于Zookeeper中时,所述第二一装置用于从Zookeeper中获取所述数据表的元信息。
CN201510128015.0A 2015-03-23 2015-03-23 基于硬盘和内存的列式存储和查询方法及设备 Active CN104715039B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510128015.0A CN104715039B (zh) 2015-03-23 2015-03-23 基于硬盘和内存的列式存储和查询方法及设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510128015.0A CN104715039B (zh) 2015-03-23 2015-03-23 基于硬盘和内存的列式存储和查询方法及设备

Publications (2)

Publication Number Publication Date
CN104715039A CN104715039A (zh) 2015-06-17
CN104715039B true CN104715039B (zh) 2018-10-19

Family

ID=53414365

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510128015.0A Active CN104715039B (zh) 2015-03-23 2015-03-23 基于硬盘和内存的列式存储和查询方法及设备

Country Status (1)

Country Link
CN (1) CN104715039B (zh)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106326305A (zh) * 2015-06-30 2017-01-11 星环信息科技(上海)有限公司 一种数据文件的存储和查询方法及设备
CN105095520B (zh) * 2015-09-23 2018-07-27 电子科技大学 面向结构化数据的分布式内存数据库索引方法
CN105426472B (zh) * 2015-11-16 2019-08-16 广州供电局有限公司 分布式计算系统及其数据处理方法
CN105468735A (zh) * 2015-11-23 2016-04-06 武汉虹旭信息技术有限责任公司 基于移动互联网海量信息的流式预处理系统及其方法
CN105302915B (zh) * 2015-12-23 2019-04-09 美林数据技术股份有限公司 基于内存计算的高性能数据处理系统
CN107562946A (zh) * 2017-09-26 2018-01-09 南京哈卢信息科技有限公司 一种大数据系统中创建索引表的方法
CN109947980A (zh) * 2017-10-30 2019-06-28 北京国双科技有限公司 一种视频收视数据的统计方法及装置
CN110019218B (zh) * 2017-12-08 2023-08-25 阿里巴巴集团控股有限公司 数据存储与查询方法及设备
CN108959587B (zh) * 2018-07-10 2021-03-02 上海达梦数据库有限公司 基于列存储的数据更新方法、装置、服务器及存储介质
CN110874358B (zh) * 2018-08-30 2023-05-05 阿里巴巴集团控股有限公司 多属性列的存储、检索方法和装置以及电子设备
CN109977122A (zh) * 2019-04-01 2019-07-05 西安电子科技大学 表格对象检索方法、装置、系统、计算机设备和存储介质
CN110704431A (zh) * 2019-09-20 2020-01-17 倪亚晖 一种海量数据的分级存储管理方法
CN111107022B (zh) * 2019-12-20 2021-08-27 深圳前海微众银行股份有限公司 数据传输优化方法、设备及可读存储介质
CN113448957A (zh) * 2020-03-24 2021-09-28 北京沃东天骏信息技术有限公司 一种数据查询方法和装置
CN111309719B (zh) * 2020-05-13 2020-08-21 深圳市赢时胜信息技术股份有限公司 一种对应HBase数据库的数据规范方法及系统
CN112434002A (zh) * 2020-12-25 2021-03-02 冯凌云 一种基于HBase与Phoenix的低成本海量结构化数据快速检索方法
CN113051274B (zh) * 2021-03-31 2023-02-07 上海天旦网络科技发展有限公司 一种海量标签存储系统及方法
CN114880322B (zh) * 2022-04-21 2023-02-28 广州经传多赢投资咨询有限公司 一种金融数据列式存储方法、系统、设备及存储介质
CN115599790B (zh) * 2022-11-10 2024-03-15 星环信息科技(上海)股份有限公司 一种数据存储系统、数据处理方法、电子设备和存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102129458A (zh) * 2011-03-09 2011-07-20 胡劲松 关系型数据库的存储方法及装置
CN102521306A (zh) * 2011-12-01 2012-06-27 苏州迈科网络安全技术股份有限公司 一种数据存储系统应用方法
CN102880615A (zh) * 2011-07-15 2013-01-16 腾讯科技(深圳)有限公司 一种数据存储方法和装置
CN103366015A (zh) * 2013-07-31 2013-10-23 东南大学 一种基于Hadoop的OLAP数据存储与查询方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9507816B2 (en) * 2011-05-24 2016-11-29 Nintendo Co., Ltd. Partitioned database model to increase the scalability of an information system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102129458A (zh) * 2011-03-09 2011-07-20 胡劲松 关系型数据库的存储方法及装置
CN102880615A (zh) * 2011-07-15 2013-01-16 腾讯科技(深圳)有限公司 一种数据存储方法和装置
CN102521306A (zh) * 2011-12-01 2012-06-27 苏州迈科网络安全技术股份有限公司 一种数据存储系统应用方法
CN103366015A (zh) * 2013-07-31 2013-10-23 东南大学 一种基于Hadoop的OLAP数据存储与查询方法

Also Published As

Publication number Publication date
CN104715039A (zh) 2015-06-17

Similar Documents

Publication Publication Date Title
CN104715039B (zh) 基于硬盘和内存的列式存储和查询方法及设备
CN103366015B (zh) 一种基于Hadoop的OLAP数据存储与查询方法
JP5466232B2 (ja) 大規模なデータストレージのための効率的な列ベースデータの符号化
CN103177062B (zh) 用于高速内存在线分析处理查询和操作的加速查询操作器
KR101806055B1 (ko) 선택도에 대해 데이터 비트를 인터리빙함으로써 관계형 데이터베이스에 대한 멀티-칼럼 인덱스의 발생
US9256665B2 (en) Creation of inverted index system, and data processing method and apparatus
US9817877B2 (en) Optimizing data processing using dynamic schemas
CN104348490B (zh) 一种基于效果优选的组合数据压缩方法
CN103020205B (zh) 一种分布式文件系统上基于硬件加速卡的压缩解压缩方法
US20150278268A1 (en) Data encoding and corresponding data structure
JP2012504824A (ja) 列ベースのデータ符号化構造の問い合わせのための効率的な大規模結合
CN105653609A (zh) 基于内存的数据处理方法及装置
CN102402586A (zh) 一种分布式数据存储方法
CN108628898A (zh) 数据入库的方法、装置和设备
CN106897280A (zh) 数据查询方法及装置
CN105302915A (zh) 基于内存计算的高性能数据处理系统
CN104346347A (zh) 数据存储方法、装置、服务器及系统
CN111209741A (zh) 表格数据字典的处理方法及装置
CN108897819A (zh) 一种数据搜索方法和装置
CN109165217A (zh) 一种时序数据的高效存储方法
CN105117403B (zh) 日志数据分片与查询方法及装置
CN108563781A (zh) 基于Hadoop的物联网大数据处理方法及系统
CN104821829B (zh) 一种哈夫曼树保存方法及系统
CN105989117B (zh) 一种半结构化数据快速联合处理的方法及系统
KR102236521B1 (ko) 데이터를 처리하기 위한 방법 및 장치

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
CP03 "change of name, title or address"
CP03 "change of name, title or address"

Address after: 200233 11-12 / F, building B, 88 Hongcao Road, Xuhui District, Shanghai

Patentee after: Star link information technology (Shanghai) Co.,Ltd.

Address before: Room 1902, 19th floor, block a, 391 Guiping Road, Xuhui District, Shanghai 200233

Patentee before: TRANSWARP TECHNOLOGY (SHANGHAI) Co.,Ltd.