CN106233632A - Ozip压缩和解压缩 - Google Patents
Ozip压缩和解压缩 Download PDFInfo
- Publication number
- CN106233632A CN106233632A CN201580020897.7A CN201580020897A CN106233632A CN 106233632 A CN106233632 A CN 106233632A CN 201580020897 A CN201580020897 A CN 201580020897A CN 106233632 A CN106233632 A CN 106233632A
- Authority
- CN
- China
- Prior art keywords
- dictionary
- entry
- labelling
- data
- size
- 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
Classifications
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/3066—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction by means of a mask or a bit-map
-
- 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/17—Details of further file system functions
- G06F16/174—Redundancy elimination performed by the file system
- G06F16/1744—Redundancy elimination performed by the file system using compression, e.g. sparse files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/04—Addressing variable-length words or parts of words
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/3084—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method
- H03M7/3088—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method employing the use of a dictionary, e.g. LZ78
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/60—General implementation details not specific to a particular type of compression
- H03M7/6005—Decoder aspects
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/60—General implementation details not specific to a particular type of compression
- H03M7/6011—Encoder aspects
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
Abstract
提供了用于数据压缩和解压缩编解码器OZIP的方法、装置和系统。OZIP利用固定大小的静态字典,该静态字典可以从待被压缩的输入数据的随机采样中生成。通过直接标记编码压缩为静态字典使编码流线化并且避免昂贵的条件分支,从而便于硬件实现和高并行度。通过将标记定义大小和静态字典大小限制为诸如字长或处理器高速缓存大小之类的硬件架构约束,可以使硬件实现快速并且成本有效。例如,可以通过使用SIMD指令处理器扩展来加速解压缩。可选的存储的元数据中的细粒度的块映射允许压缩数据被随机地快速存取,从而绕过动态字典的处理开销。因此,OZIP可以支持诸如用于OLTP系统之类的用于高度随机工作负载的低延迟随机数据存取。
Description
技术领域
本公开涉及数据压缩,并且更具体地,涉及适用于成本有效的硬件实现同时提供低延迟随机存取支持的高性能数据压缩和解压缩。
背景技术
数据压缩是管理不断增长的数据需求,从而实现存储器中的数据大小、存储占用空间(footprint)和网络带宽使用的显著降低的有效工具。然而,尤其是当压缩编解码器基于诸如ZLIP和LZO之类的基于Lempel-Ziv范式的常见压缩编解码器时,数据压缩可能增加大量的处理开销。这些编解码器倾向于为了较小的盘存储占用空间而优先考虑较高的压缩率,而不是最小化处理开销。
对于包括用于大型企业的数据库管理系统(DBMS)或高性能计算的利用大数据集的要求高的、高带宽应用来说,通常通过查询延迟时间和相关联的查询吞吐量来测量和评估性能。为了最小化这种延迟,在可能时待处理的数据被高速缓存在存储器中。由于当数据被高速缓存在存储器中时,从盘存储中读取数据的延迟被消除,因此数据压缩现在可能构成延迟的很大一部分。虽然为了降低延迟常见压缩编解码器可以在硬件中实现,但是算法的复杂度可能增加硬件开发和制造成本。此外,这些压缩编解码器通常被设计为用于对数据进行顺序存取并且可能不适用于支持包括在线事务处理(OLTP)工作负载的高度随机数据存取。
基于上述内容,存在对提供适用于延迟敏感的应用和/或高度随机存取工作负载的成本有效、高性能数据压缩的方法的需要。
本部分描述的方法是可以被实行的方法,但不一定是以前已经被构思或实行的方法。因此,除非另外指示,否则不应当假设本部分所描述的方法中的任何方法仅仅由于它们包含在本部分中而被认定为现有技术。
附图说明
在附图的图中,通过示例的方式而不是限制的方式示出本发明,在附图中相似的附图标号指代相似的元素,并且在附图中:
图1A是描绘了根据实施例的用于使用OZIP压缩数据的示例系统和数据流的框图;
图1B是描绘了根据实施例的用于使用OZIP解压缩数据的示例系统和数据流的框图;
图2A是描绘了根据实施例的用于使用OZIP压缩数据的过程的框图;
图2B是描绘了根据实施例的用于使用OZIP解压缩数据的过程的框图;
图3是在其上可以实现实施例的计算机系统的框图。
具体实施方式
在下面的描述中,出于解释的目的,阐述了许多具体细节以便于提供对本发明的深入理解。然而,明显可以在没有这些具体细节的情况下实践本发明。在其他实例中,公知的结构和设备以框图形式被示出以避免不必要地使本发明模糊。
总体概述
在实施例中,提供了数据压缩编解码器OZIP。OZIP尤其适合于低延迟硬件实现并且为对压缩数据的随机存取提供支持。因此,OZIP具有对诸如用于大型企业的数据库和高性能计算之类的具有随机数据存取的延迟敏感的应用工作负载而言特殊的相关性。通过使用OZIP,应用不再需要在应用性能方面做出巨大牺牲以实现高数据压缩率,从而实现存储器中的数据大小、存储占用空间和网络带宽使用的显著降低。
如上文所讨论的,诸如ZLIB和LZO之类的基于Lempel-Ziv范式的常见数据压缩编解码器由于其复杂度不适合于硬件实现。特别地,软件中昂贵的条件分支算法的使用可能使相应的硬件实现变得成本较高、需要高复杂度的协处理器(coprocessor)或ASIC。
另一方面,OZIP通过使用直接标记(token)编码压缩为静态字典而在很大程度上避免了昂贵的条件分支,从而便于低成本和高性能的硬件实现。因为在没有数据依赖性的情况下OZIP压缩文件的不同部分可以被独立地处理,所以静态字典实现高度并行处理。OZIP还为硬件加速提供若干设计优化,包括由诸如字长(word size)或处理器高速缓存大小之类的硬件架构约束限制的标记定义大小和静态字典大小。因此,通过利用添加到通用处理器的SIMD指令扩展,OZIP可以被高度并行化和加速,从而避免诸如协处理器或专用ASIC之类的高成本且不灵活的硬件解决方案。
另外,常见数据压缩编解码器通常提供不足的随机存取粒度并且因此不适于呈现出高度随机的数据存取工作负载的在线事务处理(OLTP)系统或其他系统。这种随机存取粒度的缺乏可能来源于动态字典或滑动字典(sliding dictionary)的使用,动态字典或滑动字典依赖于输入而改变。这通常使得需要处理压缩文件的大部分以建立用于随机存取的正确的字典。
另一方面,OZIP利用静态字典并且可选择地在存储的元数据中嵌入细粒度的块映射,从而使得任何期望的数据部分能够使用块映射被快速定位并且用已知的静态字典立即被解压缩,而不用等待动态字典被重建。因此,OZIP可以支持诸如用于OLTP系统之类的用于高度随机的工作负载的低延迟随机数据存取。
OZIP压缩系统概述
图1A是描绘了根据实施例的用于使用OZIP压缩数据的示例系统和数据流的框图。图1A的系统100包括输入数据110、候选字典130、修剪后的(pruned)字典140和OZIP压缩文件150。输入数据110包括段112。候选字典130包括1克(gram)条目131、2克条目132、3克条目133、4克条目134、5克条目135、6克条目136、7克条目137和8克条目138。OZIP压缩文件150包括头部(header)152、元数据154、块偏移映射156、字典160和标记170。图1A的系统100还示出了输入分析120、修剪124、紧压(compact)126和标记化(tokenize)128的步骤。输入分析120包括随机采样121。
如图1A所示,压缩通过首先经由输入分析120分析输入数据而开始,输入分析120可以执行快速随机采样121。然后形成候选字典130,候选字典130接着经由修剪124缩减为较小的修剪后的字典140。为了节省空间,在修剪后的字典140被存储为OZIP压缩文件150中的字典160之前,修剪后的字典140可以经由紧压126被进一步压缩。用修剪后的字典140经由标记化128来压缩输入数据110。在标记化128期间还生成元数据154,元数据154包括块偏移映射156,块偏移映射156将标记170中的标记偏移映射为具有指定块大小粒度的输入数据110中的未压缩块。因此,提供了对压缩数据的快速随机存取。注意到在一些实施例中,例如如果对数据的随机存取不是必需的,则包括块偏移映射156的元数据154可以从OZIP压缩文件150中省略。类似于字典160,元数据154在存储在OZIP压缩文件150中时也可以被紧压以节省空间。头部152也可以被添加以使得OZIP解压缩器可以识别OZIP压缩文件150以及在OZIP压缩文件150内包含的元素中的所有元素。
OZIP压缩过程
在系统100的基本概览现在已就位的情况下,评述使用OZIP压缩数据的处理步骤的高层级概述可能是有益的。转向图2A,图2A是描绘了根据实施例的用于使用OZIP压缩数据的过程200的流程图。如下文在“硬件概要”中所描述的,过程200的步骤可以在图3的计算机系统300上执行。
确定静态字典
在过程200的框202处,参照图1A,计算机系统300从输入数据110的至少一部分中确定静态字典或修剪后的字典140。修剪后的字典140包括多达字典条目的最大数量或者图1A中示出的示例中的1024个的多个条目。修剪后的字典140中的条目中的每个条目将标记映射为定义,该定义具有多达由硬件规格限制的最大字节(byte)大小的长度。在图1A中,最大字节大小是8字节,这可以匹配图3中的处理器304的64比特(bit)字长。因此,每个定义可以支持多达8字节或8克的字符串。框202可以响应于计算机系统300上的OZIP压缩程序被调用,该OZIP压缩程序可以由用户手动地调用或者经由来自诸如数据库管理系统之类的正在执行的程序的应用程序接口(API)被自动地调用。
输入数据分析
在修剪后的字典140可以被确定之前,可以首先建立较大的候选字典130。从输入数据110或者要被压缩的数据开始,OZIP需要对诸如段112之类的输入数据110的至少一部分进行存取以执行输入分析120。如输入分析120中所示,分析的一种方法是执行随机采样121,其中诸如段112之类的代表性随机采样被选择以利用对于输入数据110中的所有输入数据的估计的频率值来建立候选字典130。尽管段112被示为在偏移0x40000和0x50000之间的单个相邻的采样,但是随机采样还可以从输入数据110中选择多个段。
注意到随机采样121的使用允许输入分析120避免对全部输入数据110的完整检查(full pass)。如果输入数据110非常大并且如果已知输入数据110具有高的香农(Shannon)熵但是具有低的雷尼(Rényi)熵,其中随机采样将一般代表整个输入,则这尤其是有利的。由于OZIP被设计为用于在压缩具有上文所描述的熵模式的输入数据时具有最佳性能,因此如果在输入分析120期间检测到其他熵的模式,则OZIP可以暂停并且将输入数据110重定向到不同的压缩算法,或者甚至完全绕过压缩。
为了便于优化的字典的生成,输入数据110的部分可以被分类并且由OZIP分开压缩,从而为每个分类提供分开的字典。因此,例如如果OZIP压缩要在数据库背景中被使用,则可以利用分开的字典将表的每列分开地进行OZIP压缩。另一方面,可以利用单个合并的字典将具有相似数据的列合并为单个OZIP压缩文件。在图1A中示出的示例中,整个输入数据110将由单个OZIP操作压缩。
建立候选字典
移动到候选字典130,可以看出字典条目被划分为N克条目,其中N是1和8之间的整数值。例如,由于“Foo”由三个字符字节组成,因此用于“Foo”的字典条目被分类到3克条目133中。由于字典条目延伸至多达8克条目138,因此每个定义可以具有多达8字节的最大字节大小。尽管为从1到8的每个可能的N克提供了分开的N克条目,但是取决于输入数据110内的数据模式,一些N克可以是空的并且具有零个条目。
最大字节大小可以被配置为对应于硬件规格,例如基于处理器的字长,包括诸如半字(half word)或四倍字(quad word)之类的字长的分数和倍数。例如,64比特处理器架构可以利用64比特字长和64比特寄存器,在这种情况中用于字典定义的8字节的最大字节大小可能是合适的。类似地,对于128比特字长,16字节的最大字节大小可能是合适的。然而,用于字典定义的最大字节大小还可以基于其他性能考虑被配置并且不一定需要基于字长。
在候选字典130内,可以利用用于从0x00到0xFF的所有256字节值的条目来预先填充1克条目131。以这种方式,压缩器被保证能够标记化任何输入数据。剩余的N克条目132-138可以使用从输入数据110的段112中建立的诸如树结构之类的各种数据结构各自被填充。因此,N克条目131-138可以以频率的降序各自被维护,其中如果超出了最大可能数量的候选条目或者如图1A中示出的2048个总条目,则频率较低的N克被移除。移除某个N克的决定还可以基于统计数据、历史数据和启发式方法(heuristics)。由于在该点处候选字典130仅是候选项的列表,因此每个条目还没有分配的标记值。
为了简洁起见,仅为3克条目133示出了候选字典130中的示例字典条目,其中字符串“Foo”或者三个连续的字节0x46、0x6F和0x6F在输入数据110的段112内出现了200次。字符串“Bar”出现了150次,而字符串“Baz”出现了3次。注意到虽然为了简单起见图1A中的示例定义被示为常规的字母数字字符串,但是定义当然可以包括包含空字符(null)或0x00值的任何任意二进制数据值,因为修剪后的字典140中的定义将总是使用分开的长度指示符而不是以空字符终止的字符串来分配最大字节大小。
修剪候选字典
如图1A所示,候选字典130可以包括多达2048个总条目的最大值以作为用于考虑的候选项。该候选最大值可以被设置为大于用于字典160的最大条目数量或者如修剪后的字典140所指示的1024个总条目的某值。修剪124被配置为试图最小化标记170的大小。例如,修剪124可以移除候选字典130中最不频繁出现的候选项直至达到期望的条目数量。由于“Baz”字符串出现相对不频繁或者3次,因此“Baz”字符串和其他不频繁出现的字符串可以在修剪124中被移除。除了原始频率数据外,修剪124还可以考虑统计数据、历史数据和启发式方法。
用于字典160和修剪后的字典140的条目的最大数量可以被配置为对应于硬件规格。例如,为了较快的压缩和解压缩可能期望能够将字典定义中的所有定义容纳在处理器高速缓存内。由于每个定义占用8字节,因此1024个定义占用8192字节或者8K。注意到不管字典定义的实际长度或克如何,总是为每个定义预留8字节以便于硬件实现。8K的数据可以足够小以全部地容纳在任何现代处理器的L1处理器高速缓存内。因此,用于字典160的条目的最大数量可以被保守地设定大小以使得字典定义可能容纳在处理器高速缓存内。
另外,通过使用有限数量的条目,每个压缩的标记仅需要一定数量的比特以使所有字典条目是可寻址的。在1024个总条目的情况中,由于1024等于2^10,因此每个标记仅需要10比特以能够对字典中的所有1024个条目寻址。因此,条目的数量还可以被限制以降低标记比特大小,这可以帮助实现较高的压缩率。尽管该标记编码不适应行程长度编码(RLE),但是这可以是合理的折衷,因为RLE对于高熵数据来说可能具有有限的有效性。
以更多细节考察修剪后的字典140,可以看出每个条目包含四列:标记、长度、定义以及可选择地分析的输入数据内定义的频率。在图1A中示出的示例中,标记是10比特值,而长度是从1到8的整数。为了节省空间,长度和频率可以仅用它们需要的范围所需要的最小比特来存储。例如,由于在图1A中示出的示例中长度总是从1到8的整数,因此每个长度可以由3比特值表示。类似地,取决于在输入分析120期间遇到的最大频率,为频率列分配的比特的数量也可以是有限的。此外,尽管为了清楚起见,标记在修剪后的字典140中被显式地列出,但是标记可以由诸如数组之类的数据结构中的它们的索引位置隐式地指示。另外,如上文所讨论的,不管定义的实际长度如何,每个定义具有预留的最大字节大小。因此,额外的剩余字节可以被清零(zero out)或者未被初始化,这由指示填充字节或不用理会(do notcare)字节的“*”标记所指示。
静态字典映射
为了简单起见,图1A中仅示出了修剪后的字典140的选择的部分。由于修剪后的字典140对应于最终的静态字典,因此在该点处每个定义也被分配了特定的标记映射。由于每个标记占用恒定量的空间或者示出的示例中的10比特,因此标记映射的排序可以被任意地选择。如之前所讨论的,所有1克条目131可以被预先填充,以使得任何输入数据保证被标记化,并且这些1克条目可以被传送到修剪后的字典140。因此,如图1A所示,1克的“A”被映射为10比特标记“0000000000”,1克的“B”被映射为10比特标记“0000000001”,而1克的“C”被映射为10比特标记“0000000010”,等等。在一些情况中,字典160将对于附加的输入数据被重复使用或者作为新OZIP压缩文件的基础而被使用。在这种情况中,可能期望保留修剪后的字典140的可选择的频率列以供进一步输入分析中使用。
接下来,两个最频繁出现的3克条目133或者“Foo”和“Bar”被示出,它们分别被分配了10比特标记值“0001000000”和“0001000001”。由于3克条目“Baz”仅出现了3次,因此它可能已经在修剪124中被移除,并且因此不在修剪后的字典140中。还示出了附加的示例条目,包括具有标记值“0101001111”的4克“This”、具有标记值“1000001001”的5克“Great”和具有标记值“1111111111”的8克“Renderer”。
标记化输入数据
在输入数据110和修剪后的字典140二者都可用的情况下,输入数据110的标记化现在可以继续。在过程200的框204处,参照图1A,计算机系统300使用静态字典或者修剪后的字典140标记化输入数据110以生成压紧的(packed)、顺序的多个标记或者标记170。如上文所讨论的,由于修剪后的字典140利用10比特标记,因此标记170中的每个标记将具有被配置为对修剪后的字典140中的最大数量的字典条目(1024个或者2^10个条目)寻址的固定的标记大小(10比特)。
由于顺序标记化的过程搜索输入数据110以匹配修剪后的字典140内的字典条目,因此各种数据结构和诸如trie搜索之类的搜索技术可以被用于框204的标记化过程。一旦匹配被找到,则来自修剪后的字典140的标记可以被写入标记170中,标记170可以在主存储器306内分配的缓冲区中。由于标记可能没有均等地对齐到8比特字节边界,因此相邻的标记的对齐的块可以被写入,并且填充符(padding)可以被添加到标记170的末端以用于字节对齐。
存储OZIP压缩文件
在压缩数据或者标记170现在可用的情况下,OZIP压缩文件150的写入和存储现在可以继续。在过程200的框206处,参照图1A,计算机系统300存储字典160、标记170以及可选择地存储元数据154。如上文所讨论的,为了节省空间,紧压126可以压缩修剪后的字典140和/或元数据154。然而,在其他实施例中,紧压126可以被省略,在这种情况中字典160可以包括字典140原样。头部152也可以被添加以使得OZIP解压缩器可以识别OZIP压缩文件150和OZIP压缩文件150内的所有元素。在一些实施例中,OZIP压缩文件150可以被存储在主存储器306中而不用持久保留到存储设备310。在其他实施例中,OZIP压缩文件150也可以被持久保留到存储设备310。
元数据154包括块偏移映射156,块偏移映射156为具有定义的未压缩块大小的多个顺序数据块中的每个数据块指示标记170内的标记偏移,其中该多个顺序数据块对应于输入数据110。块偏移映射156可以被创建为上面的框204中的标记化128的部分。如上文所讨论的,存储元数据154是可选的并且在某些实施例中可以被省略。块偏移映射156通过将未压缩块的偏移映射为标记170内的特定标记偏移来允许对压缩数据的细粒度的随机存取。未压缩块的大小可以根据随机存取的所期望的粒度来被定义。例如,在数据库背景下,未压缩块可以被设置为数据库块的大小。一旦识别了标记偏移,则由于利用了具有固定大小的标记的静态字典160,而不是具有可变大小的标记的动态字典或滑动字典,因此标记可以被立即定位和解压缩。块偏移映射156的结构的详细讨论将会被推迟至下文接着的OZIP解压缩过程的讨论后。
OZIP解压缩系统概述
图1B是描绘了根据实施例的用于使用OZIP解压缩数据的示例系统和数据流的框图。图1B的系统102包括OZIP压缩文件150、应用180、随机读取请求185以及输出数据部分190。OZIP压缩文件150包括头部152和元数据154、字典160以及标记170。元数据154包括块偏移映射156。标记170包括标记172A、标记172B、标记172C和标记172D。参照图1B,编号元素可以对应于来自图1A的相似的编号元素。
如图1B所示,解压缩由接收到对于OZIP压缩文件150的来自应用180的随机读取请求185开始。输出数据部分190响应于随机读取请求185而被提供,输出数据部分190被提供回原始请求的应用180,原始请求的应用180可以是在图3的计算机系统300上执行的诸如数据库管理系统之类的程序。
OZIP解压缩过程
在系统102的基本概览现在已就位的情况下,评述使用OZIP解压缩数据的处理步骤的高层级概述可能是有益的。转向图2B,图2B是描绘了根据实施例的用于使用OZIP解压缩数据的过程210的流程图。如下文在“硬件概要”中所描述的,过程210的步骤可以在图3的计算机系统300上执行。因此,OZIP压缩文件150可以被分配在计算机系统300的主存储器306中,并且框212、214和216可以接收来自主存储器306的它们分别所描述的元素。
接收OZIP压缩文件
在过程210的框212处,参照图1B,计算机系统300接收来自OZIP压缩文件150的静态字典或者字典160。如之前所讨论的,字典160可以经由紧压126被压缩,在这种情况中字典160可以在使用之前被解压缩。如图1A所示并且如上文在框202中所描述的,字典160可以具有对应于修剪后的字典140的结构。框212可以响应于计算机系统300上的OZIP解压缩程序而被调用,该OZIP解压缩程序可以由用户手动地调用或者经由来自诸如数据库管理系统之类的正在执行的程序的应用程序接口(API)被自动地调用。
在过程210的框214处,参照图1B,计算机系统300接收来自OZIP压缩文件150的压紧的、顺序的多个标记或标记170。标记170的结构的详细描述将会被推迟至下文的框216的讨论后。
在过程210的框216处,参照图1B,计算机系统300接收如上文在框206中所描述的、包括块偏移映射156的元数据154。然而,由于过程210是在解压缩的背景下而不是在压缩的背景下,因此块偏移映射156属于未压缩的或者未压紧的(unpacked)输出数据而不是属于图1A的未压缩输入数据110,未压缩输入数据110在图1B中不存在。
响应于完整读取请求
尽管框218、220和222示出了用于请求数据的特定偏移和大小的随机读取示例的过程,但是在一些实施例中,对于压紧的、顺序的多个标记中的所有标记的完整读取请求可以被发出。当元数据154从OZIP压缩文件150中省略时,可能出现这种情况。在这种情况中,框218接收完整读取请求或者具有与输入数据110的大小相等的大小的、在偏移0处的读取,框220被跳过,而框222将压紧的、顺序的多个标记中的所有标记作为“标记组”处理。在标题“响应于随机读取请求”下,下文将以更多细节描述框218、220和222内的具体步骤。
用于随机存取的块偏移映射
在详细讨论框218、220和222之前,首先考察元数据154的结构可能是有益的。因此,图1B中示出了元数据154和块偏移映射156的更详细的结构。元数据154指定10字节的定义的未压缩块大小,这是出于说明的目的选择的相对小的块大小。在生产环境中,由于增大的元数据和处理开销,非常小的未压缩块大小可能是不期望的。如之前所讨论的,未压缩块大小可以根据期望的随机存取粒度被配置并且与应用要求匹配。
转向块偏移映射156,为未压缩块编号0、1和2示出了三个示例条目。如图1B所示,定义了四列:块#或未压缩块编号、标记偏移或标记170中的位置、标记或未压缩块中引用的标记的数量以及(如果有必要的话)跨度偏移(span offset)或要从前一个跨越标记(spanning token)中读取的未压缩偏移。尽管为了清楚起见,块偏移映射156显式地包括块#和标记偏移,但是块#还可以隐式地从索引中确定,例如如果块偏移映射156被存储为数组。对于任何给定块#的标记偏移还可以通过将所有先前的块中的标记相加来导出。因此,为了节省空间,当块偏移映射156被存储在OZIP压缩文件150中时,块偏移映射156可以不显式地包括块#和标记偏移。
继续讨论块偏移映射156的示例映射,参照标记170,对于块#0或在0处开始并且在10处结束的未压缩字节来说,标记偏移是0,标记是3,而跨度偏移是0。换句话说,块#0的读取在第0个标记上开始或者在标记170中的第0个比特处开始、包含3个标记或标记172A-172C并且不需要关注来自前一个块的跨越标记。跨越标记是映射到邻近的未压缩块的标记,跨越标记由标记172C示出。
对于块#1或在10处开始并且在20处结束的未压缩字节来说,标记偏移是3,标记是1,而跨度偏移是3。换句话说,块#1的读取将通常在第3个标记上开始或者在标记170中的第30个比特处开始、包含1个标记或标记172D并且必须通过从来自前一个块的跨越标记或标记172C的3字节的未压缩偏移中读取来调整。因此,读取实际上从前一个跨越标记或者在第20个比特处开始以适应跨越标记,并且仅从跨越标记的第3个字节开始读取未压缩字节。如标记170中所示,这对应于在从未压缩数据偏移7起、值为3的偏移处读取未压缩标记172C的字节或者字节10和11。注意到由于标记172C已经被计入块#0中,因此它不被计为块#1中的标记。
块偏移映射156中示出的跨度偏移是适应跨越标记的一种特定的方法。还可以利用其他方法,诸如通过为控制码预留字典条目或者通过将跨越标记拆分成分开的标记以保证与未压缩块的对齐。然而,为了降低开销和处理复杂度,跨度偏移方法可能是更优选的。
对于块#2或在20处开始并且在30处结束的未压缩字节来说,标记偏移是4,标记是6,而跨度偏移是0。换句话说,块#2的读取将在第4个标记上开始或者在标记170中的第40个比特处开始、包含6个标记(未示出)并且不需要关注来自前一个块的跨越标记。
当然,给定的读取请求可以不一定准确地对齐到在块偏移映射156中被映射的块。然而,通过配置未压缩块大小以提供足够的粒度,可以仅处理最少数量的不必要的标记以开始答复读取请求。如上文所讨论的,未压缩块大小可以与诸如数据库块大小之类的应用要求匹配,在这种情况中粒度将准确地匹配应用需要同时避免对不必要的标记的任何处理。因此,与静态字典160结合的块偏移映射156的存在实现对OZIP压缩数据或标记170的快速随机存取。
响应于随机读取请求
在过程210的框218处,参照图1B,计算机系统300接收来自应用180的随机读取请求185以提供输出数据部分190。如之前所讨论的,应用180可以是在计算机系统300上执行的程序,诸如数据库管理系统。如图1B所示,随机读取请求185是为了获得未压紧的输出数据,该输出数据对应于从第5个字节开始、包含15个字节并且在第20个字节处结束但是不包括第20个字节的OZIP压缩文件150的未压缩部分。因此,结尾是第19个字节,包括第19个字节。
在过程210的框220处,参照图1B,计算机系统300基于元数据154确定来自标记170的一组标记以答复随机读取请求185。更具体地,第5个字节的所请求的起始偏移以及第19个字节的所请求的终止偏移可以是被未压缩块大小或者10字节除的整数,以确定合适的起始块#和终止块#。因此,起始块是5/10=块#0,而终止块是19/10=块#1。相应地,如块偏移映射156所指示的,该组标记可以被确定为包括来自标记170的4个标记或者被映射到块#0(3个)、块#1(1个)以及任何和全部在两者中间的块(没有)的标记的总数。如果所请求的起始偏移是对于指示非零跨度偏移的块,则该组标记还可以包括附加的跨越标记。
在过程210的框222处,参照图1B,计算机系统300使用字典160处理从框220中确定的一组标记以将输出数据部分190写入到输出缓冲区中,输出缓冲区可以被分配在图3的主存储器306中。尽管上面在框220中确定了该组标记包括4个标记,但是实际上可以处理和解压缩少于4个标记,因为在与随机读取请求185不相关的起始块和终止块中的标记可以不必被处理和解压缩。
使用块偏移映射156,起始块#0对应于标记偏移0或者在比特偏移0*10=0处的标记172A。然而,由于整数除法的余数是5,因此标记必须首先被解析以寻找精确的标记来开始解压缩。因此,标记172A可以被读取并且4字节的指示的大小可以被添加到被初始化为零的正在运行的计数器。注意到由于每个标记172A-172D的大小实际上在字典160中被查找,因此出于清楚的原因仅在标记172A-172D中示出了大小。由于下一个标记或标记172B具有3字节的大小,这将使得正在运行的计数器超出余数5,因此实际的解压缩在标记172B处开始。
通过在字典160或者参照图1A的修剪后的字典140中查找标记172B,标记172B对应于“Foo”。然而,为了在正确的偏移处开始读取,未压缩数据在余数减去正在运行的计数器或5–4=1的数据偏移处被读取。因此,仅仅从“Foo”中读取了“oo”部分。附加的标记可以被解压缩直至检索了所请求的数据的大小或者如每随机读取请求185的15字节。因此,“oo”部分与解压缩后的标记172C和172D或者“Great”和“Renderer”相连结(concatenate),如输出数据部分190所示。因此,框222处理4个标记但是仅解压缩3个标记。输出数据部分190可以接着响应于随机读取请求185被传递回应用180,从而完成过程210。
硬件加速的OZIP解压缩
为了便于硬件实现,不管定义的实际长度如何,当单个标记被解压缩时,定义的最大字节长度或者全部8个字节可以总是被写入。指向输出缓冲区的写入指针被向前移动该长度,以使得下一个标记在正确的位置处被解压缩。以这种方式,避免了条件分支逻辑,因为对于每个标记的定义总是写入最大数量的字节并且指针总是增加了相关联的长度。对于具有在标记的中间的起始偏移或终止偏移的随机读取请求的特殊情况,标记可以被完全解压缩,但是其中与随机读取请求不相关的部分被截断。因此,OZIP解压缩的硬件实现容易以高性能、成本有效的方式被提供。
OZIP解压缩可以通过用单个处理器指令一次连结多个解压缩后的标记而被进一步加速。例如,处理器304可以支持指令“vlbpk”或者“可变长度字节包(Variable LengthByte Pack)”,该指令接受两个SIMD寄存器作为输入:包括具有其最大字节大小的定义的第一寄存器,以及包括相应的定义的长度的第二寄存器。输出是具有被截断到指定长度并且被连结在一起的定义的SIMD寄存器,然后这些定义可以被写入到输出缓冲区中(并且如果需要的话被截断)。诸如GPU加速之类的其他方法也可以被实行。
例如,假设输入数据110在偏移0处开始,其中20个字节的数据对应于字符串“ThisFooGreatRenderer”。通过用修剪后的字典140标记化或压缩,这对应于如图1B的标记170中示出的标记172A-172D。如果随机读取请求185替代地请求从字节偏移0开始读取20个字节,则标记172A-172D都要被完整地解压缩。与其每次一个地处理标记172A-172D并且将解压缩后的标记写入到输出数据部分190,不如可以利用“vlbpk”指令以一次连结多个解压缩后的标记。
因此,通过在字典160中查找标记172A-172D,至少256比特的第一SIMD寄存器可以用对于标记172A-172D映射的定义来填充,而第二SIMD寄存器可以用标记172A-172D的相应长度来填充:
SIMD寄存器1(至少256比特):“This****Foo*****Great***Renderer”
SIMD寄存器2(至少32比特):“0x04|0x03|0x05|0x08”
其中*指示填充字节或不用理会的字节。
上面的示例假设SIMD寄存器2中的长度为8比特值,然而通过在“vlbpk”指令中支持比特大小输入、通过修改标志寄存器或者通过在处理器304中硬编码不同的比特大小可以指定其他比特大小。附加地,其他实施例可以接受指向存储器的指针而不是SIMD寄存器。输出SIMD寄存器如下所示被填充:
输出SIMD寄存器(至少256比特):“ThisFooGreatRenderer************”
由于通过考察SIMD寄存器2,写入来自SIMD寄存器1的每个定义的偏移是已知的,因此每个定义可以被并发地写入到输出SIMD寄存器中的正确位置。一旦输出SIMD寄存器被填充,则寄存器的所有比特可以被写入到输出缓冲区,其中写入指针在输出缓冲区中前进长度的总和或者在该示例中的20字节。因此,可以为处理器304提供并行化的、硬件加速的打包的(packing)指令以改善OZIP解压缩性能。
更进一步,如果大量数据正在被请求以用于解压缩,则可以部署多个线程以并发地解压缩OZIP压缩文件的不同部分,这是因为由于静态字典160的使用,每个部分可以在没有任何数据依赖性的情况下被独立地处理。然而,需要一些协调以确保不同的解压缩后的部分被放置在正确的偏移处。
硬件概要
根据一个实施例,本文所描述的技术由一个或多个专用计算设备实现。专用计算设备可以被硬连线以执行技术,或者可以包括被永久编程以执行技术的诸如一个或多个专用集成电路(ASIC)或现场可编程门阵列(FPGA)之类的数字电子设备,或者可以包括被编程以根据固件、存储器、其他存储或者组合中的程序指令来执行技术的一个或多个通用硬件处理器。这样的专用计算设备还可以用定制编程将定制的硬连线逻辑、ASIC或FPGA结合以实现技术。专用计算设备可以是将硬连线的和/或程序逻辑结合以实现技术的桌上型计算机系统、便携式计算机系统、手持设备、联网(networking)设备或任何其他设备。
例如,图3是示出在其上可以实现本发明的实施例的计算机系统300的框图。计算机系统300包括用于传送信息的总线302或其他通信机构,以及用于处理信息的、与总线302耦接的硬件处理器304。硬件处理器304可以是例如通用微处理器。
计算机系统300还包括用于存储由处理器304执行的信息和指令的、耦接到总线302的主存储器306,诸如随机存取存储器(RAM)或其他动态存储设备。主存储器306还可以被用于在由处理器304执行的指令的执行期间存储临时变量或其他中间信息。这样的指令当被存储在对于处理器304来说可访问的存储媒介中时,使计算机系统300变为被定制以执行指令中指定的操作的专用机器。
计算机系统300还包括用于为处理器304存储静态信息和指令的、耦接到总线302的只读存储器(ROM)308或其他静态存储设备。诸如磁盘或光盘之类的存储设备310被提供并且被耦接到总线302以用于存储信息和指令。
计算机系统300可以经由总线302被耦接到诸如阴极射线管(CRT)之类的显示器312以用于向计算机用户显示信息。包括字母数字和其他键的输入设备314被耦接到总线302以用于向处理器304传送信息和命令选择。另一种类型的用户输入设备是用于向处理器304传送方向信息和命令选择以及用于控制显示器312上的光标移动的光标控制器316,诸如鼠标、跟踪球或光标方向键。该输入设备通常具有允许设备在平面上指定位置的在两个轴——第一轴(例如,x)和第二轴(例如,y)上的两个自由度。
计算机系统300可以使用与计算机系统结合使得计算机系统300成为专用机器或者将计算机系统300编程为专用机器的定制的硬连线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑来实现本文描述的技术。根据一个实施例,响应于处理器304执行包含在主存储器306中的一个或多个指令的一个或多个序列,本文描述的技术由计算机系统300执行。这些指令可以从诸如存储设备310之类的另一个存储介质被读取到主存储器306中。包含在主存储器306中的指令的序列的执行使得处理器304执行本文所描述的过程步骤。在可替代的实施例中,硬连线电路可以代替软件指令或与软件指令结合使用。
如在此所使用的术语“存储媒介”是指存储使得机器以特定方式操作的数据和/或指令的任何媒介。这样的存储媒介可以包括非易失性媒介和/或易失性媒介。非易失性媒介包括例如光盘或磁盘,诸如存储设备310。易失性媒介包括动态存储器,诸如主存储器306。常见形式的存储媒介包括例如软盘、柔性盘、硬盘、固态驱动器、磁带或任何其他磁数据存储介质、CD-ROM、任何其他光数据存储介质、具有孔的图案的任何物理介质、RAM、PROM和EPROM、FLASH-EPROM、NVRAM、任何其他存储器芯片或记忆卡。
存储媒介不同于传输媒介,但是可以结合传输媒介被使用。传输媒介参与在存储媒介之间传送信息。例如,传输媒介包括同轴线缆、铜线和光纤,这些传输媒介包含包括总线302的线。传输媒介还可以采取声波或光波的形式,诸如在无线电波和红外数据通信期间生成的那些声波或光波。
将一个或多个指令的一个或多个序列承载到处理器304以用于执行可以涉及各种形式的媒介。例如,指令可以初始地被承载在远程计算机的磁盘或固态驱动器上。远程计算机可以将指令加载到它的动态存储器并且使用调制解调器通过电话线发送指令。计算机系统300的本地调制解调器可以接收电话线上的数据并且使用红外传输器将数据转换成红外信号。红外检测器可以接收红外信号中承载的数据而合适的电路可以将数据放置在总线302上。总线302将数据承载到主存储器306,处理器304从主存储器306检索指令并且执行指令。由主存储器306接收的指令可以可选择地或者在由处理器304执行之前或者在由处理器304执行之后被存储在存储设备310上。
计算机系统300还包括耦接到总线302的通信接口318。通信接口318提供耦接到网络链路320的双向数据通信,网络链路320被连接到本地网络322。例如,通信接口318可以是综合业务数字网(ISDN)卡、线缆调制解调器、卫星调制解调器或者调制解调器以提供到相应类型的电话线的数据通信连接。作为另一示例,通信接口318可以是局域网(LAN)卡以提供到兼容的LAN的数据通信连接。无线链路也可以被实现。在任何这样的实施方式中,通信接口318发送和接收承载表示各种类型的信息的数字数据流的电信号、电磁信号或光信号。
网络链路320通常通过一个或多个网络提供到其他数据设备的数据通信。例如,网络链路320可以通过本地网络322提供到主机计算机324或到由网络服务提供商(ISP)326操作的数据装置的连接。ISP326又通过现在通常被称为“因特网”328的全球分组数据通信网提供数据通信服务。本地网络322和因特网328都使用承载数字数据流的电信号、电磁信号或光信号。通过各种网络的信号和在网络链路320上并通过通信接口318的信号是传输媒介的示例形式,所述信号承载到计算机系统300的数字数据以及来自计算机系统300的数字数据。
计算机系统300可以通过网络(多个网络)、网络链路320和通信接口318来发送消息和接收包括程序代码的数据。在因特网示例中,服务器330可以通过因特网328、ISP 326、本地网络322和通信接口318来传送用于应用程序的请求的代码。
接收的代码可以在处理器304接收时由其执行,和/或存储在存储设备310或者其他非易失性存储中以用于以后执行。
在上述说明书中,参考可以根据实施方式而不同的许多具体细节描述了本发明的实施例。因此,本发明是什么以及申请人意图将什么作为本发明的唯一且排他的指示物是以权利要求发布的具体形式从本申请中发布的一组权利要求,包括任何后续补正。用于包含在权利要求中的术语的本文明确阐述的任何定义应当决定在权利要求中使用的这些术语的含义。因此,在权利要求中没有明确表述的限制、元件、性质、特征、优点或属性都不应当以任何方式限制这些权利要求的范围。因此,说明书和附图应被视为是说明意义上的而不是限制意义上的。
附加的公开
在实施例中,一种方法包括:从输入数据的一部分中确定静态字典,该静态字典包括多达字典条目的最大数量的多个条目,多个条目中的每个条目将标记映射为定义,该定义具有多达由硬件规格限制的最大字节大小的长度;使用静态字典标记化输入数据以生成压紧的、顺序的多个标记,压紧的、顺序的多个标记中的每个标记具有被配置为对最大数量的字典条目寻址的固定标记大小;存储静态字典和压紧的、顺序的多个标记;其中该方法由一个或多个计算设备执行。
在实施例中,该存储还存储包括块偏移映射的元数据,块偏移映射为具有定义的未压缩块大小的多个顺序的数据块中的每个数据块指示压紧的、顺序的多个标记内的标记偏移,其中该多个顺序的数据块对应于输入数据。
在实施例中,该确定包括:搜索所述输入数据的所述部分以建立候选字典,该候选字典具有大于字典条目的最大数量的候选数量的字典条目,候选字典包括全部1克条目以及最频繁出现的N克条目,其中N是从2到最大字节大小的整数值;修剪候选字典以形成具有最大数量的字典条目的静态字典,其中该修剪被配置为试图最小化压紧的、顺序的多个标记的大小。
在实施例中,静态字典还包括用于多个条目中的每个条目的频率计数。
在实施例中,所述输入数据的部分从所述输入数据中被随机采样。
在实施例中,硬件规格基于该一个或多个计算设备的字长。
在实施例中,字典条目的最大数量被配置以使得静态字典中的多个条目的每个定义可以容纳在该一个或多个计算设备的处理器高速缓存内。
在实施例中,一种方法包括:接收包括多达字典条目的最大数量的多个条目的静态字典,该多个条目中的每个条目将标记映射为定义,该定义具有多达由硬件规格限制的最大字节大小的长度;接收压紧的、顺序的多个标记,该压紧的、顺序的多个标记中的每个标记具有被配置为对最大数量的字典条目寻址的固定的标记大小;响应于请求使用静态字典处理压紧的、顺序的多个标记以写入到输出缓冲区中;其中该方法由一个或多个计算设备执行。
在实施例中,请求具有所请求的大小、在所请求的偏移处,其中该处理是为了获得压紧的、顺序的多个标记中的一组标记,以及其中该方法还包括在该处理之前:接收包括块偏移映射的元数据,该块偏移映射为具有定义的未压缩块大小的多个顺序的数据块中的每个数据块指示压紧的、顺序的多个标记内的标记偏移,其中该多个顺序的数据块对应于未压紧的输出数据;基于元数据确定来自压紧的、顺序的多个标记的一组标记以答复请求。
在实施例中,硬件规格基于该一个或多个计算设备的字长。
在实施例中,字典条目的最大数量被配置以使得静态字典中的多个条目的每个定义可以容纳在该一个或多个计算设备的处理器高速缓存内。
在实施例中,该处理使用该一个或多个计算设备的单指令、多数据(SIMD)指令以一次连结该组标记中的多个未压紧的标记。
在实施例中,该处理将来自映射到该组标记中的每个标记的静态字典中的定义的、与最大字节大小相等的数量的字节写入到指向输出缓冲区的写入指针,其中该写入指针前进被映射到该组标记中的每个标记的静态字典中的定义的长度。
Claims (15)
1.一种方法,包括:
从输入数据的一部分确定静态字典,所述静态字典包括多达字典条目的最大数量的多个条目,所述多个条目中的每个条目将标记映射为定义,所述定义具有多达由硬件规格限制的最大字节大小的长度;
使用所述静态字典标记化所述输入数据以生成压紧的、顺序的多个标记,所述压紧的、顺序的多个标记中的每个标记具有被配置为对所述最大数量的字典条目寻址的固定标记大小;
存储所述静态字典和所述压紧的、顺序的多个标记;
其中所述方法由一个或多个计算设备执行。
2.如权利要求1所述的方法,其中所述存储还存储包括块偏移映射的元数据,所述块偏移映射为具有定义的未压缩块大小的多个顺序的数据块中的每个数据块指示所述压紧的、顺序的多个标记内的标记偏移,其中所述多个顺序的数据块对应于所述输入数据。
3.如权利要求1所述的方法,其中所述确定包括:
搜索所述输入数据的所述部分以建立候选字典,所述候选字典具有大于所述字典条目的最大数量的候选数量的字典条目,所述候选字典包括全部1克条目以及最频繁出现的N克条目,其中N是从2到所述最大字节大小的整数值;
修剪所述候选字典以形成具有所述最大数量的字典条目的所述静态字典,其中所述修剪被配置为试图最小化所述压紧的、顺序的多个标记的大小。
4.如权利要求1所述的方法,其中所述静态字典还包括用于所述多个条目中的每个条目的频率计数。
5.如权利要求1所述的方法,其中所述输入数据的所述部分被从所述输入数据中随机采样。
6.如权利要求1所述的方法,其中所述硬件规格基于所述一个或多个计算设备的字长。
7.如权利要求1所述的方法,其中所述字典条目的最大数量被配置以使得所述静态字典中的所述多个条目的每个定义能够容纳在所述一个或多个计算设备的处理器高速缓存内。
8.一种方法,包括:
接收包括多达字典条目的最大数量的多个条目的静态字典,所述多个条目中的每个条目将标记映射为定义,所述定义具有多达由硬件规格限制的最大字节大小的长度;
接收压紧的、顺序的多个标记,所述压紧的、顺序的多个标记中的每个标记具有被配置为对所述最大数量的字典条目寻址的固定的标记大小;
响应于请求,使用所述静态字典处理所述压紧的、顺序的多个标记以写入到输出缓冲区中;
其中所述方法由一个或多个计算设备执行。
9.如权利要求8所述的方法,其中所述请求具有所请求的大小、在所请求的偏移处,其中所述处理是为了获得所述压紧的、顺序的多个标记中的一组标记,以及其中所述方法还包括在所述处理之前:
接收包括块偏移映射的元数据,所述块偏移映射为具有定义的未压缩块大小的多个顺序的数据块中的每个数据块指示所述压紧的、顺序的多个标记内的标记偏移,其中所述多个顺序的数据块对应于未压紧的输出数据;
基于元数据确定来自所述压紧的、顺序的多个标记的所述一组标记以答复所述请求。
10.如权利要求8所述的方法,其中所述硬件规格基于所述一个或多个计算设备的字长。
11.如权利要求8所述的方法,其中所述字典条目的最大数量被配置以使得所述静态字典中的所述多个条目的每个定义能够容纳在所述一个或多个计算设备的处理器高速缓存内。
12.如权利要求8所述的方法,其中所述处理使用所述一个或多个计算设备的单指令、多数据(SIMD)指令以一次连结所述一组标记中的多个未压紧的标记。
13.如权利要求8所述的方法,其中所述处理将来自被映射到所述一组标记中的每个标记的所述静态字典中的所述定义的、与所述最大字节大小相等的数量的字节写入到指向所述输出缓冲区的写入指针,其中所述写入指针前进被映射到所述一组标记中的每个标记的所述静态字典中的所述定义的所述长度。
14.一种装置,包括被配置为执行如权利要求1-13中任何一项权利要求所述的方法的一个或多个设备。
15.一种计算机可读存储介质,所述计算机可读存储介质包括指令,当一个或多个处理器执行所述指令时,使得权利要求1-13中任何一项权利要求所述的方法被执行。
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201461955574P | 2014-03-19 | 2014-03-19 | |
US61/955,574 | 2014-03-19 | ||
US14/337,113 | 2014-07-21 | ||
US14/337,113 US9697221B2 (en) | 2014-03-19 | 2014-07-21 | OZIP compression and decompression |
PCT/US2015/020792 WO2015142749A1 (en) | 2014-03-19 | 2015-03-16 | Ozip compression and decompression |
Publications (2)
Publication Number | Publication Date |
---|---|
CN106233632A true CN106233632A (zh) | 2016-12-14 |
CN106233632B CN106233632B (zh) | 2019-08-06 |
Family
ID=54142300
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201580020897.7A Active CN106233632B (zh) | 2014-03-19 | 2015-03-16 | Ozip压缩和解压缩 |
Country Status (4)
Country | Link |
---|---|
US (2) | US9697221B2 (zh) |
EP (1) | EP3120266B1 (zh) |
CN (1) | CN106233632B (zh) |
WO (1) | WO2015142749A1 (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110662061A (zh) * | 2018-06-29 | 2020-01-07 | 想象技术有限公司 | 有保证的数据压缩 |
US12034934B2 (en) | 2018-06-29 | 2024-07-09 | Imagination Technologies Limited | Guaranteed data compression |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9697221B2 (en) * | 2014-03-19 | 2017-07-04 | Oracle International Corporation | OZIP compression and decompression |
US10867273B2 (en) | 2014-09-26 | 2020-12-15 | Oracle International Corporation | Interface for expanding logical combinations based on relative placement |
US9965546B2 (en) * | 2015-03-24 | 2018-05-08 | Sap Se | Fast substring fulltext search |
US10169362B2 (en) | 2016-07-07 | 2019-01-01 | Cross Commerce Media, Inc. | High-density compression method and computing system |
US10747638B2 (en) * | 2018-04-18 | 2020-08-18 | Oracle International Corporation | Computing memory health metrics |
US11309908B2 (en) * | 2018-11-26 | 2022-04-19 | Fungible, Inc. | Static dictionary-based compression hardware pipeline for data compression accelerator of a data processing unit |
US10944423B2 (en) * | 2019-03-14 | 2021-03-09 | International Business Machines Corporation | Verifying the correctness of a deflate compression accelerator |
US10983915B2 (en) * | 2019-08-19 | 2021-04-20 | Advanced Micro Devices, Inc. | Flexible dictionary sharing for compressed caches |
US20210144226A1 (en) * | 2019-11-13 | 2021-05-13 | Microsoft Technology Licensing, Llc | Partial downloads of compressed data |
US11362672B2 (en) * | 2020-05-08 | 2022-06-14 | Qualcomm Incorporated | Inline decompression |
CN115149958A (zh) * | 2021-03-30 | 2022-10-04 | 华为技术有限公司 | 数据压缩方法及装置 |
US11681659B2 (en) * | 2021-05-21 | 2023-06-20 | Red Hat, Inc. | Hybrid file compression model |
US11907206B2 (en) | 2021-07-19 | 2024-02-20 | Charles Schwab & Co., Inc. | Memory pooling in high-performance network messaging architecture |
US20240248753A1 (en) * | 2023-01-20 | 2024-07-25 | Arm Limited | Locating data in storage |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6009432A (en) * | 1998-07-08 | 1999-12-28 | Required Technologies, Inc. | Value-instance-connectivity computer-implemented database |
CN101311930A (zh) * | 2007-05-21 | 2008-11-26 | Sap股份公司 | 具有重复值的表的块压缩 |
US20110246425A1 (en) * | 2010-03-30 | 2011-10-06 | Sybase, Inc. | Managing Data Backup of an In-Memory Database in a Database Management System |
CN103078646A (zh) * | 2012-12-31 | 2013-05-01 | 上海宇芯科技有限公司 | 字典查询压缩、解压缩方法及其装置 |
Family Cites Families (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB1332631A (en) | 1971-02-26 | 1973-10-03 | Ibm | Data processing system |
SE8307228D0 (sv) | 1983-12-30 | 1983-12-30 | Grundstenen 16808 Ab | Datakomprimering |
US5544347A (en) | 1990-09-24 | 1996-08-06 | Emc Corporation | Data storage system controlled remote data mirroring with respectively maintained data indices |
US5442350A (en) * | 1992-10-29 | 1995-08-15 | International Business Machines Corporation | Method and means providing static dictionary structures for compressing character data and expanding compressed data |
US5610603A (en) * | 1995-09-28 | 1997-03-11 | International Business Machines Corporation | Sort order preservation method used with a static compression dictionary having consecutively numbered children of a parent |
US5778430A (en) | 1996-04-19 | 1998-07-07 | Eccs, Inc. | Method and apparatus for computer disk cache management |
US7026962B1 (en) * | 2000-07-27 | 2006-04-11 | Motorola, Inc | Text compression method and apparatus |
US20030217025A1 (en) * | 2000-09-11 | 2003-11-20 | David Costantino | Textual data storage system and method |
US20050022123A1 (en) * | 2001-06-04 | 2005-01-27 | David Costantino | Textual data storage method |
US6670897B1 (en) * | 2002-10-03 | 2003-12-30 | Motorola, Inc. | Compression/decompression techniques based on tokens and Huffman coding |
US7412541B1 (en) * | 2003-07-18 | 2008-08-12 | Core Mobility, Inc. | Tokenized compression of session initiation protocol data |
US7555497B2 (en) | 2003-08-21 | 2009-06-30 | Microsoft Corporation | Systems and methods for separating units of information manageable by a hardware/software interface system from their physical organization |
US7430553B2 (en) | 2005-12-30 | 2008-09-30 | Microsoft Corporation | Managing states with delta pager |
US20080059492A1 (en) | 2006-08-31 | 2008-03-06 | Tarin Stephen A | Systems, methods, and storage structures for cached databases |
US8671076B2 (en) | 2007-05-08 | 2014-03-11 | Bmc Software, Inc. | Database recovery using logs applied to consistent copies |
US8782075B2 (en) | 2007-05-08 | 2014-07-15 | Paraccel Llc | Query handling in databases with replicated data |
US10152504B2 (en) | 2009-03-11 | 2018-12-11 | Actian Netherlands B.V. | Column-store database architecture utilizing positional delta tree update system and methods |
US8401996B2 (en) | 2009-03-30 | 2013-03-19 | Commvault Systems, Inc. | Storing a variable number of instances of data objects |
US8583692B2 (en) | 2009-04-30 | 2013-11-12 | Oracle International Corporation | DDL and DML support for hybrid columnar compressed tables |
US8868510B2 (en) | 2009-12-03 | 2014-10-21 | Sybase, Inc. | Managing data storage as an in-memory database in a database management system |
US8880508B2 (en) | 2010-12-30 | 2014-11-04 | Sap Se | Processing database queries using format conversion |
US20120323971A1 (en) | 2011-06-14 | 2012-12-20 | Sybase, Inc. | Optimizing data storage and access of an in-memory database |
US8918436B2 (en) | 2011-12-22 | 2014-12-23 | Sap Ag | Hybrid database table stored as both row and column store |
US20140040218A1 (en) | 2012-07-31 | 2014-02-06 | Hideaki Kimura | Methods and systems for an intent lock engine |
US20140075493A1 (en) | 2012-09-12 | 2014-03-13 | Avaya, Inc. | System and method for location-based protection of mobile data |
US9430390B2 (en) | 2013-09-21 | 2016-08-30 | Oracle International Corporation | Core in-memory space and object management architecture in a traditional RDBMS supporting DW and OLTP applications |
US9292564B2 (en) | 2013-09-21 | 2016-03-22 | Oracle International Corporation | Mirroring, in memory, data from disk to improve query performance |
US9128972B2 (en) | 2013-09-21 | 2015-09-08 | Oracle International Corporation | Multi-version concurrency control on in-memory snapshot store of oracle in-memory database |
US9697221B2 (en) * | 2014-03-19 | 2017-07-04 | Oracle International Corporation | OZIP compression and decompression |
-
2014
- 2014-07-21 US US14/337,113 patent/US9697221B2/en active Active
-
2015
- 2015-03-16 EP EP15716907.9A patent/EP3120266B1/en active Active
- 2015-03-16 CN CN201580020897.7A patent/CN106233632B/zh active Active
- 2015-03-16 WO PCT/US2015/020792 patent/WO2015142749A1/en active Application Filing
-
2017
- 2017-06-30 US US15/640,286 patent/US10437781B2/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6009432A (en) * | 1998-07-08 | 1999-12-28 | Required Technologies, Inc. | Value-instance-connectivity computer-implemented database |
CN101311930A (zh) * | 2007-05-21 | 2008-11-26 | Sap股份公司 | 具有重复值的表的块压缩 |
US20110246425A1 (en) * | 2010-03-30 | 2011-10-06 | Sybase, Inc. | Managing Data Backup of an In-Memory Database in a Database Management System |
CN103078646A (zh) * | 2012-12-31 | 2013-05-01 | 上海宇芯科技有限公司 | 字典查询压缩、解压缩方法及其装置 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110662061A (zh) * | 2018-06-29 | 2020-01-07 | 想象技术有限公司 | 有保证的数据压缩 |
US12034934B2 (en) | 2018-06-29 | 2024-07-09 | Imagination Technologies Limited | Guaranteed data compression |
US12170534B2 (en) | 2018-06-29 | 2024-12-17 | Imagination Technologies Limited | Guaranteed data compression using reduced bit depth data |
Also Published As
Publication number | Publication date |
---|---|
WO2015142749A1 (en) | 2015-09-24 |
EP3120266A1 (en) | 2017-01-25 |
US10437781B2 (en) | 2019-10-08 |
US9697221B2 (en) | 2017-07-04 |
US20170300510A1 (en) | 2017-10-19 |
US20150269180A1 (en) | 2015-09-24 |
CN106233632B (zh) | 2019-08-06 |
EP3120266B1 (en) | 2022-09-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106233632A (zh) | Ozip压缩和解压缩 | |
US11567901B2 (en) | Reduction of data stored on a block processing storage system | |
US8572131B2 (en) | Techniques for more efficient usage of memory-to-CPU bandwidth | |
CN104380267B (zh) | 数据解压/压缩装置 | |
US10972125B2 (en) | Storage access interface to an encoded storage system | |
CN104283567A (zh) | 一种名称数据的压缩、解压缩方法及设备 | |
CN101894115A (zh) | 电子文档的图像数据处理方法及其装置 | |
US12149266B2 (en) | Exploiting locality of prime data for efficient retrieval of data that has been losslessly reduced using a prime data sieve | |
TW201627890A (zh) | 多層搜尋引擎索引 | |
JP2020518207A (ja) | 基本データシーブの使用によるデータの無損失削減、ならびに基本データシーブを使用して無損失削減されたデータに対する多次元検索およびコンテンツ連想的な取出しの実行 | |
US9665590B2 (en) | Bitmap compression for fast searches and updates | |
EP3387647B1 (en) | Reduction of audio data and data stored on a block processing storage system | |
US20220066994A1 (en) | Efficient retrieval of data that has been losslessly reduced using a prime data sieve |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | 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 |