A computational model for analytic column stores
Eyal Rozenberg
TL;DR
This paper introduces an abstract computational model for analytic column stores based on circuits that process columns, enabling better optimization, parallelization, and analysis of columnar query processing architectures.
Contribution
It presents a unified, expressive model for column store computations using circuits, facilitating optimization and analysis without significant out-of-plan data.
Findings
Model captures architectural features of existing column stores
Enables extensive optimization of query processing
Supports massive parallelization on modern hardware
Abstract
This work presents an abstract model for the computations performed by analytic column stores or columnar query processors. The model is based on circuits whose wires carry columns rather than scalar values, and whose nodes apply operators with column inputs and outputs. This model allows expression of most of the architectural features of existing column-store DBMSes through columnar execution plans, rather than such features being implemented sui-generis, and without the column store maintaining significant out-of-plan data. A strict adherence to columnarity allows for a relatively simple and robust model; enabling extensive and intensive optimization of almost all aspects of query processing; and also enabling massive uniform parallelization of query process on modern hardware. Moreover, the computational model's expressivity makes it useful also as an \emph{analytical} tool for…
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
Taxonomy
TopicsAlgorithms and Data Compression · Advanced Data Storage Technologies · Parallel Computing and Optimization Techniques
\reserveinserts
28 \WarningFilterlatexYou have requested package ‘include/
\WithSuffix[1] [#1]
\newabbrev\xthth \newabbrev\xrdrd \newabbrev\xstst \newabbrev\xndnd \newabbrev\etcetc. \newabbrev\cfcf.
\newabbrev\WhpWith high probability
\WithSuffix[2]#1{#2}
\WithSuffix[1][]
\WithSuffix[1][]
\newaliascntcorollary@alttheorem
\newaliascntproposition@altlemma
\newaliascntclaim@altlemma
\newaliascntdefinition@altlemma
\newaliascntobservation@altlemma
\newaliascntnumbered-example@altlemma
\newaliascntfact@altlemma
\newaliascntassumption@altlemma
\newaliascntquestion@altlemma
\newaliascntconjecture@altlemma
\newaliascnthypothesis@altlemma
\WarningFilterfixltx2efixltx2e is not required \WarningFilterlatexYou have requested the package
[name=operators,title=Index of computational operators,intoc=true] [name=schemes,title=Index of representation and compression schemes,intoc=true] \indexsetupnoclearpage
Table of contents
-
3.2.1 Elementwise composition and “noise-signal”-like separation
-
3.6 Further compression of scheme-generated auxiliary columns
-
4.1 Avoiding materializations: Operator fusion via JIT compilation
-
4.2 The choice of compression schemes as a nexus of preprocessing effort
Introduction
Why bother spending time on formalizing a model of computation for columnar data processing systems? Column stores have, after all, already become well-established and widely-used. Isn’t this pursuit several decades too late, and thus mostly irrelevant?
It is the author’s belief that nothing could be further from the truth, and that the dearth of theoretical underpinnings is an obstacle to the progress of more practical research into column stores or columnar DBMSes and their further acceleration. The reason for this, in a nutshell, is that column stores designers have failed to realize and exploit the full potential of the column as a fundamental concept and focus of computation. A formal model of computation would:
- •
make the plethora of architectural features column stores typically support [ABH*+*13, §1] be taken care of as integral parts of the execution of a plan, without special treatment by feature-specific code. Consequently,
- •
bring as much of a column store’s computational work when processing a query into the sphere of consideration and influence by execution plan optimization phases.
- •
facilitate the conception and specification of a rich space of composite compression schemes, fully and seamlessly integrated into execution plans.
- •
form a basis for a further theoretical endeavor: A grammatic formalism for execution plan transformation/optimization rules — rather than such rules constituting mostly ad-hoc unconstrained code.
- •
inspire a more streamlined, flexible architecture for future column store software systems, especially those focused on emerging parallel-execution hardware, lending itself to better utilization of their capabilities as well as easier extensibility.
The non-history of column store models of computation
It is somewhat peculiar that research into column stores has not produced any formal models of computation long ago already. An (essentially) columnar storage model for DBMSes was proposed as such already in 1985, in the form of the Decomposition Storage Model (DSM) [CK85]; columnar file storage format (“transposed files”) was suggested even earlier, in [Bat79]; and work in which a columnar model is implicit goes as far back as half a century ago, to the late 1960s [EB69]. Columnar DBMSes as full-fledged products have also long been available: KDB and Sybase IQ [Fre97] were released in the 1990s; MonetDB [Bon02] and C/̄Store [SAB*+*05] were made availble in the 2000s as free software — the former is in active development under a free license even today. In fact, by the time of writing, all major commercial DBMSes which consider analytics to be a use-case sport columnarity in some form or another — even if only as an auxiliary index for a row store: See [ABH*+*13, §2.2, §3.3] for the state of affairs as of 2013, which has since progressed further with systems by Amazon [GAT*+*15], Microsoft [LBH*+*15], Oracle [LCC*+*15] and so on. But these advances in practice have not manifested themselves in theoretical research; that is still wholly dominated by efforts inspired by, and geared towards, row-oriented DBMSes, unordered relations, and/or transactional work. The author was unable to find a single paper evaluating the models of computation — formal or informal — used by the prominent column stores of recent years.
The more abstract fields of the theory of computation generally, and parallel computation theory particularly, also offer no panacea in terms of a relevant model. The closest models of computation formalized and studied in the literature (see, e.g., [Sav98, Chapter II] for a textbook overview and [KSS18] for a recent and more domain-specific publication) seem to fall into one of the following categories:
A network of many computing nodes, acting independently and communicating with each other, where the parallelism is expressed by multiple nodes working on potentially different elements of a column/array). 2. 2.
A data-parallel computer, supporting complex control flows, exhibiting either SIMD (Single-instruction multiple-data) or SPMD (Single-program, multiple-data) behavior. 3. 3.
Circuits / circuit families, carrying scalar values on the wires, using a small fixed set of very-simple operator nodes (boolean algebra, or arithmetic operations on rational numbers). Parallelism may expressed by multiple nodes processing multiple elements of the input (in our case, the column).
The network abstraction of the first category is not useful for us to adopt: Networking may be a significant part of implementing a system as it scales, but the parallelism does not inherently depend on this network structure, nor is the parallel nature based on it. The second model is too powerful for our use: Allowing loops and such control structures would make it rather non-meaningful to distinguish between individual operators and execution plans more generally. Finally, the circuit model, in itself, does not express the concept of the column, or of the processing of an entire column at once. What we would be after is some kind of middle-ground between the two last options, as we shall elaborate in this monograph.
Yet another subfield of computer science in which we find some context for our desired model of computation is that of programming languages. Several languages have been devised over the years intended to manipulate arrays as fundamental types; and some of these involve “dataflow graphs” in one form or another (e.g. [FCO90]). Unfortunately, the author is not well-versed in the scholarly work in this subfield enough to authoritatively draw on such work; but it would seem previous research efforts have not fleshed out or formalized a proper model of computation which one may adapt for use with column stores. Some inspiration can be drawn from the the monadic and diadic operators of the APL language [Ive62], formalized with vector and matrix arguments in mind (as per the relatively late but more comprehensive set of definitions in [Mic]).
Finally, the reader should bear in mind that existing column stores do not actually share a single identical model of computation or common set of structural features it relates to. Differences can be quite significant: Proper-DSM-based column stores couple each column of data with a keying column relating it to the rest of its table; while others operates on tuples in multi-column projections. Or, taking another aspect of the model, some column stores support execution plans with strictly acyclic dependencies between operators — circuit or DAG-like plans; others allow full-fledged imperative programming, with loops and all (even if these are rarely used in practice).
What existing column stores have left out
Typically (if not universally),the columns appearing a column store’s execution plan are those found in a database schema — columns within tables to which users can make queries — and intermediate results of operators within the plan. A wealth of auxiliary data is kept separate from the execution plans: NULL indication; column statistics; index structures; partitioning, sharding or cracking information, and more yet. The column store code involving this auxiliary data is not reflected in the execution plans, but rather hard-coded to apply in certain cases and in certain ways. Also, such data is held in structures of idiosyncratic design; and while they might be well-designed for their specific function, they are not themselves columnar — another reason for their necessitating out-of-plan code.
Whatever is done outside of an execution plan cannot benefit from repatedly-applied and contextually-applied plan optimizations and transformations; it can also hardly benefit, if at all, from the use of just-in-time compilation. Also, such idiosyncratic use of auxiliary data may impose constraints on the actual plan, such as additional materialization points of intermediate results, or less flexibility in scheduling.
Compression, data layout, and ‘pushed-down’ execution
Recently, the author was working on implementing lightweight decompression on a GPU. True to the principle mentioned above, several well-known schemes — Dictionary, FrameOfReference and so on — were concretized using distinct, fixed-width-type columns in memory. As implemention progressed, it turned out that large parts of the code were used by more than one scheme; and that operators originally written for executing queries on uncompressed data were being used as-is in decompression.
These occurrences in practice naturally induce two theoretical questions:
- •
Perhaps it would be useful to decompose compression schemes into simpler transformations (which do not, individually, decompress anything), and consider them separately as well as in combination?
- •
Is there really a distinction between the computational operators we employ during query execution “proper”, and the computational work performed for decompression?
The potential for composition of compression schemes, as opposed to their decomposition is rather obvious, both to a query processing engine designer as we as to the end user. For example, if we have a time series with points at intervals whose lengths only have few possible values, then an effective compression scheme could be: Storing the differences between samples rather than the values (Delta compression), and using less bits for the differences (NullSuppression), or perhaps storing indices into a dictionary of possible interval lengths (Dict).
The decomposition of compression schemes becomes useful mostly in the larger context of executing an actual query, when we can sometimes avoid some of the decompression work, and act on a partially-decompressed form, or on partial data. Let us take the previous example of time-series data: Suppose we wish to perform some aggregation on a feature of events in the time-series which occur after long intervals. In this case, we would like to be able to skip the reconstitution of timestamps from differences, followed by taking differences again to filter out the irrelevant data. But to do so, we must be able to do away with the Delta decompression of the composite scheme.
Existing column stores supporting compressed data do not support composition or decomposition of compression schemes (e.g. Vectorwise [ZHNB06] and C/̄Store/Vertica [LFV*+*12]); and the same seems to be true for high-performance row-stores (e.g. HyPerDB [Neu11, LMF*+*16]). Some of them do have a few useful composite schemes baked-in; and some have some scan functionality ‘pushed-down’ to operate on the compressed data as it is being decompressed. But the use of each of these is idiosyncratic; and query-specific optimizations and work-avoidance be applied. Specifically, the two examples given above cannot be realized these systems.
Structure of this monograph
This work progressively presents concepts, constructs, definitions, based on previously-exposited ones; but as far as motivation is concerned, the document’s direction is mostly in reverse. We thus begins with the formulation of a model of computation (Chapter 1 with rather limited justification for the choices of its specifics; we continue with an exploration of the expressivity of combinatorial structures within the model of computation, as columns (Chapter 2; it is only then that we “apply” these representation schemes, in formulating common and less-common compression schemes in columnar terms (Chapter 3). A final chapter Chapter 4, prospectively sketches out aspects of the possible design of an analytic column store implementing the model of computation fully and directly.
Acknowledgements
Part of the work on this monograph was conducted while the author was a post-doctoral researcher at CWI Amsterdam (https://www.cwi.nl), in the Database Architectures group; the author wishes to thank all group members, and the group’s founder, Prof. Emeritus Dr. Martin Kersten, for an enlightening stay. The author particularly wishes to thank Prof. Dr. Peter Boncz, for his guidance and insights during that time. Finally, the author wishes to thank Profs. Drs. Boncz and Urbani , as well as Aris Koning of MonetDB Solutions B.V., for useful discussion and comments on earlier versions of this work.
Chapter 1 A model for columnar computation
In this chapter we formalize a model of the computations performed by column stores. In more concrete terms, we extend the folklore model of computation of combinatorial boolean logic circuits to columns.
A boolean logic circuit consists of nodes, or vertices, which are logic gates, such as And or Not; and of directed edges, corresponding to physical wires between logic gate outputs and inputs, each “carrying” a one-bit (scalar) value. The vertices and edges form a DAG (directed acyclic graph). Circuit inputs are conceputalized as wires with only their destination attached to gate input, while outputs are wires with only their source attached to a gate output. The function computed by a circuit is computed inductively, starting from an assignment of a sequence of bits to the inputs, and propagated through the vertices to deeper and deeper internal edges — until the final gate or gates which compute the circuit’s outputs — in correspondence to how setting 0/1 values on the input wire propagates through the physical nodes over the wire, eventually setting the output wire charges. We will not restate any of this formally; the reader may consult a detailed textbook treatment in [KJ10].
In the context of a column store, with most activity being (ideally) uniform over large columns, instead of forming gigantic circuits with single-bit or single-scalar-value edges, we instead have each input, and each edge, carry a column with elements of some data type. This is where the similarity between the model we formalize and circuits reaches its end, both in the technical details of the definition and with respect to the richness and expressivity of the model.
Notational conventions
In the following, denote the image, domain and range, respectively, of a function . Composition of functions is denoted where . The natural numbers, are considered to include 0. All combinatorial structures we define are finite unless otherwise stated. Diagrams presenting two-dimensional arrays are column-major unless otherwise stated or indicated by element indices. We shall refer to “types” in the sense of programming language type systems: Types have domains — sets of possible values; they have a representation in physical computer memory; and they have associated operators, which may be applied to values in their domains. We’ll assume a fixed set of allowed types, which includes various integers and floating-point types with representations of fixed sizes in bits. This set of types will specifically include , an integer type large enough to represent the indices of the column being considered; as well as , the unit type (with a single possible value); and , is a type with an empty domain (having no values). When we refer to “any type” or to an “arbitrary type” — this is with respect to the global set of allowed types (which will will otherwise not be concerned with).
Model building blocks
Columns
We begin with a choice of a column store’s fundamental, most basic, data structure:
Definition \thedefinition@alt (Column).
A (plain) column is a function for some fixed-representation-size type and . is the column’s length (denoted ), is its element type and the size of ’s physical representation is the column’s width.
A column may be empty in case is 0, or it may interpreted as a scalar, a single value of type , for the case of . Both cases are valid, though the latter will be explicitly useful in this work, while the former will be mostly ignored. The set of all columns of element type is denoted .
Our definition of a column is not entirely concrete: It does not specify a particular physical layout for column data. In our model of computation, columns will in fact have multiple possible physical layouts, developed at length in subsequent chapters. Still, as a concrete starting point, we choose a default physical layout in which columns manifest: The standard representation of a column is the sequence of its evaluations over its domain, by the natural order of integers, i.e. . While also defined abstractly, this representation translates immediately into the physical world — a sequence of values in a computer’s memory.
In this work we often conflate columns in the abstract with their standard representation. Also, in light of this physical expression, this work uses the array subscripting syntax of C-like programming languages to denote column elements, e.g. for some , denotes , the function c applied to .
Definition \thedefinition@alt (Element frequency distribution / probability mass function).
Let c be a column of element type . The (element) frequency distribution or frequency function of c is the function counting -value appearances in col, i.e. . Normalizing this function by , we obtain the probability mass function for the uniform distribution over the elements of c.
Now, the support of (i.e. ) is of significance — the set of all values appearing in c — while the support of c as a function is simply regardless of the column’s contents. Thus, abusing notation, we refer to the support of as “the support of column c”, denoting it .
Circuit nodes: Computational operators
In a boolean logic circuit, and with nodes limited to zero, one or two inputs and one output, there can be no more than possible kinds of nodes. In fact, only a small subset of them is necessary to define the model of computation, since each of the functions can be computed using a small gadget-circuit using only the small subset: Just And, Or, and Not suffice, or even just Nand or Nor, alone [KJ10, §3.2]. The situation is entirely different when circuit node inputs are columns — the variety of computational operators becomes infinite. We do not, therefore , limit our discussion to some fixed set of operators, and instead consider arbitrary operators inspecifically. A column store system may limit its operators to a finite set, or support defining them dynamically (as many DBMSes, including column stores, do).
Definition \thedefinition@alt (Signature).
A (single-direction) computational signature is a tuple : A set of labels, and a family of types corresponding to each of them. A bidirectional/in-out computational signature is a pair of an input and an output single-direction signatures, with disjoint sets of labels.
For an in-out signature , we denote for and for and similarly and . When some entity has an associated (in-out) signature , we denote and similarly for output labels and for types. Finally, we occasionally assume an implicit order on sets.
Definition \thedefinition@alt (Operator).
A computational operator is a tuple comprising some computational automaton with finite description and a corresponding signature . Omitting details, the automaton — a deterministic Turing machine [Sip12, §3.1] unless otherwise specified — takes as input the standard representations of columns of types , and if it halts, produces the standard representations of columns of types .
We will abuse this definition by referring to operators performing the “same” computation for different input types, as though they were the exact same operator (e.g. elementwise addition and multiplication, defined for multiple possible column element types).
For an operator Op, we denote by the partial function computed by Op: A partial function from (a subset of) to . We denote by the output column of with label (the projection of the output on , if you will). If Op has a single output labeled , we may conflate with . The arity of is also referred to as the arity of Op itself.
As the first few examples of actual computational operators, suppose we wish to have the “same” logic operators of traditional circuits in columnar circuits as well — by having them apply to multiple tuple of inputs, elementwise. Choosing And as an example, we define the following example operator:
*[ElementwiseAnd]
[TABLE]
The output satisfies .
The and signatures of this operator are the labels and types on the lines marked “Input” and “Output” above, respectively. As for the length designations, these are actually a constraint on the lengths for which the operator produces an output — as, unlike in boolean circuits, operators are partial rather than complete functions. In this case, ElementwiseAnd will only produce output for pairs of input columns having the same length.
Note*.*
In practice, storing bits often involves issue such as machine byte-alignment. We do not account for alignment issues in this text, except to note that they can be overcome using mechanisms developed in Chapter 2 below.
Our example elementwise operator immediately generalizes to any function with and :
*[Elementwise_f]
[TABLE]
Letting and , the output satisfies for all . When (or, respectively, , the single argument (respectively, result) column is referred to as arguments (respectively, results), dropping the index. (When is a unary function, one can think of this as the higher-order function applied to .)
this kind of elementwise operators will be put to considerable use throughout this monograph.
We present two additional examples of simple operator on columns, with forethought of a columnar computation example later on, in 1.2 and 1.3.
Replicate
[TABLE]
Produces a column with the uniform value value at each index .
Select
[TABLE]
Keeps only those elements of a column which are “selected” by a true value in a selection column. Note that this operator has two variants: One which maintains the relative order of elements in selected as in data, and a more relaxed variant in which any permutation of the selected elements is a valid output; the difference is quite significant for parallel implementations.
In the description of this operator we’ve used value and factor as scalars rather than columns; this should be interpreted as a use of and — the single values in these length-1 column.
Side note: On the strength of circuit operators
The choice of Turing machines for Subsection 1.1.2 above is motivated by actual column stores our model of computation abstracts from — principally MonetDB [IGN*+*12], C/̄Store [SAB*+*05] and Vectorwise [ZB12]: Most column stores can and do run user-defined functions (UDFs) in one or more high-level language; and these functions may well be Turing-complete. Even if one only considers the operators built-in to the column store — they may involve arbitrary code, and are not restricted apriori in their complexity.
On the other hand, in a typical column store (including the abovementioned ones), UDFs are used sparingly if at all (depending on the application domain); and most of the built-in operators, require no more time for length- inputs-plus-outputs, and space. Even the more involved built-in operators are not terribly complex (e.g. time for a Join in the most unforgiving figuring). Furthermore — and recalling our model of computation being formalized with a mind to enable parallelization and distribution of computation — we expect most (not all) operators to fall into an even weaker complexity class: Computations which may be extremely-effectively paralellized to machines, or cores, or threads. Even [AB09, §6.7.1] would be far too much. Without delving into details, these should have constant parallel running time and be decomposable to very small fixed-size traditional (non-columnar) circuits. This requirement is similar to the “pipelinability” property of operators defined by HyperDB [Neu11], but not quite identical, as may become apparent to a careful of subsequent sections and chapters. Further discussion of this point is beyond the scope of this monograph.
Circuit layout: Port graphs
Next, a combinatorial structure for our circuits. Boolean logic circuits could make do with a directed (acyclic) graph, as the Or and And binary operators are symmetric, so there is no need to distinguish between their two inputs; and the edge directionality distinguishes inputs from outputs. For operators on columns (and even for asymmetric operators on scalars), inputs are not interchangeable (and neither are outputs). Thus, if we think of them as vertices in a DAG, each such vertex must have different ‘ports’ which edges start from or arrive at. This inspires the following definition.
Definition \thedefinition@alt (Port graph).
A (simple) directed port graph (or (simple) port digraph for short) is a tuple of vertices , per-vertex port label sets and edges , such that:
- •
is a family of per-vertex port label sets: .
- •
The edges in connect ports (i.e vertex-label tuples) rather than vertices. In other words: Denoting the ports of each vertex by , and the overall port set of by — we have .
Non-simple port digraphs and undirected port graphs are defined similarly, mutatis mutandis.
A port in a port digraph is said to be engaged if it is an endpoint of an edge in (and disengaged otherwise); if the origin port of its engaging edge is , is said to be engaged by . Two vertices in a port digraph are said to be (directly) connected if the graph has an edge between a port of and a port of . A port is said to be reachable from port if there is a path of edges beginning at and ending at ; reachability from a vertex means port reachability from any of its ports; the reachability of a vertex means port reachability of any of its ports.
Definition \thedefinition@alt (Induced sub-port-digraph).
Let be port digraph with . The subgraph of induced by is the port graph {{G}{\big{|}}_{V^{\prime}}}={\left({V^{\prime},\Lambda^{\prime},E^{\prime}}\right)} where \Lambda^{\prime}={{\Lambda}{\big{|}}_{V^{\prime}}} and .
We denote by (respectively, ) the input (respectively output) degree of port in a port graph . The input (respectively output) degree (respectively ) of a vertex in a port graph is the sum of all of its ports input (respectively output) degrees. For a pair of port sets , denotes the number of edges from ports in the first set to ports in the second; and for a pair of vertex sets , denotes .
Generally, a port graph vertex can have edges coming in and going out via the same port. As the ports are a method of qualifying incoming and outgoing edges, it makes sense to consider those cases in which a given port, a given label, may only be associated with one direction — either incoming or outgoing. More formally, same port in a port graph can have edges coming in and going out
Definition \thedefinition@alt (Port orientation).
Let be a port digraph. A partition of ’s ports is an orientation (w.r.t. ) if ’s edges only connect ports in to ports in . If is port graph for which such a partition exists, it is said to have orientable ports.
In conclusion of this section, bear in mind that the port (di)graph is an abstraction of mere convenience. One could very well ‘encode’ ports as gadgets within a single binary relation, either more trivially with an auxiliary unary relation, or with some gadgetry and higher overhead in graph size, but no auxiliary relations — all using trivial model-theoretical techniques. It would also be possible to have labels as special vertices, and use oriented 4-uniform hyperedges with two regular vertices and two port labels. Our choice is geared towards the definition of circuits, below, since we’ll want to maintain the mental picture of a physical circuit layout, where a graph edge is a physical wire, a graph vertex is a component placed on a PCB (printed circuit board), and a port is one of the holes into which a components’ pins fit.
Columnar circuits
We have already indicated columnar circuits are to be similar to boolean logic circuits, except for having columns instead of bits on the wires. Still, the orientation of the edges will necessitate a proper definition, somewhat more rigorous and verbose. Before presenting it, however, let us consider example circuit, Figure 1.3: It counterposes a program-listing-style execution plan (with syntax and structure similar to those used in MonetDB) to a columnar circuit for processing the same query. The program-listing-style plan cannot itself be the equivalent of a circuit, as its instructions/operators are in a total order, while in the circuit there is merely a partial order imposed by the data dependencies. One may thus think of the circuit as being counterposed to the equivalence class of all reorderings of the program-listing-style plan, in which instructions only use variables computed in previous instructions.
Not every port digraph can serve as the underlying structure of a columnar circuit. A port digraph is said to have circuit layout w.r.t. a partition of its ports if is acyclic, is a port orientation for (as per Subsection 1.1.3), and no port of is the target of more than one edge (i.e. ). If, given a port digraph, such a partition exists, is said to admit circuit layout if there exists a partition with respect to which it has circuit layout. (If it seems odd that a graph in “circuit layout” cannot actually have circuits, i.e. cycles — recall that boolean logic circuits are also acyclic and not literally circuits; it’s the electricity driving their operator physically that runs in circuits).
A last stepping-stone before finally defining a columnar circuit is the induction of the ports. Indeed, given a finite set , a function op from into some set of available operators would induce a family of input and of output ports for each element of :
[TABLE]
and with these two defined, we denote by their elementwise union, i.e. are all the induced ports for each vertex. This completes the machinery necessary for:
Definition \thedefinition@alt (Columnar circuit).
A tuple — a computational signature (as per Subsection 1.1.2), a set of vertices , a mapping of vertices to operators op (which induces the ports of each vertex), a set of edges , and an “interface mapping” of circuit signature labels to ports — constitutes a columnar circuit if the following hold:
The tuple constitutes a port digraph — the layout graph or structure graph of . 2. 2.
The structure graph has circuit layout with port orientation . 3. 3.
Edges only connect ports with the same associated element type, i.e. if then . 4. 4.
The interface maps of the circuit input ports to disengaged vertex input ports, and every disengaged input port has exactly one circuit input port mapped to it; in other words, {{\pi}{\big{|}}_{\sigma_{\text{in}}}} is a bijection between and the disengaged input ports of . 5. 5.
The interface maps circuit output labels to output ports in .
Note*.*
This definition does not support “pass-through” wires in a circuit, connecting an input to an output directly with no operator used; without a pass-through capability, circuits may require the use of an idempotent (Elementwise-identity-applying) operator to achieve the same functionality — relaying its input to its output. Similarly, unused input ports are not supported, but could be simulated using NoOp nodes (essentially, Elementwise with the unary identity function): If a circuit input is mapped by to the input of one of these, it can be considered unused.
Definition \thedefinition@alt (Circuit input and output ports).
The input ports of a computational circuit is the set ; as per the constraint above, these are exactly all disengaged ports in . The output ports of are .
We come now to the central definition of our model of computation, relating the combinatorial objects to computed functions:
Definition \thedefinition@alt (Circuit-computed function).
Let be a columnar circuit let with corresponding operator and input arity (which may be 0) and let . We now inductively define a family of functions, , each taking input variables (the circuit ’s overall inputs); our definition is inductive:
[TABLE]
In other words: The inputs are cascaded through the columnar circuit, just like in a boolean logic circuit; nodes (operators) apply their associated function to their inputs, and the resulting outputs are “carried” by wires on to input ports of subsequent nodes.
Finally, The function computed by , denoted , is .
To make the above definition more concrete, let us work out the function computed by a specific circuit: The one appearing in Figure 1.4. For brevity, we use EA, EM, R, L, S2 and S3 in the following instead of (Elementwise add), (Elementwise multiply), Replicate, Length, Scalar 2 and Scalar 3 respectively, and the column names res and val instead of result and value.
[TABLE]
this functions computed on each port are also noted in Figure 1.4 itself.
An implementation of the model of computation we’ve defined is a system (a program, a machine or a multi-node cluster of machines) which, given a columnar circuit and an assignment to its variables, evaluates as in the above example, on its entire domain, i.e. materializes the columns produced by circuit when provided with columns as assignments to its inputs.
Definition \thedefinition@alt (Decision circuit).
A (columnar) decision circuit is a columnar circuit with a single output type , whose output column never has length other than 1 (i.e. ). A decision circuit is said to accept input columns if , and to reject the input if . If is a complete function (accepting or rejecting every input), is said to be a complete decision circuit.
Side note: Circuits vs instruction sequences
The circuit model is the more fitting characterization of the kind of computation column stores execute, as there is no ordering among the vertices except through their data dependencies. Instruction sequences, the much more commonly used formalism for specifying computations, are ordered; and are also amenable to control flow denotations such as loops, conditionals and jumps — none of which are supported by the model of computation we have presented. This being said, in sequential, non-vectorized/columnar execution of programs, out-of-order execution which does not interfere with data dependencies is common practice. And we could just constrain instructions to merely Single-Static-Assignment applications of columnar operators, defining a program to be an equivalence class of instruction sequences under permutations ensuring that all instructions producing the inputs of an operator application appear before this application.
Circuit composition and transformation
A traditional boolean circuits is not typically generated from scratch, but rather composed of subcircuits, computing simpler functions. The same should be the case with columnar circuits as well, for column store constructing execution plans. Such plans undergo repeated transformations after their initial generation — involving removal, addition and replacement of individual operators and entire subplans. This section presents some formal machinery for applying such transformations to columnar circuits. We will also be making extensive use of them for further conceptualization work in later chapters.
Definition \thedefinition@alt (circuit union).
Let , be two circuit, and assume , are disjoint, as are and ). The (disjoint) union, or union circuit, of and is the circuit where
[TABLE]
For the case of non-disjoint vertex or signature label sets, one may differentiate them by applying for one circuit and for the other.
If we order the input and output labels of circuits and , the latter after the former, their union can also be thought of as a concatenation: It takes a concatenation of inputs to each of them and produces a concatenation of outputs from each of them (when the outputs are defined, of course).
Definition \thedefinition@alt (Circuit input assignment).
Let be a columnar circuit whose signature contains the label , let be the vertex input port to which is mapped in , and let be a vertex output port within , with the same associated element type as . The circuit resulting from the assignment of vertex output to input in , or the assignment of the output of to the input in is the circuit where
[TABLE]
The above definition is “intra-circuit”; but one may wish to engage a circuit’s input with the output of another circuit, rather than another vertex in the same circuit. This can be done by reducing the inter-circuit case to the intra-circuit case by taking the union circuit of the two circuits to be connected.
Definition \thedefinition@alt (Induced subcircuit).
Let be columnar circuit and let (with ). The subcircuit of induced by is a circuit with the layout of the sub-port-graph of induced by , the ports of mapped to by ), plus an artificial circuit port for every port of a vertex whose connection from/to is broken by taking the induced subgraph. We label these new artifical circuit ports using the ports to which they had been connected, assuming without loss of generality that these labels will be disjoint from . More formally, the induced subcircuit, denoted {{C}{\big{|}}_{V^{\prime}}} is the tuple with
[TABLE]
Induced subcircuit replacement
Let be columnar circuit, let (and let ) and let be a replacement circuit for subcircuit {{C}{\big{|}}_{V^{\prime}}}. The replacement of {{C}{\big{|}}_{V^{\prime}}} with in can be thought of in the same terms as replacing, say, an audio extension card in a personal computer, physically: The card has a line in and line out ports — part of the computer case’s overall ports facing the outside world — and the replacement card’s similar ports replace those. Additionally, the card has a a sequence of specifically-positioned metal strips which fit into the computer’s motherboard — its internal connections to rest of the computer system: While a card is connected these are irrelevant, or unexposed; when we disconnect the old card these spring into effective existence, and the new card must match these connections in order to physically fit in to the system.
More formally, let {\rho\,:\,P\left(C_{r}\right)\setminus P\left(C\right)\!\rightarrow P\left({{C}{\big{|}}_{V^{\prime}}}\right)\setminus P\left(C\right)} be a bijection between the intra- ports of the replaced and replacement circuits. The circuit , resulting from the replacement, is defined by
[TABLE]
We have taken some pains to formally define this transformation of columnar circuits, due to its relevance to execution plan optimization in column stores; it is a general form of the key step in a typical plan execution optimizations in a column store: Find a subplan which is amenable to improvement; then replace it with with a more useful subplan.
Operator lifting
A special case of induced subcircuit replacement with a different motivation for interest is the case of one of the circuits having just one node — one computational operator: Let Op be a columnar operator. The tuple with
[TABLE]
is a circuit, referred to as the lifting of operator Op into a circuit .
Note that any circuit with a single vertex is, in fact, a lifted operator, up to a renaming of its external ports. Now, consider a larger circuit , in which we perform a subcircuit substitution of a single-node subcircuit with another circuit . This is essentially the replacement of the operator lifted into with a possible implementation, . In programming language terms, it is reminiscent of the inlining of a function at its call site (and a transformation one expects to be followed by various local optimizations such as avoiding redundant copies, operators followed by their inverse and so on).
The opposite kind of subcircuit replacement is the replacement of a (larger) subcircuit by a lifted operator; we refer to this transformation as a subcircuit fusion. It is of key importance for efficient implementations of the columnar circuit model; see Section 4.1 for details.
Side note: “Primitives”, operators and composition
Many DBMSes distinguish between relational-algebraic “operators” and computational primitives: With this distinction, operators are what one might find in a logical SQL plan — high-level, non-granular. They are implemented using “primitives”, which are simpler and of higher granularity. Some primitives are atomic — and the system is unable to reason about their innards — while some are composites of other primitives. For a recent overview of this distnction, see [GBD*+*18, §1,2]. In particular, it references an (early) overview of the primitives in the columnar MonetDB [BK99] and essentially-columnar Voodoo [PMZM16, Table 2]; one notes that they are clearly distinct from relational algebra operators, in that the former take columns (or scalars, partitioned columns etc.) — not relations.
We do not follow this taxonomy. It does not concern itself with “operators” in the relational-algebraic sense (although a column store will likely acknowledge those during query plan compilation); We only have columnar “operators”, as defined in Subsection 1.1.2. We also have no notion of “primitivity” or “atomicity”. All operators as potentially composable — through the construction of circuits and finally their fusion into a new, composite operator; and they are all potentially decomposable (in a sense), by replacement with a multi-operator circuit computing the same function.
Chapter 2 Columnar representation
A column store produces and utilizes a lot of data which isn’t merely plain-vanilla columns — whether it be meta-data for schema columns; indexing structures; lower-dimension projections; or intermediate results during the processing of a query. Having kept our data structures simplistic and uniform in the definition of the basic model of computation, this section will show how little expressive power was lost — using simple columns as building-blocks for representing more complex structures, thus promoting them to “first-class citizens” within a column store.
Encoding/decoding schemes for representation
Fix, throughout this section, two unidirectional signatures and , for encoded and original/not-encoded forms respectively. Also, denote , and fix — the set of families of (labeled) columns of which we wish to be able to decode and encode. Finally, since it will often be the case that the same structure has multiple columnar representations, we also fix , an equivalence relation on : Intuitively, if , they must represent the same entity or structure.
Definition \thedefinition@alt (Decoding scheme).
Let be a pair of columnar circuits — the decoder and the encoded-form verifier — computing partial functions and , respectively. Such a circuit pair constitutes a concrete decoding scheme for w.r.t. if:
The decoder has input signature and output signature . 2. 2.
The verifier has the same input signature as the decoder (). 3. 3.
The verifier is a complete decision circuit (as per Section 1.2). 4. 4.
The decoder produces output on all valid encoded forms, i.e. . 5. 5.
The decoder only produces outputs in . 6. 6.
Every has a valid encoded form which decodes into , or into an equivalent family (i.e. hits every equivalence class of under ).
A decoding scheme for w.r.t. is a function , for which there exists a concrete decoding scheme where the domain of are the valid encoded forms for the concrete scheme, and is identical to on those valid encoded forms (i.e. and f_{d}={{\varphi_{d}}{\big{|}}_{{{\rm{Dom}}\left(f_{d}\right)}}}).
Note*.*
The verifier circuit in Section 2.1 is an artifice for compartmentalizing the potential concerns regarding decoder input validity. It lets us describe decoding circuits which presume their inputs are valid — significantly simplifying their structure and the operators they are made up of. Indeed, the computational complexity of deciding input validity may be higher than actually perfoming the decoding on valid inputs (as our model is circuit-based, not timed-machine based). Verifiers will not be of much significance in the remainder of this monograph, which is not concerned with invalid inputs and their handling.
A decoding scheme in which the decoder produces a single column () is a column decoding scheme.
Definition \thedefinition@alt (Encoding scheme).
A columnar circuit , computing function constitutes a A concrete encoding scheme for w.r.t. if:
The (encoder) circuit’s input signature is and its output signature is . 2. 2.
All families in are encodable, i.e. . 3. 3.
If satisfy then .
An encoding scheme for w.r.t. to is a function , for which there exists a concrete encoding scheme with f_{e}={{\varphi_{e}}{\big{|}}_{\mathcal{I}}}.
Definition \thedefinition@alt (Codec).
A concrete codec for w.r.t. is a tuple such that is a concrete encoder and is a concrete decoder (w.r.t. , ), and the following hold:
All encoder outputs for are valid encoded forms, i.e. . (The converse statement is valid for any concrete decoder and encoder for .) 2. 2.
Decoding the encoding of a tuple of columns in produces an equivalent tuple of columns (i.e. letting , we have for every ).
A codec is a pair of a decoding and an encoding scheme satisfying the above conditions (substituting for and for ).
Definition \thedefinition@alt (Column representation scheme).
A representation scheme for columns of type is a codec for columns (i.e. with ), with being all columns of this element type and with being the equality relation.
The definitions above allow for multiple valid encoded forms (or representations) for a single uncompressed column-tuple. Occasionally, we will be interested both in such “lax” schemes and their “narrowing”, by the imposition of further constraints on the encoded forms:
Definition \thedefinition@alt (Sub-scheme).
A decoding scheme constitutes a sub-decoding-scheme, or sub-scheme, of another decoding scheme , if and {{f^{\prime}}{\big{|}}_{{{\rm{Dom}}\left(f\right)}}}=f.
We similarly define a sub-codec and a sub-representation scheme.
Subcolumns
Explicitly-indexed columns
Before proceeding to define and model subcolumns, we first take a detour to introduce an additional representation scheme for (complete) columns. Its measure of redundancy will make it easy to adapt it, further below, to subcolumns.
Consider the following operators:
Iota
[TABLE]
Produces the identity column of a specified length, i.e. .
Permute
[TABLE]
Produces the result of applying the permutation encoded in old_pos to the data in data, i.e. a column satisfying .
Length
[TABLE]
Produces the length of the input column col as a scalar.
If we Permute a column, the original order of elements is lost, and the original column cannot be restored without known the permutation used. However, if we were to add a second column alongside our original one, and make it indicate positions — the permutation would leave us with sufficient information to undo them. In fact, the result of permuting the output of Iota is the permutation. We thus define:
Indexed
[TABLE]
The scheme induced by the concrete decoder being the lifting of Permute, and the concrete encoder mapping a column c to .
Note*.*
This representation corresponds to the Decomposition Storage Model (DSM) [CK85]. For many years it was also the default internal representation scheme for columns in MonetDB (albeit not using the formalism in this paper), referred to as a BAT (Binary Association Table); here corresponds to the BAT “head” and “tail” parts [MKB09, §3]. Recently, MonetDB has dropped this scheme [Mul16] except for some vestigial aspects of the API for columns. In C/̄Store (and likely Vertica), columns are not materialized this way — but iteration over position-and-value pairs is a fundamental part of the interface for all columns [AMDM07, §2].
This representation scheme is highly redundant. It does, however, preclude the need to consider the index of corresponding elements within the two column, i.e. one can make do with just the tuple set , decoding each tuple independently.
A subcolumn representation
Definition \thedefinition@alt (Subcolumn).
A subcolumn is a partial function whose domain (of definition) is a finite subset .
A subcolumn sc is said to be contiguous if its domain is a contiguous subset of , and incontiguous otherwise.
Observation \theobservation@alt.
A column can be thought of as the special case of a contiguous subcolumn whose domain contains 0 (hence, with domain ). This reflects our choice to define subcolumns independently of any specific super-column, or even a specific-size supercolumn domain.
Let sc, be two subcolumns of the same element type which agree as partial functions. sc is said to be a subcolumn of if their domains satisfy , and they agree on ; this is denoted .
As in the case of columns, we choose one representation scheme as the standard scheme; any other reprersentation scheme is defined by a codec relative to the standard one.
*[Subcolumn (Standard representation of a subcolumn)]
Label Type Length Description
pos Non-negative values
data
The represented subcolumn sc is the partial function , i.e. . Its domain is .
Observation \theobservation@alt.
For , the full domain, a standard representation of a subcolumn is a representation of it as a column using the Indexed encoding scheme; as in that scheme, there are multiple standard representations for each subcolumn (one for every of the permutations of the domain elements).
Definition \thedefinition@alt (Canonical representation of subcolumns).
The canonical representation of a subcolumn is its standard representation in which the elements of pos are monotone increasing.
Observation \theobservation@alt.
A subcolumn sc is contiguous if and only if the pos column in its canonical representation is contiguous.
Definition \thedefinition@alt (Subcolumn decoding & encoding schemes).
A subcolumn decoding (respectively, encoding) scheme is a decoding (respectively, encoding) scheme (see Section 2.1 and the following text) for pairs of columns, of types — an integer type and an arbitrary type — with being the set of all standard subcolumn representations, and being the equivalence relation among standard subcolumn representations. A subcolumn codec is a codec for the type pair .
As in the case of columns, decoding schemes for the set of all subcolumns of a type induce representations of type- subcolumns in addition to the standard one.
Combining subcolumns
Definition \thedefinition@alt (Subcolumn overlay).
Let , be two -subcolumns with domains , respectively. The overlay of by , denoted , is the partial function:
[TABLE]
Two subcolumns are said to be compatible if they agree (as functions) on all elements of the intersection of their domains.
Observation \theobservation@alt.
The following are equivalent regarding two subcolumns , of the same type:
and are compatible. 2. 2.
There exists a column c such that and . 3. 3.
is a super-column of both and .
Two subcolumns being compatible makes for a special case of the above definition:
Definition \thedefinition@alt (Subcolumn union).
Let , be two compatible subcolumns. The union subcolumn of , is the subcolumn .
Observation \theobservation@alt.
The relation is a partial order over all subcolumns of a fixed column; moreover, the set of such subcolumns and the partial order form a lattice w.r.t. intersection and union — isomorphic to the lattice of partial sets of a fixed set.
The above modes of combining columns and subcolumns are immediately useful in defining representation schemes:
SubcolumnUnion
[TABLE]
A subcolumn representation scheme constituting standard representations of two compatible subcolumns.
DisjointSubcolumnUnion
is a restriction of SubcolumnUnion to pairs of disjoint subcolumns. This is still a representation scheme, since the restriction is of the representations (that is, encoded forms), not of the represented subcolumns.
SubcolumnOverlay
is the subcolumn representation scheme similar to SubcolumnUnion, except that the two subcolumns need not be compatible, and the decoding result is the overlay of the first subcolumn by the second one.
In fact, some of these representation schemes inspire corresponding (full-)column representation schemes:
ComplementingSubcolumns
[TABLE]
An adaptation of DisjointSubcolumnUnion to the full-column case: and are each other’s complement, so only one of them (say, the first) is encoded; and the decoding produces a standard representation of a column, not a subcolumn.
ColumnByOverlay
Same as ComplementingSubcolumns, except that the two subcolumns need not have disjoint domain, and the decoding result is the overlay of the first subcolumn by the second one.
OverlaidColumn
[TABLE]
Similar to ColumnByOverlay, except that instead of two subcolumns we now have a full column and an overlaying subcolumn. This scheme can be decoded by the lifting of the Scatter operator (see below). (Also refered to as Patched — the individual position-datum pair are like patches applied to the fabric of the data column).
These schemes can all be shown to have concrete codecs. To illustrate what some of the decoders are like, consider the following operators:
Concatenate
[TABLE]
Produces the concatenation of the two input columns, i.e. the column
[TABLE]
This operator does not concatenate individual elements into larger elements — it’s only columns that get concatenated.
Scatter
[TABLE]
Produces the column
[TABLE]
Examples of the use of these three operators appear can be seen in Figure 2.5.
Segmented columns
Motivation
Much of the processing in concrete column stores is applied limited-size chunks, segments or blocks: Pages on a magnetic disk drive or in DRAM; the data fitting inside one of a CPU’s cache levels; a GPU multiprocessor’s shared memory; an FPGA’s bus width and its synthesized circuit data width; and so on. Many, if not most, existing column stores have chunks or segments as a fundamental abstraction, and partitions into chunks as a fundamental system feature (Some examples: Vectorwise [ZBNH05, ZHNB06], Google PowerDrill [HBB*+*12, §2.3], C/̄Store/Vertica [LFV*+*12]; a notable exception is MonetDB [Mona]). Yet, the model of computation presented in Chapter 1 is based on a uniform, unbroken definition of a column. We have opted for this simpler abstraction, as both the model itself and the representation and compression schemes this work presents would have been very unwieldy, had they beed saddled with segmentations of each column.
At the same time, we do intend to model existing systems, so we cannot simply ignore column segmentation. Segmentations are also inherent to several key data compression schemes, a subject which Chapter 3 will explore in more depth. We therefore presented segmented columns through the use of non-segmented ones, rather than the other way around.
First, suppose we merely wish to regard a column’s indices — the sequence — in contiguous segments. These can be represented as follows:
Segmentation
[TABLE]
There are no gaps between the segments, that is, for every . It must also hold that and .
UniformSegmentation
[TABLE]
A degenerate scheme for the special case of segment length being uniform; the number of segments is \lceil\text{overall_length}/\text{segment_length}\rceil.
One may verify that these two qualify as representation schemes, with the represented columns being the identity functions of any length. Also, the length values may be 0 for the non-inform-length case; when this occurs, the segmentation is said to be degenerate.
Now let’s apply these segmentation schemes to columns of actual data:
Segmented
[TABLE]
A standard representation of a column and an accompanying Segmentation.
UniformlySegmented
[TABLE]
A standard representation of a data column; only one of the scalars in a UniformSegmentation is additionally necessary, as the data column length subsstitutes for the overall_length of a UniformSegmentation.
The two kinds of column segmentation — fixed- and variable-length segments — differ quite significantly not just in their representation, but in their motivations for use; but — that discussion will wait until Subsection 3.2.3, below. The rest of this section will focus on the interpretation and manipulation of segmented columns (mostly with fixed-segment-length).
Uniform segmentation and nearly-matrices
Definition \thedefinition@alt (Segmented view).
Let c be a column of length and . The -segmented view of c is the function , defined whenever .
With this function in mind, and when is obvious from the context, we abbreviate as (the \xthelement of the \xthsegment).
The segmented view is the conceptualization of the break-up into segments defined above: Consecutive, aligned, length- segments are perceived as short columns in a -column nearly-matrix. This view is (row-major) matrix-like; but it cannot generally correspond to a proper matrix, since the last shorter column — the last segment — will be missing some elements when . We also refer to this last segment as the slack segment.
Still adhering to the matricial interpretation, a -segmented view of a column can be thought of as its transposition — a single ‘row’ of length (but bear in mind it is merely the replacement of with ). More generally, transposition is defined as follows:
Transpose
[TABLE]
Produces a permutation of col such that for every element offset within segment . Consequently, the segment length is exchanged with the number of segments.
Transposition requires col to be a complete matrix (i.e. have a full-lnegth last segment), as otherwise its result does not form a nearly-matrix, i.e. there would be gaps in the resulting ‘column’ due to their origin elements under transposition missing. This contrasts with a a segment length change (a re-segmentation if you will), which is possible for any column length.
Data replication within and across segments
Columnar circuits for decoding and encoding schemes occasionally involve replicating the values of short columns or scalars into longer columns; and this is the case also for column segments (as will become apparent in Subsection 2.3.3). Additionally, the matrix-like segmented views lend themselves to thinking of two kinds of replication of data, corresponding to the two dimensions of the segmented-view ‘matrix’: Column-wise and row-wise replication:
ReplicateSegments
[TABLE]
Produces a UniformlySegmented column with the same segment length as the input but with \text{factor}\cdot k=\text{factor}\cdot(n/\text{segment_length}) segments, with column in the segmented view of replicated being equal to column in the segmented view of col. In other words, each segment is replicated into factor consecutive copies of itself in the output.
Replicate
[TABLE]
Produces a UniformlySegmented column with longer segments than the the input, but the number of segments remains the same. The new segment length is factor times the old length; each element in each of these segments is replicated factor times, consecutively, within its segment, so that the \xthelement in the result segment equals the \xthelement of the original segment.
Note that the Replicate operator, defined in Subsection 1.1.2 for unsegmented columns of length , agrees with this definition — it is the special case of this definition where the input has just a single segment — the entire column. See also Subsection 2.3.3 below regarding similar generalizations.
Uniform segmentation and subcolumns
We would like to have a meaningful concept of “taking a subcolumn” of an -segmented view, rather than a plain column; naturally, this means respecting the segmentation when discarding some of the data. To be more explicit: A permutation of is said to respect -segmentation if the image of every -segment of the domain is an -segment as well (e.g. becomes ); and the final sub--length segment, if it exists, remains in place. A subcolumn sc is said to respect the -segmentation of a supercolumn column c if each (short) column in c’s -segmented view is either entirely within or does not intersect at all.
Observation \theobservation@alt.
An -segmentation-respecting permutation of the pos column of an -segmentation-respecting subcolumn can be uniquely determined with just the first of every contiguous elements.
For our well-behaved subcolumns and permutations, this observation leads to a more space-efficient representation:
SegmentedSubcolumn
[TABLE]
Instead of a staight-up permutation of the entire index set, this scheme describes a permutation of elements The positions are in units of elements, i.e. if k\in{\mathop{{\rm{Img}}}\left(\text{segment_pos}\right)} then the decoded subcolumn’s domain contains .
Adapting operators to column segmentation
To actually utilize segmented columns — to apply columnar circuits to them — we require operators which respect such segmentation (either fixed- or variable-length). Specifically, we would want to adapt operators we have already defined for non-segmented columns to take segmented column inputs, and produce outputs for each of the input column segments.
Definition \thedefinition@alt (Simple, fixed-length operator segmentization).
Let Op be a columnar operator taking an input column labeled c of type and producing a single output labeled , whose length is a function of . The segmentization of Op is an operator Segmentize(Op), taking a UniformlySegmented input and producing a UniformlySegmented output. Segmentize(Op) applies Op to every one of the m=\lceil\left.{\left|\text{c}\right|}\middle/\text{segment_length}\right.\rceil segments of the segmented view of c. The resulting would-be output columns (denote them through ) are concatenated together into the data component of . By our constraint on Op, all segment outputs are of the same length, which is used as the segment_length component of .
This definition can be generalized to the case of multiple input and output columns:
Definition \thedefinition@alt (General operator segmentization).
Consider a signature , let be a subset of inputs to be shared among all segments, let , and let Op be a columnar operator with signature . The segmentization of Op is an operator Segmentize(Op) with the following characterization. Segmentize(Op) has the input labels in , and additionally, for every input label in , Segmentize(Op) takes a segmented column (in the Segmented or UniformlySegmented encoding scheme) of the same data element type. Segmentize(Op) produces output only if the its inputs from all have the same number of segments. When that is the case, for each label , Segmentized(Op) produces a Segmented column, with the data being concatenatation of Op’s outputs for the input families for the each of the segments, and a segmentation corresponding to these outputs’ lengths.
In formulating this definitions, one notices how fixed-length segmentation in columns lacks robustness: If an operator is applied whose output length depends on input data rather than just input lengths (say, a range filter) — different output column segments will have different lengths; thus the outputs must be defined as variable-length segmented. For this reason the definition above does not use UniformlySegmented outputs; for those to be possible, we would need a constraint on the operator involved to conserve length uniformity.
Representing additional constructs
Index subsets
Recall that our standard representation of a subcolumn contains two columns: positions and values. Now consider the result of dropping the values column: Doing so will leave us with the information regarding which indices are the subcolumn’s domain; and since the order of indices in this columns is incosequential — what we are left with is the specification of an index subset. As in the definition of subcolumns, we must choose whether to be ignorant of the overall index set size (resp. subcolumn domain); and for index sets we make the opposite choice, marking the domain size by default:
*[SparseIndexSet (Standard representation of an index subset)]
Label Type Length Description
full_length 1 size of the full set of indices
elements up to full_length values of elements in the index subset, in any order
If the elements column is also sorted, the subset representation is said to be canonical.
The standard representation is sparse in the sense of the underlying assumption that elements not specified in it are missing from the set. Alternatively, we can choose to have an explicit indication of presence for every potential element — a dense representation — using the following:
Definition \thedefinition@alt (Set characteristic column).
Let . The characteristic column of (a.k.a. the characteristic function of ) is the function with
[TABLE]
The set of characteristic columns for all is in bijection with the power set itself; and thus we choose the characteristic columns — the evaluated characteristic functions — as the DenseIndexSet reprersentation scheme for subsets of . A concrete encoder and decoder for this scheme appear in Figure 2.12.
The decoding and encoding circuits we’ve presented for DenseIndexSet use two yet-undefined operators. These are:
SelectIndices
[TABLE]
Produces a column containing the indices of all elements of dense with value true (or if we’re using the numeric type). The output is not necessarily sorted in increasing order.
Length
Given a column of type , produces its length as a scalar (i.e. a column of length 1).
Columns of bits corresponding to a subset a column’s (or rather, DBMS table’s) indices have long been in use in analytic query processing, well before the advent of column stores (an early example is the Model 204 DBMS by Compute Corporation of America [O’N89], which predates even the era of relational DBMSes and SQL).
Finally, we define highly concise representations for subsets of which are either contiguous, or are a union of contiguous ranges.
ContiguousIndexSet
[TABLE]
The represented set is .
Partitions of columns and index sets
In Section 2.3 we presented representation schemes for the break-up of colums into contiguous segments; let us now generalize this to arbitrary partitions — in which the parts are not necessarily contiguous.
If the number of parts is fixed (say, ), we could simply adjoin the (standard) representations of subcolumns:
*[Partitioned_k]
Label Type Length Description
Element positions of the first subcolumn
Element data of the first subcolumn
⋮ ⋮ ⋮
Element positions of the \xthsubcolumn
Second subcolumn, element data
The position columns are distinct, and the union of their support sets is the entire index set, i.e. .
And if we only consider the index sets in this scheme, we have an index set partition representation scheme: .
Note*.*
Given our constraints, only of the position columns are actually necessary. For the case of , dropping the redundant complementing position column results in the ComplementingSubcolumns scheme.
Having separate columns for each part in the partition becomes rather unwieldy with many parts, and essentially irrelevant when wishing to represent a number of parts proportional to the column length. We can do with something simpler than subcolumns, when we consider set-theoretic definition of a partition: A function from the set of indices to the set of parts. And a column, after all, is merely an evaluated function from indices to the domain of the element type; hence:
*[Partition (Standard representation of a column index set partition)] An alias for the standard representation of a column, with the domain being a set of part identifiers.
A representation of a partition in the Partition scheme is said to be canonical if its image (as a function) is for some . With a canonical representation, there are no implicitly-empty parts.
Note*.*
The circuit in Figure 2.13, when adapted for , transforms a DenseIndexSet instance (after a to upcast) into an index subset in the default representation, along with its complement.
Element de/composition, interleaving and type-punning
Let , and consider the following operator:
*[Zip_k]
[TABLE]
The operator, with being the -tuple constructing function . (a.k.a. Compose; see [GBD*+*18, §3.1]).
this operator induces the following representation scheme for elements:
Components
Each multi-type element is represented by elements in disjoint columns, each with a single, simpler, uniform type. It is decoded by applying , and as that operation is invertible, it is encoded by applying .
The Components scheme can also be thought of as a Structure-of-Arrays representation of a product-type column, as opposed to the standard representation, which is an Array-of-Structs. Also, if a relational DBMS table only has types of fixed width, and is the tuple of the table column element types — Components constitutes a representation of the entire table as a single column.
Now suppose that all types in are identical, i.e. the case of for all . For the distinct-type case we needed a separate column for each component; but for the uniform-type case, we could just have all of them within a single column. Below are two alternative formalizations of such a scheme, differing by the placement of component data within the single column:
*[ComposeSegments]
[TABLE]
The output of this operation is the equivalent of applying to the different segments of a segmented view of your input, each considered as one of the component columns. columns, so that the output satisfies . Note that a different Zip operator will be applied for different lengths of the components column - so that this operator and Zip are quite distinct, despite the similarity in practice.
*[Assemble_k]
[TABLE]
While the segment_length scalar is redundant, its presence makes this a uniformly-segmented scheme. In a segmented view of components, the output is obtained by a applying the elementwise function of \textsf{Zip}{}_{\text{segment_length}} to each of the segments. Thus the output satisfies .
Each of these operators can be obtained from the other by applying it after a Transpose.
The two operators translate into two compression schemes — two specializations of Components for the case of a uniform elementwise function argument type:
ConcatenatedComponents
A segmented column decompressible by ComposeSegments; the input column length must be divisible by the segment length, i.e. the segmented view of the must be a full matrix.
Shattered
A segmented column decompressible by Assemble; the input column length must be divisible by the segment length.
Bitwise decomposition
The deepest one can go in applying ConcatenatedComponents is breaking elements up into individual bits: A -bit-wide column becomes 1-bit-wide component columns, concatenated into a single, -times-longer, -bit wide column. Such decomposition has seen some research attention under the name of “bitwise-decomposed storage”. Specifically, when I/O is very expensive (or slow) relative to computation (as in the case of GPU accelerators obtaining data from main system memory over a PCIe bus) — it may be worthwhile to send over just the highest bit or several bits of a wider column, and begin some computation of values (e.g. for CPU-GPU co-execution of queries, as explored in [PMK14]).
Another kind of decomposition into bits — less orthogonal and space-frugal — is per-value indicator bit columns. For example, suppose is a type with domain instead of using 3 one-bit component columns (with which values will correspond to 000,001,010,011,100), we would use 5 one-bit indicator columns, such that for every index , exactly one of them is set (i.e. 00001,00010,00100,01000,10000).
ValueIndicators
[TABLE]
num_bits concatenated columns (via a segmented view); the \xth-bit column is a dense subset representation of those indices within having value . (Inaccurate but common shorthand name: Bitmap; a.k.a.“bit-vector encoding” [ABH*+*13, 422].)
While this representation scheme is exponentially inefficient, it has the advantage of offering what are essentially pre-computed results for constant-column equality operator applications, and requiring access to only a small part of the column when only a small subset of values are of interest.
Type punning and member access
The bitwise decomposition described in Subsubsection 2.4.3.1 is a specific example of using the Shattered for reinterpreting, rather than transforming, data. In our model of computation, there is no “reinterpretation”, nor access to a part-of-an-element — a column is never replaced, reconceived, or trimmed of uninteresting data; but in actual programming, A single value of an aggregate or product type may be perceived as the sequence of its constituent types, in order of their appearance in physical memory. For example: a complex number could be represented by its real component followd by its imaginary components, separately. Descending a level further, non-aggregate numeric types may be perceived as sequences of bytes, or bits, in accordance to the idiosyncracies of their representation in computer memory. This practice is known as type punning; applying the Shattered scheme with an appropriate function on an input column produces the equivalent of such punning (and will likely result in actual punning in an implementation of the computationa model).
Variable-width columns and string representation
Our basic definition of a column (Subsection 1.1.1) was chosen for its simplicity, which in turn simplifies the formalism for our model of computation. An important aspect of this choice is the limitation of columns to have a fixed width, i.e. element types with a fixed-size representation. This ensures the memory representation of a column is perfectly straightforward: The location in memory of the representation of each element can be determined without having to pre-read any other information from the column (no “read-after-read” dependencies). A column store must, however, also support variable-width data — so as to hold columns of strings, arbitrary-precision numbers or just opaque sequences of octets. Variable-width data also features extensively in many CPU-targeted lightweight compression schemes (see, e.g. [DHHL17]); most of which are usable or in-use in column stores, further motivating consideration. To do so, we will not amend the definition of a column, but rather make a separate one:
Definition \thedefinition@alt.
A variable-width column is a function (where the empty product of ’s is ) for some fixed-representation-size element type and non-negative integer . is the column’s length, and is its base element type. The length (in units of ) of the \xthelement of vwc, also referred to as the width of vwc at index , is the value such that .
A variable-width column is not a column by our definition (Subsection 1.1.1); it may only accidentally constitute a column if it so happens that all of its elements have the same length, it will therefore not be decodable into the standard column representation, nor could we encode it in other column representation schemes. The concatenation of the -units of all column elements, however, is a plain column; and the additional information it needs is the association of contiguous subsequences of elements with their corresponding variable-width element indices. That is exactly a partition into segments, discussed in Subsection 2.4.2; and our representation scheme will combine a Segmentation form with the raw data:
(Standard representation of a variable-width column)
[TABLE]
start_position and length correspond to start and length, respectively, in scheme Segmentation. For an index , the \xthelement of the variable-width column occupies the range of elements (and specifically, occupies nothing if ).
This “verbose” choice of standard representation has more to it than meets the eye, as we have not constrained start_positions to even be monotone increasing. When it also holds that \text{start_positions}{\left[i\right]}=\sum_{j<i}\text{lengths}{\left[j\right]}, things are much simpler, and we refer to this case as a canonical representation of a variable-width column.
A special case of variable-width columns are those columns whose width is not fixed, but is at least bounded. In the SQL standard, VARCHAR(k) columns are of this kind: strings with a per-column maximum length. These columns have a more straightforward, though wasteful, representation if we expand all elements to actually take up that maximum width:
CappedWidth
[TABLE]
Considering a max_length-segmented view of data, each column is a small buffer holding a single variable-size element, and lengths indicates how much of the buffer is actually taken up by the element; the few remaining type- elements may have any value and are ignored.
Note*.*
The above is insufficient to fully model the representation of strings, as it does not go into the character set encoding — which often intorudce another layer of variability-of-length: Each single character within a string can have variable length (e.g. when the popular UTF-8 encoding is used). While this work covers composite compression schemes in Chapter 3, String representation is not explored further
Nullable and union-type columns
In SQL tables, a column may be allowed to have NULL values at some positions rather than a value of the actual type. This can be interpreted as expanding the column type by a single value, i.e. the replacement of by the union type (with having a single possible value); and this interpretation motivates considering the case of NULL’s as a special-case of disjoint-union types: . How would we represent a column with such an element type?
Three approaches come to mind:
Actually expand the representation of values to accomodate all values as well; this often means increasing column elements’ width in bits. 2. 2.
Hold two complementary subcolumns, one of ’s and the other of ’s. 3. 3.
Hold a column of just one of the types (without loss of generality, ), and an overlay subcolumn of elements of the other type, which are to be patched into the base column.
The first approach is typically the most burdensome: In addition to the width increase, one must also pay up-front the price of extra condition checks and reinterpretation work to obtain a usable or from the combined domain. However, by definition, this is our standard approach: Ignoring how the type was formed and yielding a standard representation (in the sense of Subsection 1.1.1). The second and third approaches correspond, repsectively, to the ComplementingSubcolumns and to Patched.
Now let us consider these approaches for the specific case of NULL’s. The first approach isn’t often used in DBMSes in practice (in part due to the shortcomings listed above). Some DBMSes do, however, artificially restrict many of their data types to ensure at least one “invalid” value, which is then used to represent NULL. Two concrete examples from MonetDB, which takes this approach [Theb]: In the case of fixed-width integer types, the lowest or highest representable value is sacrificed to serve as the encoding of NULL; and in a UTF-8 encoded string, one of the invalid sequence of octets is used (as not any sequence of octets is a valid encoded UTF-8 string).
Using the second approach for NULLs, we would compose ComplementingSubcolumns with the Constant scheme used for the subcolumn, i.e. out of pos, and , we would only need the first two constituent columns — the non-null positions and the non-null values — alongside the overall column length and the NULL scalar.
Finally, the third option would also require just two (non-scalar) columns due to the use of Constant: A full-length column with junk values at the overlaid positions, and the column of overlay positions. In this case, and for a column of basic type , of length and with NULL values, the overhead would be bits, or relatively to a non-nullable column of type and length .
Chapter 3 Column compression
We have so far modeled columnar computations; and have used them to represent several fundamental combinatorial structures in columnar schemes. This is sufficient machinery for us to turn our attention to encoding schemes effecting data compression. The following sections are not intended to be an exhaustive re-formulation of existing academic work on compression schemes for DB columns; they do, however, cover the lightweight compression schemes most commonly studied academically and used in practice (see [ABH*+*13, §4.2] for a brief survey), formulating them in columnar terms. Other schemes developed below result from the application of the same principles and approach as in previous chapters, as well as the composition of existing schemes — and have mostly not been formulated in previously published research.
Definition \thedefinition@alt (Compression scheme).
A column compression scheme is a codec for single columns, as per Section 2.1. Respectively, a concrete column compression scheme is a concrete codec for single columns.
Column compression schemes are often not representation schemes for columns, in that only a subset of all possible columns is representable by a compressed form in a given scheme (other columns are “not compressible” by the scheme).
Definition \thedefinition@alt (Representation size).
The size (in bytes) of a columnar representation of a column or other structure is the sum of the constituent columns’ sizes in bytes, which in turn is their element type’s fixed width in bytes, times the column length.
Definition \thedefinition@alt (Compression ratio).
The compression ratio of a compressed form under a concrete compression scheme is the ratio of sizes of and in bytes. The compression ratio of an uncompressed column col under scheme is the compression ratio of its compressed form (which is the ratio of sizes of col and in bytes).
Basic schemes
We begin with a formulation of relatively simple compression schemes, each exploiting a single aspect of redundancy or excess in the representation of the input: Predictability of values using the element index; or a support set much smaller than . These schemes are also characterized by decompressed elements directly depending on a single element of the compressed column, at the most — so that the basic schemes are also the “most parallelizable”.
Output-index-based compression
Our first compression scheme applies in cases where the entire input column is simply an evaluation of a known function:
*[Generated_f]
Label Type Length Description
length … of the represented column
The decompressed column is the evaluation of over domain (i.e the result of applying the composition of after Iota to the compressed input).
Of course, there exists only one such column for each choise of at each length, which means such a scheme will not often be directly used in practice; still, auto-generated columns do occur in real-life databases (e.g. matrix row and column indices based on the overall record index). To slightly expand the expressivity beyond this scheme, we introduce some parameters to choose within a larger (though fixed-dimensional) space. For example, let it be just a single parameter for selecting among the space of uniform-valued functions from to :
Constant
[TABLE]
The decompressed column has length elements, all equal to value.
This is, in fact, more than a toy example; it is quite the useful plug-in for more complex compression schemes — where it might stand in for a full-blown component column. Examples of such schemes can be found in Subsection 2.4.5 and Subsection 3.4.1 below. It may also be used as the default representation scheme for newly-created non-NULL fixed-width columns, so as to avoid the work of actually initialize them.
For columns with a ring-like element type, admitting addition and multiplication (e.g. the integral types), the Constant can be seen as a semi-degenerate of larger spaces of functions: The single value value is a scalar coefficient, for a single basis function . If we allow functions, rather than just one, as part of the definition of the scheme, we have:
*[Generated_→f]
Label Type Length Description
length … of the intended column
coefficients
coefficients of the linear combination of
forming the generating function
The scheme is parameterized on a sequence of univariate basis functions, , so that the decompressed column is an evaluation of over the domain .
GeneratedPolynomial
The scheme, with the choice of increasing-power monomials for , i.e. .
Of course, real-life data does not match a generated function perfectly — as there are almost always some discrepancies (see Subsection 3.2.4) or what could be described as noise (see Subsection 3.2.1).
Column support compaction
The support of a column may only constitute a small subset of the domain of its element type, motivating compression schemes which use less space to indicate which element of that support set is used. We consider an initial, simplistic taxonomy of small support sets, by order of increasing complexity.
Singleton set
[TABLE]
Constant 2. 2.
Set having a low maximum within with respect to its physical (binary) representation, containing most values below that maximum
[TABLE]
DiscardHighBits 3. 3.
Set with none of the above features (scattered in a non-trivial fashion within )
[TABLE]
Dictionary
Singleton support sets
Single-value columns admit the Constant compression scheme from Subsection 3.1.1 above. Constant is a degenerate case of a small support set, requiring no per-element compressed data.
Dense low-bounded support sets
A database column will often be declared to hold integers of some default (larger) width, while in fact its data could be represented with a lower width. This makes the top bits in the representation always-zero (or in the case of signed integers, a sign-extension). If it also happens that within the non-redundant bits, the column’s support set is ‘dense‘ — containing more than half of the possible values — it does not make sense to try to represent an element of the support set other than by its lower bits. Generalizing from the case of unsigned integers, we define:
DiscardHighBits
Let be types, be the natural well-ordering of and a positive integer, such that and that is lower by than the -th lowest element in . The compression by DiscardHighBits is the mapping of each element of type to itself, but as an element of type ; and the decompression is the opposite. In “physical” terms, this is typically the dropping the high bits in the representation of each elementAbusing the above definition somewhat, we also refer to the discarding of high bits of signed-integer types as encoding with this scheme.
NullSuppression
A commonly used alternative name for DiscardHighBits; the scheme does not relate to the SQL NULL value. (Shorthand name: NS)
Explicitly-enumerated support sets
The support set may sometimes be small, but not limited mostly to the lower elements of an ordered type. While it may still fit some pattern or rule, it is often simple and effective to specify all elements of the set, using an evaluated function whose image covers the entire set. This is (inaccurately) referred to as a dictionary for the column, used in an eponymous compression scheme:
Dictionary
[TABLE]
Letting col denote the uncompressed column, is a superset of . The compressed form is the index in the evaluated dictionary instead of the original value, so that (with denoting function composition), and elementwise we have .
Decompressing the Dictionary scheme involves performing essentially the opposite of the Scatter operator (see Subsection 2.2.3):
Gather
[TABLE]
Performs an indirect lookup into data, i.e. gathers various elements of data, so that .
De-duplication and use of dictionary indices as surrogates
With a compression scheme focused only on the support set, it is natural to wish to use the compressed-form elements (the representations of individual uncompressed elements) as surrogates for the original column elements: To avoid decompression, and apply columnar operators to the compressed form of the data. This is possible if the compression function is injective, or better still, when the order relation within the compressed domain commutes with the decompression function. Key operators we can apply to the compressed surrogates are:
- •
Equality and range filters, using a compression of a single match value or a pair of extrema to compare against;
- •
Sorting or partitioning by relative order;
- •
Obtaining the column’s support set;
- •
Join of a pair of columns which share the same compression scheme.
This potential for operator “push-down” via surrogates was noticed already in early research into the use of compression in DBMSes [GS91, Page 4].
Use of surrogates is clearly possible with DiscardHighBits; but the Dictionary scheme does not guarantee, by definition, usable surrogates. To secure this guarantee we must impose additional constraints on the dictionary column of the scheme:
Injectivity: For surrogate use of the compressed elements in exact-match comparisons, must be a proper function, i.e. all dictionary entries must be distinct. 2. 2.
(Strong) monotonicity: For surrogate use of the compressed elements in order relation comparisons, dictionary must strictly preserve that order, i.e. iff . (Note that if dictionary is known to be injective, this is equivalent to the additional constraint of weak monotonicity.)
By adding one or both of these constraints to the definition of Dictionary, we obtain a different — more restricted — compression scheme:
UniqueDictionary
A sub-scheme of Dictionary, where compressed forms have no duplicate elements in the dictionary column. (Shorthand name: UDICT.) With this scheme, (with denoting the composition of functions).
*[MonotoneDictionary_⪯] A sub-scheme of UniqueDictionary, where the dictionary column is also (strong-)monotone-increasing with respect an order relation over ; we omit if it is the default order relation for the uncompressed column’s element type. (Shorthand name: MDICT.)
De-duplication and sorting change the cost-benefit tradeoff of the unconstrained Dictionary scheme: We gain the use of surrogates, described above — at the cost of additional, less-parallelizable work in performing the compression. But there may be additional, secondary gains in using UDICT or MDICT: When a unconstrained dictionary contains many duplicate entries, their removal reduces its size. This, in turn, may allow for a smaller width of the dictionary indices as well. The compression ratio may thus improve somewhat; and a smaller dictionary is also likely to fit more of itself into a processor’s cache or local memory space. Also, a sorted dictionary is more likely to admit additional compression utilizing the similarity of consecutive elements (see 3.2 and 3.6.1 below).
Finally, note that the choice of indices in a dictionary can be used to express an order relation among values of the encoded column, other than the default order on the uncompressed column’s element type. For example, the dictionary entries could be ordered by descending frequency within the uncompressed column, or even so that the dictionary index is a hash of the value (see also Section 3.3).
Patterns of scheme composition and transformation
A reader familiar with existing analytic DBMSes (columnar or otherwise), may be puzzled by the previous section: Very few schemes were presented as “basic”; most of them cannot even encode an arbitrary input column (regardless of compression ratio); and several schemes which, in other systems, are not considered ‘composite’, were not mentioned (such as RLE and FOR). The reason for this is that our model of computation, together with the machinery for columnar representations of data, allow us to formulate all those additional schemes by composing the basic ones, or transforming them using a few additional operations in the encoding and decoding circuits.
Each such “composite compression scheme” is simply a codec, with the encoding and decoding partial-functions being compositions of several functions. A composite scheme may be concretized by composing the decoding and encoding circuits of its constituent schemes: Assigning outputs of one decoder to inputs of the other, and assigning encoder outputs in the opposite direction; or, in some cases, taking the union of these circuits; both of these transformations were described in Section 1.3 above.
One can compose compression schemes almost to no end, choosing schemes using knowledge of the intended input distributions. This section will describe some patterns for composing schemes — which will be put to use in concrete composite schemes of particular interest, throughout the rest of this chapter. Each of the patterns presented here exemplifies some concept worthy of explicit description — and are commonly useful in terms of compression ratio gains.
Elementwise composition and “noise-signal”-like separation
In signal processing, a fundamental task is restoring or isolating an original transmitted signal from (literal) noise it picks up as it is transmitted over physical media. The signal carries limited and well-formed information; the noise is unconstrained with the encoding or modulation of the signal, but is of limited power. In our setting, there is ‘noise’ per se — information can discard; but the analogy still inspires a decomposition of an unencoded column: , with signal admitting a more effective compression (typically better than, say, DiscardHighBits), and noise being of limited magnitude. These can be compressed separately, with noise using DiscardHighBits.
The trivial — though useful — example of this kind of scheme would follow through with the analogy to signal processing:
*[NoisyGenerated_→f]
Label Type Length Description
coefficients
coefficients of the linear combination of
forming the generating function
noise elementwise additive noise
The type is a subtype of , typically with fewer bits in its representation. The decompressed column is the addition of the noise, up-cast from to , to the generated function.
The more general scheme above scheme may well be used in practice to store samples of some real-world signal, with signal-processing techniques employed to determine the basis coefficients.
Generalizing the ‘signal-noise’ decomposition, elementwise addition may combine arbitrary schemes. Specifically, Generated with base functions can be perceived as the application of compositions-by-addition of schemes for the different basis functions.
Note*.*
While lossy compression of information is out of scope for this monograph — schemes could be used for lossy compression floating-point data, which is of inherently limited accuracy: The noise values might be encoded at lower precision, seeing how after their addition to signal, those less-significant bits may fall below the floating point precision threshold.
Discrete differentiation and integration
Column stores processing queries, and performing decompression, frequently need to consider both the positions (or indices into a column) of elements and lengths or distances between elements (within a column), or to switch between these two kinds of information. When compressing, we can make do with only one kind: We may store the positions and take their derivative as necessary, or store only lengths, and integrating over them. To be more concrete, circuits involving such compressed data will use one of the following operators:
Derivative
[TABLE]
Sets to — the discrete derivative.
*[PrefixSum]
[TABLE]
Sets to . (a.k.a. InclusivePrefixSum, Scan — but this is not a relational“table scan”; see also [GBD*+*18, §3.2]).
*[ExclusivePrefixSum]
[TABLE]
Sets to . Similar to PrefixSum, except that the \xthaggregate does not involve the \xthelement.
*[PrefixAggregate_⊕] The generalization of PrefixSum to an arbitrary (commutative) binary operator .
*[ExclusivePrefixAggregate_⊕] The generalization of PrefixSum to an arbitrary (commutative) binary operator . There must be a neutral element in w.r.t. , for use as the aggregate of no elements.
Segmentization
In Section 2.3 we formalized representations for segmented columns, and the process of segmantization of operators. Now, given some compression scheme for columns — it can be applied separately to consecutive segments of an (uncompressed) column, with the compressed forms’ constituent columns for every segment being concatenated, to form a compressed form for the column overall. Doing so is applying a segmentized version of the original scheme. Segmentized schemes are of two varieties, depeding on the nature of the segmentation:
Fixed-length segments
As mentioned in Section 2.3, segmented columns with fixed segment length are prevalent in many column stores regardless of compression; and they therefore often choose to compress distinct segments separately (possibly with some column-level data) — to avoid inter-segment dependencies during decompression. Provided segments are not too short, this may help compression ratio: The overhead on per-segment data is often lower than the savings due to localization: A smaller range of variation to cover; and no need to tolerate or account for anomalies throughout the entire column.
Variable-length segments
Letting the number of elements per segment vary is a costly choice, regardless of the compression scheme. First, there is the space required for specifying segment lengths. There’s also a cost in parallel decompression time, due to read-after-read dependencies: A decompressed column element’s segment index cannot be determined in advance (and, in fact, often requires multiple reads into a Segmentation); and only when it is known can the per-segment data be read. Such a choice would therefore be the result of necessity rather than convenience:
- •
The column data itself may require adapting segment length to capture abrupt local changes within a column. Alternatively, the data may exhibit gradual, but non-uniformly-progressing, changes in behavior; in this case the break-up into segments would be rather artifical, but required for limiting divergence between the actual data and some localized model. As an example, think of columns obtained by the following random process: Elements are uniformly and independently sampled from a small-support local distribution, and this distribution changes at a non-uniform pace.
- •
In some cases, it is the decompression process which necessitates variable-length segmentation. We observed in Subsection 2.3.3 that segmentized operators do not preserve uniformity: The dependence of operator output length on the input data causes uniformly-segmented data to be transformed into non-uniform-length output segments. Thus, even if a variable-length segmentation is not immediately apparent in a description of the compressed form, a decoder may have to introduce it within a decoding circuit.
Patching and outlier removal
Definition \thedefinition@alt (Hamming distance [Ham50]).
Let , be columns of type and length . The Hamming distance between and is the number of indices on which and disagree, i.e. . The Hamming distance between a column col and a set of columns , all of the same length as col, is the infimum of distances between col and every column in .
Suppose some compression scheme MainScheme (that is, some codec ) has certain desirable features, such as high compression ratio or well-parallelizable decompression. Now suppose we wish to compress a column col which is not in ; rather, it is within a small Hamming distance from it: If not for a few outlier values, the column could be compressed using MainScheme. Let denote a column in , closest to col; instead of giving up on the efficient compression of col, it is intuitive to consider using the compressed representation of instead, with some information allowing for post-decompression correction of into col. The necessary information is in fact simply the subcolumn of col on , which we adjoin in the standard representation (see Subsection 2.2.2). The application of this subcolumn — the patching of with col values — is an application of the SubcolumnOverlay operation; and we have thus obtained a new compression scheme, being the composition of Patched (defined in Subsection 2.2.3) after MainScheme on the main column.
The decoding example is immediately reminiscent the use of the Patched scheme for representing NULL values, in Subsection 2.4.5 Indeed, if the column element type is , and there are only a few elements from , the patches can have type and the column overall can be compressed as a purely -type column.
The use of patched compression schemes in column stores was pioneered by Vectorwise, as presented in [ZHNB06]. However, work published so far on this subject (as surveyed[DHHL17]) does not present patching as a meta-scheme, or a scheme transformation, applicable generically to arbitrary base schemes; rather, very specific patched schemes are presented. This stems from the orientation of existing work towards less-parallelized CPU-based decompression: These schemes “package” data from both the main column and the patches subcolumn into consecutive chunks of the (not immediately columnar) compressed form — so that it fits well into a few consecutive CPU cache lines. This is done with some finesse in carefully designing compressed block layout — which makes for idiosyncracy rather than generality. See a more detailed discussion of this point in [RB17].
Patching can increase compression efficiency not only by reaching the domain of a compression scheme: It also allows selection of better-compressible column within a compression scheme’s domain. For example, suppose the RLE scheme is applied to a column with very long stretches of similar lengths. But suppose also that at a low frequency within those stretches, an interrupting value appears once or twice. The distance between these interruptions has high variance, making it difficult to estimate the index of the run covering a given position in the output; also, the interruptors take up close to half of the RLE compressed form in terms of bytes used. Patching away a single one of these interrupting values saves the space of two values and two run lengths in the main RLE compressed form, but costs one-or-two values and one-or-two position indices in patch information; this is not much of a saving, if at all (especially if the type for position indices is wider than the type of run lengths). However, the overall length of the compressed main column has now dropped significantly — as most runs had only existed separately because of the interruptors — and the variances in run lengths have also decreased. This may allow for faster decompression of the column overall, as well as faster processing of the compressed form: Computing, say, a sum of all column values may become faster due to the smaller number of runs, while the re-integration of the sum of patch values and the sum of the main column will have very low overhead.
Note*.*
As part of a later discussion of composite compression schemes, a converse-of-sorts of column patching will be presented in Subsection 3.5.3.
Alternating schemes within the same column
This section is concerned with the variation in the distribution and patterns of data within a single column to be compressed. We have already touched upon several approaches to handle such variation, under certain constraints: The use of (low-complexity) models; separate handling of outliers by patching; and the localization of the compression scheme’s parameters, by segmentizing the scheme. But what if significant fractions of the column behave so differently, that forcing the same compression scheme on the entire column is extremely costly? Alternatively, what if two possible schemes are each better fit at different parts of the column, so that while none of them does poorly overall, each of them could do really well if it could just be limited to that part? Indeed, it is intuitively useful to be able to alternate between two (or more) different schemes in different parts of the column.
In existing column stores supporting compression, this is achieved as a side-effect of column segmentation. In SybaseIQ, for example, each page in magnetic disk storage may have data in a different compression scheme [ZHNB06, §2.1]. In Vectorwise, there are (at least) two levels of segmentation — one spanning a certain number of secondary storage pages (“chunks”; a compression scheme is chosen at this resolution) and within each chunks, multiple segments which may either be compressed or uncompressed [ZHNB06, §3.1.1].
It so happens, that this capability is inherent already in the machinery developed so far in this and the previous chapters, for representation and compression schemes: For each of the compression schemes to be alternated, the elements of the column compressed using this scheme constitute a subcolumn; and these subcolumns constitute a partition of the full column. We have already discussed the representation of partitions, in Subsection 2.4.2; one simply has to adjoin the Partition representation scheme with the compressed forms for the concatenated elements of each of the compressed subcolumns.
Of course, the column representing the partition (holding compression scheme indices) may itself be compressible, reducing the overhead of scheme alternation. A specific case of interest is alternation aligned with transitions between equi-sized pages or chunks on disk or other storage: In this common case, we call the partitions are -segmentation-respecting, for some appropriate . Given , and with alternating compression schemes — instead of keeping a partition with bits per each compressed column element, we would only require bits per element to indicate which scheme is in use. For typical values of in practice, this is rather negligible.
Using a single partition column is not always the best choice, especially for an -segmentation-respecting partition. In the latter case, we may prefer to represent each of the subcolumns using SegmentedSubcolumn before each subcolumn’s specific compression scheme. While the space overhead is somewhat higher — up to per element for a column of length — this representation affords us immediate use of each subcolumn separately. Also, a concatenation of the different segment_pos columns will constitute a valid Segmentation scheme instance.
Having presented several patterns for composing compression or encoding schemes, in subsequent sections we will use them to build up a rising pyramid of actual composite compression schemes, exploring their uses, strengths and weaknesses.
Variable-width columns: Dictionaries and surrogates
In Subsection 3.1.2 above we explored the use of dictionaries for compressing individual elements independently, and how their use may be adapted so that dictionary indices are usable as surrogates for the entire value (Subsubsection 3.1.2.1). The benefits of achieving the same for variable-width columns are potentially even more dramatic: It is typical, for example, for a database to have long columns of strings, each of which is a word or a phrase taken from a small set; and users are notorious for performing Join’s on these columns.
Recall, that the standard representation of variable-width columns (defined in Subsection 2.4.4) already has a dictionary-like aspect: Access to element data for a given index in the column is indirect, going through a column of pointers / position indices into the raw data. If all elements of a variable-width column happen to have length 1, then its lengths column is redundant, and we in fact have a Dictionary-encoded regular column (with start_positions assuming the role of indices and data assuming the role of dictionary). It can thus be said that the standard representation variable-width columns already incorporates a dictionary, except that dictionary keys are (position, length) pairs rather than merely a position; and that no additional compression scheme need be defined.
If the support set is small enough that indicating the length of each element is too wasteful, the pair of columns start_positions and lengths may be compressed using the Dictionary scheme — with identical indices. The resulting compression scheme merits a proper named definition:
VariableWidthDictionary
[TABLE]
The \xthelement of the uncompressed (variable-width) column is the concatenation of the elements of entry_data at indices \text{entry_start_positions}{\left[i\right]} through \text{entry_start_positions}{\left[i\right]}+\text{entry_lengths}{\left[i\right]}-1. (Shorthand name: VWDICT.)
With VWDICT defined, we now have a second alternative for a surrogate scheme for variable-width data: Either use the default representation’s (position, length) pairs, or just use VWDICT positions. And for each of these alternatives we can define the two sub-schemes in which the dictionary entries are unique and strictly-monotone respectively (see Subsubsection 3.1.2.1).
Creatively positioning variable-length element data
Two final potential benefits of using dictionaries with variable-length data involve either the overlap or the spacing-out of element data within the data array.
Recall that there are no constraints — in either the standard representation or in VWDICT — on the positions within the raw data column of elements’ data ; this is unlike in the canonical column representation, where data is a concatenation of the elements in order. Specifically, there is nothing preventing the stretches of individual values for different elements of the variable-width column from overlapping each other, or even beginning at the same position: A variable-length element is determined also by its length. Thus with base data “abc”, we could have the dictionary consisting off “a”, “b”, “c”, “ab”, “bc”, “abc” and the empty string — 7 different elements. Overlap use still has a small price with VWDICT, where each such element costs another length value, but in the standard representation, it costs nothing.
Alternatively, we may want to use the dictionary indices to make searching for element more efficient. Suppose we wish to determine whether a column contains a certain variable-length value. If the column values are sorted (regardless of the compression or representation scheme), a binary search would work. if we were guaranteed the dictionary only holds extant values, and we were using the sorted sub-schemes of the default reprersentation or of VWDICT, we could apply a binary search to the dictionary — which is likely much faster to do. But finally, suppose we have a reasonable hash function ; in this case, we could have the data for element appear in data starting at index (ignoring collisions). If we then search for our arbitrary element at that exact position, the search would only require constant time (independently of the column length) on average [CLRS09, Chapter 11].
Of course, collisions can and do occur. One can construct a proper hash table to handle them (e.g. of the linear probing [Lit80] variety); but another option is to give up on hashing colliding elements, so that data is split into hashed_data and unhashed_data. MonetDB applies this approach to some extent for representing string columns: For string columns with small support size, the strings are placed inside a hash, Once the hash exceeds some size, storage reverts to a more straightword manner, which is not even a dictionary, so that later-inserted strings may appear multiple times. (This feature has not been described in published scholarly work, and would require examining the source code [Thea]).
Hash-based placement of element data also has uses when Join’ing columns. Of particular interrest is the case of a pair of columns to be Join’ed, both of which share such a compression scheme: A hash-table layout of the dictionary can serve as an imperfect surrogate of a hash table of the entire column — saving most of the work of a hash-based Join implementation, except for those elements with hash collisions.
Segmentized schemes
Uniform-value-run encoding
Database table columns may exhibit long sequences of identical values — a run — without being constant overall. The typical example are the columns of a multi-column key by which a table is sorted, with the exclusion of the last column; and these are quite prevalent in practice (as the authors of C/̄Store report, for example, in [AMF06, §4.3]). With our extensive previous discussion in Subsection 3.2.3, and recalling the basic schemes in Section 3.1, we can capture these runs by applying the Constant compression scheme to each of them, and treating the concatenation of these stretches as a segmented column, i.e. segmentizing the Constant scheme. The resulting scheme is:
RunEncoding
[TABLE]
The uncompressed column has the value at all positions .
This scheme achieves effective compression only if the run lengths are not too short on average. To quantify “not too short”, consider the specific case of : The representation of each run requires one extra element in each column, which in our limited case is 3 elements; thus, for a compression rate of 2, the average run length would have to be at leeast 6. This begs for some further space savings, so as to be useful with more modest average-length of runs. Reducing the overhead is indeed possible, since start_position and length columns are almost entirely redundant with each other: The former is a discrete integration of the latter. Dropping any one of these columns results in a different scheme:
RunPositionEncoding
RunEncoding without the length column, but with an additional scalar overall_length. Or, a standard sucolumn representation of the first elements of each run, plus the overall length necessary to bound off the last run. (Shorthand name: RPE.)
RunLengthEncoding
RunEncoding without the start_positions column. (Shorthand name: RLE.)
There is a trade-off in the choice of which of the redundant columns remains and which is discarded: If we keep the start_position column, we get simplified decompression — as the value of any element of the output is determined by the triplet of elements for a single run, without influence by any of the other runs; decompressing using the length requires discrete integration — a much more costly operation with deep dependency chains among elements. On the other hand, run lengths are typically much shorter than the entire column length, in which case we can further compress them with DiscardHighBits — with minimal decompression overhead; this motivates keeping length over start_position. In fact, we can ensure that this typical occurs always, with a slightly modification of the RLE scheme:
CappedRunLengthEncoding
A scheme similar to RLE, but with for some r provided as an extra scalar. When encoding, runs longer than elements are broken up into consecutive runs of length , and a final run of up to elements — all with the same run value. (Shothand name: CappedRLE.)
Note*.*
The RLE scheme is very well-known — albeit not in a columnar formulation — and in extensive practical use in a variety of applicative fields, dating back as far as analog compression of US Television broadcast signals in the 1960s [CKPB63, RC67]. The capping of run lengths, so as to limit the amount of information required to encode it, and the consequent introduction of additional runs of the same value, was discussed and put into practice already in those early days of digital telecommunications [CKPB63, §F]. The RPE scheme is not as frequently used; this is likely because it is less suited for communication streams, being anchored to some starting position. Also, the decompression penalty when using RLE only occurs in a parallelized setting; with serial decompression, integration is just as easy as differentiation (neglecting numeric stability issues), slanting the trade-off mentioned above in favor of RLE. The RPE scheme has, however, recently proved quite useful for linear algebra computations on compressed data (see [EBH*+*16, “Offset List Encoding” in §4]).
Finally, we consider two variants of RunEncoding and its related schemes, involving further segmentation:
Fixed-width pre-segmentization
A significant difference between the columnar formulation of RLE and its use in practice has to do with the common practice of holding columnar data in segments, “blocks” or “chunks” (see Section 2.3). Despite RunEncoding, RPE or RLE being inherently segmented, this is a variable-length and data-dependent segmentation; to better reflect existing systems, we need to consider the application of an artifical fixed-width segmentation to a column before applying one of the run-based schemes. The price of this pre-segmentatization; Non-negligible decompression overhead, and no chance for exceedingly-high compression ratios with extremely-long runs. But there is also a significant gain: In addition to the bounding of search lengths, the capping of run length and the fact that position offsets are relative to the segment, so both RLE and RPERunPositionEncoding now require less bits per run — which changes the trade-off between them somewhat in favor of RPE.
Implicit sub-segmentation
In this variant we stick to the single segmentation inherent in RunEncoding-like schemes: The runs. Instead of adding a second segmentation, we break up existing runs into smaller runs — so that it becomes also a sub-segmentation of a uniform -segmentation; that is, whenever a run contains both the \xthand the \xthelement - we break it into two runs on the length- “segment” boundaries. The decompression circuits for RunEncoding/RLE/RPE can be used as-is for these schemes. Also note that applying this sub-segmentation to RLE column after this refinment, and adjoining as a scalar, results in an instance of the CappedRLE scheme mentioned above.
Splines: segmentized generated functions
We’ve just explored compression schemes using the segmentization of Constant — RunEncoding, RPE and RLE — representing columns as consecutive uniform-value runs. Recalling that columns are simply functions, we’ve in fact been discussiong representations of step functions. In Subsection 3.4.2, we generalized from constant functions to elements of linear spaces of basis functions, such as low-degree polynomials; and we now do the same in the segmentized context. Indeed, we will use the well-studied generalization of step functions (to low-degree polynomial functions): The spline.
In fields such as computer game graphics, industrial design and typography, one often wishes to model curves (or surfaces in 3-dimensional space) using polynomial functions. However, high-degree polynomials are harder to reproduce physically and slower to compute; also, they typically exhibit high-amplitude oscillation between their points of constraint, particularly near edges of the intervals of definition (Runge’s phenomenon [DB74, §4.3.4]). It is thus usually more convenient to subdivide the domain, and use multiple low-degree polynomial pieces, one per segment, rather than a single high-degree polynomial. Historically, their use arose from physical splines: pieces of wood used in craft design which would bend into the minium-energy form, while being bound by physical constraints of position and angle at their endpoints. For an exposition of the historical development and varigated uses of splines, see [DB01].
A similar principle is relevant for data compression also: If the data has a certain shape locally, be it a gradually-changing shape or with points of discontinuity — this overall tendency or shape would be captured relatively well by a spline, at a certain resolution of segmentation (whether fixed or variable, and with or without continuity and smoothness constraints).
The proper segmentization of yields the following scheme:
*[GeneralizedSpline_→f]
Label Type Length Description
segment_start_pos of the first element of each segment
segment_length Non-negative number of elements in each segment
coefficients
a concatenation of sequences of coefficients for the
basis functions in , forming a different function for each
segment.
Spline
The case of where the basis functions are monomials, i.e. .
These schemes have a somewhat redundant representation — similarly to the case of RunEncoding. We may compress it further by dropping one of the two columns of the segmentation. Here we spare ourselves the dilemma by following the traditional formulation of splines, which focuses on knots, the pointes delimiting the segments:
*[KnottedSpline_k]
Label Type Length Description
knots start/endpoints of segments
coefficients
a concatenation of sequences of coefficients for
the polynomials
The first knot is always [math] and the last is , with being the uncompressed column length.
*[EquiknottedSpline_k]
Label Type Length Description
interval_length the distance between consecutive knots
coefficients
a concatenation of sequences of coefficients for
the polynomials
The uniform-segmentation equivalent of . The last interval may be shorter than the uniform length.
and we could similarly define knotted versions of GeneralizedSpline.
Spline functions are technically a generalization of step functions — which are captured by the segmentized Constant scheme. And yet, in practical use, it is in fact the step-function-describing RPE and RLE schemes that are effectively the more general, or rather more widely applicable directly. This is due to their being much more “forgiving” towards diversions from the modeled function: If some elements do not fit the current (constant) step/run value - we may simply add a new run for it, with only local overhead — another run, and possibly breaking up an existing run in the middle. With splines, one needs quite a few coefficients. Also, in practice, one does indeed encouter long stretches of identical values; and possibly some long arithmetic sequences (degree-1 splines); but column data being perfectly quadratic or cubic over some stretch are rare occurrence. Thus, paradoxically, one would tend not to use the generalized scheme as-is, but rather combine it elementwise with small additive “noise” column (as discussed in Subsection 3.2.1).
Smooth splines
Spline functions are often constrained to be continuous curves, i.e. constrained to be continuous at the internal knots. Stronger smoothness constraints are also sometimes introduced, so that the polynomial “pieces” have the same direction at the point of joining (e.g. to avoid jagged edges on the surface of a car or side of a ship, whose contour is set to a spline); and further constraints are sometimes placed on the higher derivatives. These constraints create linear dependencies between the coefficients of the polynomials (or outright equality constraints if we choose another polynomial base, as in B-splines [DB01, Chapter 10]) - reducing the number of parameters necessary per segment. One would typically still opt to keep the full sequence of redundant coefficients for each knot, as failing to do so requires reconstructing them with a pass over previous segments.
Splines with non-integral knots
Monomials — the basis functions for the Spline scheme — can be applied to any positive real value rather than just to the (integral) column indices. The same would often be true for other choices of base functions. With this in mind, one could specify non-integral spline knots — using some fixed-width floating-point type for the knot positions — in the schemes above, or a non-integral interval length for equi-knotted splines and generalized splines. The column values are the evaluations at offsets which are integral relative to each other, but non-integral relative to the knot. This may reduce the complexity of fitting optimal splines to data.
Frame-of-Reference
The composition of with elementwise additive differences (see “noise-signal” separation in Subsection 3.2.1). At every segment, the additive differences can be thought of as offsets from a reference value or a baseline value for that segment — the uniform value of the step function. This special case is commonly known as:
FrameOfReference
[TABLE]
The \xthelement of the uncomrpessed column is \text{offsets}{\left[i\right]}+\text{references}{\left[i/\text{segment_length}\right]}. (Shorthand name: FOR.)
The FOR has been in use by several analytic DBMSes (e.g. Teradata [Mor02] and Vectorwise [ZHNB06] composed with aposteriori patching).
Compressed Differences
Consecutive elements in real-world database table columns are often close to their predecessors: Timestamps; samples from real-world data sources with low energy in high frequencies; arbitrary data after having undergone a sort; and so on. In such cases, each element’s value is a fairly decent estimate for the value of the next one — even if a model for the entire column is not available or is complex. When these element-to-element differences are all integral (or of fixed precision), they may fit a smaller-size type, and the following scheme achieves meaningful compression:
NaiveDelta
[TABLE]
The first element of the delta column holds the difference between the first uncompressed element and the base value (so that the base value is not uniquely determined by the uncompressed column).
As defined, NaiveDelta is not a very practicable scheme: The computation of each decompressed element depends on all previous input elements — possibly millions or billions of them. It is at this point that segmentation comes into play: Instead of a change in any compression scheme parameters per se, we apply it to NaiveDelta to break the chain of dependencies; dependencies will now extend only to the segment boundary rather than all the way to the beginning of the column.
Delta
[TABLE]
The first element of each segment, i.e. \text{delta}{\left[\text{segment_length}\cdot i\right]} for the segment, holds the difference between the segment’s first uncompressed element and that segment’s base value, .
An alternative to segmentizing NaiveDelta, is characterizing the behavior of the differences globally rather than locally — with model functions as in Subsection 3.4.2 above. But that is not, in fact, a different compression scheme — as a characterization of the derivative as a span of basis functions is the same as a characterization of the underived function, with the anti-derivative of those basis functions (up to a global constant). Thus, NoisyGenerated may be a reasonable alternative to NaiveDelta; and while both can be segmented, it will be less essentiall to do so for the latter scheme; NoisyGenerated would also be much easier to decompress, with its work being elementwise.
Patching segmentized differences
The long dependency chains created by representing differences rather values remains somewhat problematic even with segmentatization. In addition to the limits of the parallelization of decompression, the use of (aposteriori) patching also becomes difficult. To illustrate, suppose are integeral types and that . Now suppose we wish to compress a column made up of occurrences of [math], followed by at least occurrences of . One can show that at least patches are necessary to bring all consecutive pairs of elements to within of each other; consequently, at least aposteriori patches must be made to a Delta-compressed form of this column. If, instead, we were to patch the compressed column — after casting it into rather than values — this would require only a single patch at index .
The adjoining a subcolumn in standard representation to the compressed form of Delta, of patches to be applied as we’ve just described, defines another compression scheme — PatchedDelta scheme or PDELTA for short. A non-columnar equivalent of this scheme is defined in [ZHNB06, §3.1] as PFOR-Delta.
Segment-local dictionaries
Segmentation allows mid-column changes in a compression scheme’s parameters. In subsubsection above we described the localized modeling of a column in a space of low-degree functions — fitting a different model for each segment. We now turn to a different assumption of local “well-behavedness”: An assumption regarding the column support set.
For example, consider a column of type with a poor (discrete) modulus of continuity, for which one cannot provide a well-fitting model using typical base functions (e.g. polynomials), even if one were to allow for a narrow noise column. But suppose also, that despite its discontinuous nature, the column’s support set does exhibit locality: There exists a neighborhood width around each position in the column, such that the local support size in each of these neighborhoods is significantly less than .
To exploit this locality, we break up the column into contiguous segments, each of which with its own hopefully-small local dictionary: Not too large, so as to limit the size of the support set; but not too small, so as not to incur excessive storage overhead for the dictionaries, nor hurt the decompression speed overmuch by having to read them. Keeping one dictionary for each of these segments results in the following compression scheme:
UniformSegmentDictionaries
[TABLE]
Decoded similarly to Dictionary, except that the dictionary entry index is not , but rather \text{indices}{\left[i\right]}+\lfloor i/\text{segment_length}\rfloor\cdot d.
This local-dictionary scheme is used essentially as-is, albeit not in columnar formulation, in existing systems (e.g. Oracle [PP03] and Vertica [LFV*+*12]). It also has quite a few possible variations, or further developments:
De-duplication
We can constrain the per-segment dictionaries to have no duplicate values and/or to be sorted — allowing for the local-dictionary indices to serve as surrogates; these would be the same constraints described in Subsubsection 3.1.2.1 for the case of a single all-column dictionary. Note, though, that the surrogacy in the segment-dictionaries case would be limited to the relevant segment: The comparison of indices into dictionaries of different segments does not yield a meaningful result.
Patching
The segmented dictionaries scheme relies on complete disappearances of elements from support sets from segment to segment. In some real-life cases, this does happen; for example, when batches of data in a column are inserted in large batches from different “categorical sources”, where the support for different categories is distinct (e.g. records involving activities in one country and records involving another country). But if the column’s support has a more continuous behavior, disappearance will not be complete; Instead, we’re more likely to see supports with the vast majority of weight on a small set of values, and some weight on a large set of very-infrequent values. In other words, the segment support sets will not be small, but the frequency functions of values in the column will have almost all of their weights on a small set each. To be able to ignore the distributions’ “tails”, we may use patching. The patches can theoretically be themselves segmentized rather than being column-global , but it is not clear whether this segmentation is particularly useful, so all-column patching seems more attractive.
Variable-length segments
We’ve made an off-hand choice of using a uniform segmentation with the local dictionary, but we can also opt for a non-uniform segment length (see Section 2.3). Such a choice may be relevant if the changes in the local support set are themselves non-uniform, i.e. if there are long stretchs where the support set hardly changes, and others where it changes at a faster pace. Remember, however, that instead of adding another level of indirection, one can also consider patching for some problematic parts of a column; increasing the dictionary size, effectively obtaining a slower change; or using a two-level dictionary (see below).
A particularly interesting scenario where the locality of support breaks is that of a discontinuity in the occurrence frequency function: After a certain element, the support set changes abruptly, perhaps even completely (and typically, this may not be aligned with a segment end). Variable-length segments seemlessly addresses this case — but it can also be handled by a doubling of the dictionary size: If the discontinuities are at least segment_length elements apart, a double-sized dictionary could have both the current segment and the next segment’s support set covered, disappearing the discountinuity. Again, this is a trade-off between read-after-read dependencies, bit width, alignment of values (the doubling means an extra bit) and other compression scheme parameters.
Two-level dictionaries
A drawback of UniformSegmentDictionaries, as defined, is the amount of space necessary to store all of the dictionaries, especially when the segment length is not very high relative to the dictionary size (due to relatively weak support set locality). Also, a global support set which is itself compressible, or when the original column has very large elements or variable width — adversely affect the storage of segment dictionaries in terms of complexity, size or both. Both these issues may be addressed by composing UniformSegmentDictionaries after an application of Dictionary to the uncompressed column. The first level of dictionary use — the global dictionary — results in fixed-width integers, regardless of the original element type; and pre-reduces their sizes in the second-level dictionaries – the segment dictionaries.
Such a two-level scheme (with de-duplication and sorting) is used in the Google PowerDrill column store [HBB*+*12, §2.3] (again, in a non-columnar formulation). Specifically, schema columns are physically partitioned into “chunks”, each one being much more complex than a plain column.
Compression of the segment dictionaries
The overhead of storing a dictionary per each segment poses a dilemma: If our segments are short, we may need to store so many dictionaries that the space taken up by dictionary_entries is of the same order of magnitude as the space taken up by the indices column, compromising the compression benefit of the segment dictionaries in the first places. On the other hand, if segments are long, the dictionary for each segment must be larger, as we lose some of the effect of locality; and while the dictionary’s size is offset by the lower number of dictionaries — the dictionary index width will increase as well, dragging the overall compression ratio down.
One can conceive of several ways of circumventing, or resolving, this dilemma:
- •
Expand the dictionaries slightly (hopefully without increasing the dictionary index size) beyond the size necessary for our fixed choice of segment length. Now, construct ‘union dictionaries’ of the dictionaries of consecutive segments, which can be used for stretches of several consecutive segments. We could then apply RunEncoding or RLE to avoid duplicating these dictionaries.
- •
Make some effort to reduce the number of distinct dictionaries (e.g. by creating “segment union dictionaries” as in the item above). Avoid the repeated use of the same dictionary using a dictionary-of-dictionaries, i.e. adjoin a column with one element per each segment of indices, indicating the index of the dictionary to use for that segment; the distinct dictionaries, having some fixed size, are concatenated in dictionary_entries.
- •
We’ve been treating the different dictionaries as perfectly distinct stretches of data, despite them being placed together in the same column. We could remove this constraint, and allow a dictionary to start at an arbitrary position within the dictionary_entries column. Thus less-frequent elements at the beginning of a dictionary may be discarded by moving its starting index up, but not all the way, so that many or most elements remain. The dictionary length will also be set so as to introduce the appropriate amount of new elements, and possibly also to re-introduce elements which were lost at the beginning but are still necessary; at the same time, we’ll need to avoid enlarging it too much to avoid widening the indices into it.
This approach complicates the compression somewhat, as one must tackle the combinatorial challenge of choosing a dictionary index width for which the exist a satisfying placement of elements: Such a placement must include enough redundant appearances of values to capture segments’ support, but not too many appearances so as to spoil the overall effect of dictionary overlap.
- •
Instead of storing entire dictionaries, store the differences between consecutive dictionaries (i.e. which elements were added and which removed); due to the locality property, and the choice of smaller segment length, consecutive dictionaries mostly overlap (if we ignore placement within the dictionary), on the average. Thus, on average, their differences should take up little space. For more on the use of differences in compression, see Subsection 3.4.3 above.
… and if this option reminds the astute reader of Intra-frames and P-frames in MPEG video compression [DL96] — the analogy is not without merit.
Exploiting non-uniformity in frequency distributions
In seeking features to exploit for compression, and particularly in considering a column’s support set, we have so far mostly ignored the frequencies of values appearing in the column: We’ve ve treated each of them as equally worthy of compression, with an equal potential benefit from compression; and the only allowance for infrequency we’ve presented is patching, which is useful removing extremely-infrequent elements entirely. In other words, we’ve mostly ignored the non-uniformity of columns’ frequency distribution (as per Subsection 1.1.1).
We begin with a classic (non-columnar) approach to exploiting such non-uniformity for coding — using elementwise variable-length coding of the originally fixed-length data, so that frequent elements use less bits. Then, in Subsection 3.5.2, we consider a conceptual of “transposition” of the above, where instead of having one variable-width column, we have a multiple, uniform-width columns, but of decreasing lengths, i.e. where some elements “end” in an earlier column. Finally, we focus on a single aspect, or step, of the multiple-column approach, involving a two-way partition of the frequency distribution function, that is useful in itself as a building block for compression schemes, and is in a sense the complement of patch removal; this is Subsection 3.5.3.
Note*.*
In information-theoretic terms, in this section we exploit low (Shannon) Entropy [CT12, §2.1] of columns’ element distributions.
Huffman-like encoding of variable-width columns
Given a column with highly non-uniform element frequencies, it may be worthwhile to apply an elementwise approach of exploiting this non-uniformity: Having frequent elements be represented in less space and infrequent elements taking up more space than in the fixed-width representation. This is an extremely common technique in communication and (serial, non-columnar) compression, particularly using the Huffman code [Huf52] for representing elements; this code is optimal for symbol-for-symbol prefix codes (see [CT12, §5.8]. A similar choice, for the additional constraint of preserving the relative order of the unencoded values in the encoded form, is the Hu-Tucker code [HT71, Hu82].
But what is a straightforward in a serial context is not to be considered lightly in parallelism-focused computational computation: Variable-size rather fixed-size representation of data comes at a cost, of either extra space or extremely poor amenability to parallel decompression. With our standard representation of variable-width column, see Subsection 2.4.4) we pay in a significant amount of extra space, to indicate element positions or lengths. Without those indications, however, it would generally not be possible to start inspecting the variable-length data at some mid-point and determine where an uncompressed element starts or ends; decompression would therefore have very long dependency chains to follow over numerous compressed-form column elements.
Two approaches for achieving a middle ground between minimum size and more shallow data dependencies are:
- •
Use of periodic, rather than per-element, position/length indication (a-la FrameOfReference or Delta); between these indicators, decompression is almost impossible to parallelize, in that one cannot determine where elements start or end by examining them from some midpoint between the indicators.
- •
Interspersing synchronization elements between actual compressed column elements, which can be identified with certainty even when the input is read starting at an arbitrary position. Without delving into the details, applying this code-theoretic concept would be based on the exploration of the subject in [FR84, Tit97]; but would differ due to our ability to pre-transform the column to enforce certain features or remove certain artifacts, using patching; this may allow for simpler decompression, or for an improved upper bound on the compression ratio relative to the classic case.
Finally, note that compression using variable-width columns can exploit more than the mere element frequency distribution, but rather than frequency distribution of pairs, or longer sequences, in the uncompressed column. This would bring it somewhat closer to Lempel-Ziv-style compression schemes [ZL78].
Cascading dictionaries
We wish to benefit from using a shorter representation for more frequent elements — but perhaps we are loath to sacrifice so much of the uniformity and regularity of fixed-width columns, which is required for Huffman-like coding. In this case, we may adopt a compromise: Fixed-width columns, but several of them, or rather, several complementary subcolumns — each with a different width. Of course, the representation in each width would be a fixed-width number, or more specifically: An index into a Dictionary. Elements will be assigned indices to these subcolumns (and given a dictionary entry) based on the frequencies in the uncompressed column.
Consider the first, narrowest dictionary, ; its index width is bits, and it covers an fraction of the column’s values. One of its entries, however — we’ll choose entry 0 for simplicity — is reserved for indicating that an element is not covered by the dictionary. We may think of the indices column of the Dictionary scheme also as a dense subcolumn representation (if we were to check it for equality with 0, elementwise). After these elements have been added to the dictionary and the problem resolved, we remain with the task of compressing merely the fraction of the values which do not appear in , as a contiguous column. If the residual subcolumn still meets the criteria of this section (non-compactable support set, roughly obeys a power law) — the process may be repeated: Dictionary , with bits covering of the subcolumn; and again, a new residual subcolumn is formed, to be compressed further.
*[CascadedDictionaries_k]
Label Type Length Description
upto Entries of the dictionary
… … … …
upto Entries of the dictionary
-bit integers
into ; an index of 0 indicates
elements to be set in later phases.
… … … …
-bit integers into .
Decompression occurs in phases, each using two circuit inputs columns, and , and an additional, intra-circuit, input — one of the outputs of the previous phases. The phase produces two outputs: , for use in the next phase, and a sparse-representation subcolumn . The phases can be interpreted as successive application of SubcolumnOverlay. The final phase’ output is empty, and is not used.
The \xthphase gets the positions of those output column elements which have not yet finalized, from . It partitions this set of indices into two subsets: Indices to be finalized in this phase — — and indices left for later phases — . The partition uses : An index is placed in if , and in otherwise. The phase concludes with Dictionary decoding of and .
An initial implicit column, , is the identity column for , i.e. initially, all elements are still not finalized. The disjoint subcolumn union constitutes the decompressed column in default subcolumn representation.
We have not described an exact procedure for partitioning the elements into subsets. Naturally, the earlier dictionaries involve the more frequent elements; but the number of dictionaries and their index sizes in bits must still be determined — a process in which one may trade off a better compression ratio for fewer dictionaries and thus shallower dependencies of the decompressed column.
Note*.*
The idea of partitioning columns by element frequency, to be able to use shorter-width dictionary indices for more frequent elements has already been adopted in lightweight compression in a DBMS context: IBM has used a “frequency partition”-based compression scheme in its BlinkDB system[RSQ*+*08, §III]. The scheme is rather different from CascadedDictionaries: BlinkDB is a row store, so the scheme there is applied to tuples; also, it compresses without preserving tuple order, so that the relative position of the various tuples is not encoded. With this said — it is an interesting composite scheme also involving Delta, which could be expressed in terms of the basic schemes and composition patterns presented in this chapter; and the discussion of partition formation [RSQ*+*08, §3.b] is also of interest.
Small-dictionary fitting
While the CascadedDictionaries scheme discussed in the previous section, is certainly of some utility, its definition involves something possibly even more useful: The single phase of its decompression, with a decoder as per Figure 3.8(a). Instead of its repeated application on residual columns, let us apply it just once, and assume the decoded values for the residual are available explicitly:
SubcolumnDictionary
[TABLE]
When decompressing, dictionary and indices are treated just as in the Dictionary scheme: — except for the elements of ; these have individual values provided, in order of their position, via the residual_data column.
We can indeed formulate as a repeated composition of SubcolumnDictionary with itself, times — with the appropriate subcolumns and bit widths ), and dropping the empty final residual subcolumn.
SubcolumnDictionary alone will not yield a good compression ratio unless the dictionary covers almost all column elements. But even if it leaves out a sizable fraction, it is a prime candidate for composing with other encoding schemes, a procedure we refer to as small-dictionary fitting. Such a separation of a column into an “easier” and “harder” part immediately reminds us of the patching procedure (described in Subsection 3.2.4); in some senses, they can be seen as each other’s converse:
[TABLE]
Small-dictionary fitting can therefore take its place alongside the fundamental, or commonplace, scheme composition and transformation patterns in Section 3.2.
Further compression of scheme-generated auxiliary columns
Patch positions — sparse index subsets
Patching, described in Subsection 3.2.4 and used in several concrete schemes presented in this chapter, has a very steep space overhead per patched element: We need to store not only the full-size uncompressed element, but also an index into the uncompressed column. And the more effective the main compression scheme, and the longer the column — the more “painful” this extra overhead of specifying the patch position becomes. As a consequence, naive patching — a subcolumn of patched value in SparseIndexSet representation — is only beneficial with very low fractions of values to patch in a column.
Luckily, index subsets which aren’t extremely sparse tend to be amenable to some compression, due to two characteristics: They can be arranged in monotone-increasing order; and the denser they are, the lower the arithmetic differences between subsequent indices are on the average, even well below the density at which one might consider switching to a dense representation.
To simplify the exploitation of these two properties, we focus on long common prefixes of indices’ binary representation — since if subsequent indices are close together, then on the average (though with slightly lower probability) they share a long common prefix. Indeed, we can define a family of representation schemes concretizing the prefix-agreement by grouping together the representation of identical prefixes:
*[Carve_w,p] Let be the function carving -bit values into their higher and lower and bits respectively — that is, defined by . is an alias for with .
*[CommonPrefix_w,p]
Label Type Length Description
prefix unsigned integer, bits each to be prepended to multiple suffixes
suffix_count unsigned integer, bits Number of suffixes for each common prefix
suffix unsigned integer, bits each preceded by the appropriate prefix
With this scheme, (encodings of) indices appear in order of index value. As consecutive indices tend to share their higher (more-significant) bits, we apply a operator, carving each width- integer into its higher (or prefix) bits and its lower (or suffix) bits is performed. The column of high bits of patch positions exhibits (hopefully long) sequences of identical values, so we apply RLE to it. The lower bits column remains untouched, completing the encoding. This procedure is clearly reversible, up to the sorting — but sorting maintains the equivalence of the standard representations of index sets, so it unnecessary when decoding.
Note*.*
The reader may notice the similarity between the scheme and FrameOfReference. But the two schemes are fundamentally different in that the former only represents index sets, or ordered column of integers — not arbitrary columns. Another difference is the non-uniform number of represented indices with each prefix, while in FrameOfReference that number is fixed.
An index subset representation in this family may take up as many as bits per element. This worst-case occurs when , i.e. when each element has a different prefix: In this case, each element requires bits for the actual carved-up element and bits for representing the length of the one-element subset. This fact seems to motivate a shorter prefix, to ensure more indices end up in the same set — contrary to the basic motivation of sharing longer prefixes among many index set elements.
We can balance the contradicting motivations for a shorter and longer prefix by using multiple distinct (and disjoint) index sets: Each encoded in CommonPrefix (or naively), with the same value of but different values of . Choose, with foresight, two values: [math] and . This choice results in the following compression scheme for index subsets:
*[CommonUpperHalf_w] Each element of the subset to be compressed is placed in one of two index subsets. The first of these is in the naive representation (and corresponds to no common prefix), while the second is represented using (we assume is even for simplicity). The choice of placement for the different values depends on the density of the original index set’s intersection with each consecutive -aligned sequences of elements (i.e. the subsets of elements which all share the same prefix): If an index value is the single one within its -aligned sequence, it is placed in the first index subset; and if there are multiple elements, they are all placed in the common--prefix index subset. The subsets are disjoint, so a decoder can simply concatenate the decoded standard representations of both subsets to obtain the original one.
For each one of the possible prefixes, we have either: No elements or one element in the first index subset, with width ; or at least two corresponding elements in the prefix and suffix_count columns of the second index subset, whose widths are each, i.e. overall; or none of the above. Thus, a total size of bits. This does not account for the elements in suffixes over the first two elements for each suffix; their size is bounded by . The overall size per element is therefore . If , the size per element is — asymptotically half of the naive representation.
Returning finally to the context of patching, suppose a column of length , has of its values requiring patches. With , the amortized per-element overhead (in bits) of storing patch indices is — so that, asymptotically, the patches require about half as much space as their naive representation. To make this more concrete, suppose that that (which, for , means ); the index representation size per patch element is then under , rather than the full for naively-represented indices.
Note*.*
Common prefixes are a sub-optimal form of clustering the indices together; and so is the choice of only length-0 and lengh- prefixes in CommonUpperHalf. One could, instead, undertake the computation of an actually optimal choice of cluster reference points, and assignment of indices to the clusters. This would be a non-trivial special case of the min-max facility location problem: Even if the optimal number of clusters is known in advance, the best known upper bound on the time complexity seems to be [WS11] — which is extremely prohibitive for long columns. If we also allow for the possibility of switching from a sparse to a dense regime locally in some clusters (as in Roaring bitmap compression [CLKG16]), the time complexity would increase even further.
Element length specifiers
Using a variable-length representation of a column’s elements often yields significant compression ratio improvement; but in the standard representation, and other compression schemes, this is offset by the significant overhead of storing elements’ start positions. In the most useful cases of variable-width columns, the frequent elements only use a few bits — in which case the starting positions takes up more space than the data itself. Thus, to effectively compress variable-width columns, they themselves must be compressed.
Fortunately, the element lengths, taken as a column, are often amenable at least to some of the simpler compression schemes, or a combination thereof: The range of extant element length is usually limited, and only as many bits as the logarithm of its size is required. Achieving this might requires using something like Dictionary in the general case, but often that’s not necessary, since the possible lengths are very dense in a certain range, thus FrameOfReference (see Subsection 3.4.2) followed by DiscardHighBits produce a near-optimal compression. The segmentization of the FrameOfReference scheme may also come in useful, if the length distribution changes gradually.
Shaping element lengths by padding
Beyond the straightforward approach above, there’s a special feature of some variable-length representations which may be utilized to further improve the compression of a column of their length indicators:
- •
For unsigned integers, in the ubiquitous base-2 bitwise representation, a representation can always be padded with 0’s as the top bits without changing the value.
- •
The case of signed integers with two’s-complement representation is similar, but using the sign bit for padding.
- •
Text strings are usually represented in character set encoding schemes which allow for indicating the end of the string with a special value; this is commonly the “null character”, or the numeric value of [math]. It can be repeated past the end of the string for padding.
For these kinds of data, the representation of an element can always be extended to a longer length without altering the value. We can thus trade off extra bytes in the element data column for a better fit to compressible patterns in the element lengths column.
This upwards-flexibility of element lengths is exploited in several well-known, non-columnar lightweight compression schemes: The 4-Gamma and 4-Wise NS schemes element widths for consecutive sequences of 4 elements (to the maximum of the actual widths); SIMD-128 and SIMD-FastPFOR go as far as setting a single length for sequences of 128 elements [DHHL17]. These all incur a significant penalty in compression ratio, however, when the compressed data is not locally uniform in width. Combining this with the fact that variable-length representation only makes sense to begin with when the element distribution is somewhat power-law-like, one is led conclude that the approach of these schemes is somewhat questionable in terms of achievable compression ratio. As an example, consider a column in the distribution of length exhibits a Geometric distribution with parameter (with minimum value occurring with probability ); and that we set the maximum length in bits every consecutive elements. Letting be the maximum width of some sequence elements and be their individual widths, we have
[TABLE]
Taking (as in 4-Gamma, 4-Wise NS etc.) and (i.e. 90% of the data takes up at most one byte), we would have an expected of and expected single-element length of about . That would be worse than doubling the amount of space used for the actual compressed elements. This is rather dismal! … of course if the element lengths are more likely to be identical to the predecessors or successors, such compression schemes can make sense.
Let us, therefore, describe a columnar compression scheme in the same vein as 4-Gamma, 4-Wise NS, SIMD-128 and SIMD-PFOR [DHHL17]:
PeriodicallyVariableWidth
[TABLE]
Each sequence of period consecutive elements of the encoded variable-width column have the same size: They each take up type- elements in data. The same is true for the last few elements (which may be less than period in number). total_length indicates how many variable-size elements the decoded “column” actually has.
Uniform element lengths via separate subcolumns
The performance pitfalls of the schemes mentioned above (including PeriodicallyVariableWidth), along with their requirement of computing a prefix sum over element lengths, motivates the consideration of alternative approaches. One that immediately comes to mind when we recall Subsection 3.5.2 is the “transposition” from variable-length elements to multiple (sub)columns of uniform width. In our case, we can reduce the number necessary columns by padding elements of less-frequent widths — while elements of frequent lengths should not require such padding. The overall number of columns should thus be limited. The down-side of such a scheme is the need to store the position of all these elements. This detriment may also be reduced by some creative use of padding: It is cheaper (possibly much cheaper) to pad an element by another bit (or basic column element type) than to relegate it to a subcolumn of patches.
Multi-column compression
This chapter has mostly been concerned with compression schemes for a single column (with the half-exception of variable-width columns). Using single-column schemes on a table yields one separate and independent compressed representation for each one of the columns; but this separation is often wasteful in terms of space, as some table columns are usually very well correlated. Also, a column store may have use for a copy of several columns in lexicographic order of the tuples they form (see Section 4.2 below). It is thus worthwhile to consider intricating the compression schemes for different columns, to avoid some of the redundancy. Following is a scale of the intensity of such potential intrication:
(Independent representations: Compression and decompression of each column completely disregards other columns. This is the naive approach, directly following our discussion in this chapter thus far.) 2. 1.
Decoder fusion: When columns known to be related are decoded (decompressed), the disjoint union of their decoding circuits is considers as a decoding circuit for a column pair. In this circuit, one may opportunistically locate and remove identical, duplicate operators shared by the different decoders (or apply more involved optimizing transformations). Encoding may or may not be performed jointly also (“enconder fusion”), but that is of relatively minor concern. 3. 2.
Derivative representation: Some columns are compressed under the assumption that certain other related, uncompressed columns are available. At worst, this results in the independent compression scheme; hopefully, only little additional data is necessary over the pre-existing column. When decompressing, the base columns for the derivation, are decompressed first, realizing the assumption. 4. 3.
Co-representation: One chooses compression schemes for multi-column structures, e.g. pairs or tuples of several types — from the outset. The columns are also decompressed all together.
As one proceeds along this scale, compression ratio and speed for related columns together drops, but for the individual columns it mostly rises.
So as to limit the breadth of this monograph, we will not explore concrete multi-column schemes and different patterns of combining single-column schemes, except for a single simple case, immediately below. The reader is reminded that the general problem of optimally combining compression schemes for multiple columns is computationally intractable — just like determining the optimal compression scheme for a single column: These are the problems of computing the plain, conditional and/or shared Kolmogorov complexity of columns as words over a finite alphabet. For an in-depth (abstract) treatment of these fundamental theoretical problems, see [LV08].
Full derivation
Real-life data tables very often have columns which can be perfectly inferred from other columns — even at the single tuple level. For example, a time-series table may have a date column, alongside day_of_week, or possibly year, month and month as separate columns (e.g. in [Sch]). More generally, such columns tend to show up in databases not in the Third Normal Form (3NF, see [Ken83]). A column c is fully-derivable from a family of columns if there is a columnar circuit which, for some assignment of columns from to its inputs, produces c. If, the circuit is just a lifted operator, the column is elementwise-derivable from .
The notion of full derivability can be abused if arbitrary operators are allowed in the circuit, as one can simply define an operator which outputs the desired column; but an appropriate constraint for excluding this case is difficult to formulate, seeing how column stores may generate operators dynamically. Elementwise derivability is a useful restriction of the general definition, both because the prevalence of such columns and because the elementwise-applied function is less amenable to such edge-case abuse. Typically, these functions correspond to multivariate arithmetic expressions with some deterministic mathematical functions available in SQL (such as SIN(), SQRT() and the like).
Chapter 4 Applying the model: Prospective notes
The columnar circuit model of computation we have presented in this work is intended for analysis of existing column stores systems — but also as a foundation for developing new ones. This chapter focuses on what a column store might look like when designed with the model of computation in mind, and which aims to support and benefit from features more consistently and fully. Chapter 3 explored one aspect of these prospects — the use of compression — in greater detail: This was a demonstration of how the model applies to a subject whose study so far has been somewhat fragmented and piecemeal; and which is possible to present in a a relatively self-contained manner. Other aspects of a column store system: Compilation, plan optimization, choices between representation schemes, mutability, execution flow and so on — would require further, more concrete, work to be explored with confidence. Instead, this chapter will touch on these aspects more speculatively, and in brief; these prospective notes may hopefully indicate paths towards actual implementation.
Avoiding materializations: Operator fusion via JIT compilation
A reader concerned with optimizing column store performance may become worried as they browse the previous chapters of this work: Ostensibly, this model suggests a column store materialize results after each and every operator in a circuit. Doing so is highly detrimental to query processing performance, and was a main motivation for the evolution of Vectorwise (initially “X100”) out of MonetDB [ZBNH05]. To make matters worse, the columnar circuits tend to be composed of simpler operators than in existing column stores — increasing the number of intermediate materializations even further.
This stands in contrast to the increasing prominence in recent years of DBMSes effecting compilition of query execution plans into native code : [Neu11] and the implementation in HyperDB [KN11]; MS SQL Server’s Hekaton engine [DFI*+*13, §2.1.3], the MemSQL DBMS [CJW*+*16, §1.1] and others (see also the discussion in [TER18]). While these are not column stores, the motivation is similar: Avoiding a multitude of separate operators applied to ever element or tuple, with unnecessary data movement back and forth. A larger plan made of more operators seems to be the opposite of desirable.
Paradoxically, the copiousness intermediate materialization is intended to achieve the opposite of its immediate effect: The adherence to simple, uniform data structures and the simplicity of the operators maximize execution plans’ amenability to optimizing transformations. Many of these let a column store avoid some computation altogether, or use alternative approaches to the computation of a subcircuit; but afer the system is done with these kinds of optimizations, numerous materializations still remain. It is important to have some final “bake-in” transformations of the resulting circuit: Inverting the decomposition impetus of our approach in previous chapters, these will take subcircuits made up of multiple simple operations and fuse them into single, complex, customized operators, which typically materializes only its final result.
We have, in fact, already described the formal machinery for effecting the above. In Section 1.3, we formalized the transformation of circuits by replacing an induced subcircuit with another circuit having the same function. We noticed the special case of “lifted operator” single-node circuits, and defined the fusion of a subcircuit into a lifted operator. There remains the question of where the implementations of these complex operators are to be found.
The simple, naive approach is for a large set of operators compiled into (optimized) machine-executable form to be determined statically, apriori: The DBMS’ executable files have their final implemented forms before any queries arrive; and complexities such as SQL UDFs are be handled by an interpreter (or an external compiler run [Raa18]). Indeed, pre-compilation of operators is the approach column stores have taken, by and large, thus far: MonetDB, Vectorwise and C/̄Store have all of their machine code compiled apriori, with no additional (“Just-in-Time”) compilation for individual queries.
But while for some column stores apriori-compiled operators may be a baseline option — with the columnar circuit model, and the compositional approach previous chapters have taken — this approach is a non-sequitor: The variety of potentially fused subcircuits is enormous. Furthermore, transformation rules and even some representation schemes may be devised with reliance on the elision of materializations. Thus it is absolutely necessary to generate operator implementations — by JIT compilation of a higher or lower-leve language, or by using compilation results of different pieces of code.
Let us consider a concrete example. A simple, archetypical scenario for compiling execution-plan-specific code is treated in [Neu11] (in a non-columnar setting; and it is implemented by the DBMS, HyperDB [KN11]): A circuit includes two consecutive elementwise operators, and ; and the column store intending to execute this circuit has compiled implementations for both individual operators, not of ; but it is able to fuse the machine code for both operators, with the result being an operator applying to the input. Or perhaps — neither nor is available, but the code for and code for on individual elements is, and the column store can generate a parallelized “for all elements” operator from the code for a scalar. Banking on this ability, the column store may replace the subcircuit containing and with the lifted single operator , maintaining semantic equivalence and circuit output correctness.
There are, however, several important differences between compilation-based operator fusion in the columnar circuit model, and the JIT compilation in aHyPerDB-like system approach:
- •
Non-tree circuits: Columnar circuits are not, in the general case, decomposable into compilable pipeline-segments in the sense of [Neu11, §3.1]; specifically, columnar circuit layouts are DAGs rather than trees, so that the same intermediate column(s) may be used multiple times for different purposes.
- •
Fusion after parallelization: In HyPerDB, operator fusion is a per-record level concept (as in the example of elementwise operators above; although operators like Gather can also be thought of as being “per-record”). With our model, operators can have complex parallelization in their implementation, while still being relevant for fusion. We must therefore allow for more complex memory access patterns in “non-pipeline-breaking” operators (again in the sense of [Neu11, §3.1]) — as otherwise, many of the transformations presented in previous sections would preclude JITing: We would not be able to replace a non-pipeline-breaking operator with an implementation containing “pipeline-temporary-breakers” .
- •
Perhaps most importantly: In existing systems employing operator fusion (and in HyPerDB particularly), much of the computational work is not represented in execution plans: Application of statistical meta-data, combination of hot and cold structures into a single column, specifics of decompression, etc.; such work is therefore not amenable to fusion or JITing. Our model significantly increases the potential for fusion and JIT compilation of these kinds of work, especially as parts of overall query execution plans.
A related, but different, approach to operator fusion can be found in the more recent [FBN*+*18]. The differences are fundamental enough to make a comparison of this approach to HyperDB-style JIT’ing exceed the scope of this monograph (albeit interesting to consider). But this approach is less general than HyPerDB’s, which in turn is less general than fusion in our model.
Finally, recall that both before and after subcircuit contraction, a column store has a columnar circuit to execute. While such circuits expose the potential for parallelism relatively well, the exploitation of this potential on the hardware side is ever more difficult as one considers operators of increasing complexity, on different processing devices, with multiple devices operating at once and cluster-level parallelism. The more sophisticed this exploitation becomes, the more challenging it is to support effective operator fusion. Unlike the trivial case of elementwise work, it may require adherence to certain programming conventions; and perhaps also instrumentation of the compilation chain to keep track of how pieces of code can fit together. Consider the following prototypical example, regarding the complication of even simple considerations: Suppose an operator Op has a GPU implementation involves the execution of two distinct kernels (which cannot be fused together), while a previous in the execution plan, to be fused with Op, is implemented using just one kernel. Should the fused operator employ three kernels, or two? Or maybe it’s even just one, if the fusion obviates somehow the need for two kernels for Op? And if it’s two kernels, which of them will actually get the first operator’s code fused? Such complications abound.
The choice of compression schemes as a nexus of preprocessing effort
A column store with elaborate machinery for representation and compression of columnar data faces a challenge in choosing (or devising) compression schemes for its columns. Even for some single criterion for evaluating schemes, and even when capping the complexity of the scheme (e.g. in terms of compression and decompression circuit sizes and available operator set) — the task is already rather daunting. This is both due to the size of the search space — thousands upon thousands of potential schemes already with the above restrictions — and the difficulty of the very choice between pairs of candidate schemes.
For example, consider an column c of element type , which is close, but not identical, to an affine function, both in average distance and the maximum difference betwee elements — i.e. both by the and by the metrics; and suppose we wish to optimize the compression ratio, disregarding all other scheme features. Which compression scheme would yield a better ratio for column c: Delta, or a GeneratedPolynomial with degree 1 (modeling ) ,with elementwise offsets? If c is perfectly affine, both schemes would have essentially the same compression ratio: An all-zero column of elementwise differences vs. an all-zero column of elementwise offsets; both could use an extra composition with the Constant scheme, which would make the representation “infinitely” efficient. However, we do have some differences from the affine function; which should we choose? The best ratio (ignoring the application of further compression schemes) would depend on the extremal offset values (for the noisy affine model scheme), and on the maximum second discrete derivative (for the Delta scheme). And even realizing that these parameters are to be examined — the dilemma is not nearly resolved, since composition of further compression must be considered. Specifically, if one examines the support sets for the first descrete derivative (i.e. the delta column) and for the offsets in the GeneratedPolynomial scheme, respectively — one of them may be small enough to make an application of Dictionary worthwhile; or the support set may mostly have weight on a small set of values, allowing for one of the approaches described in Section 3.5 for exploiting the distribution skew? And so on.
This confounding state of affairs, already within limited search spaces for schemes, has led other researchers to approach the selection of a compression scheme as DBMSes typically approach the choice of a query plan: Rule-based pruning and strategic selection of composition steps for improvement of metrics or achievement of features; see [FHL10, §4.1].
But Let us venture even farther, and lift the caps on scheme complexity and consideration criteria. In previous chapters of this work we’ve described quite a few (structural) features of a column store which, without the restriction, may induce additional dimensions of complexity to the the choice of compression schemes for the columns in a store:
Compressed-form execution
A key desirable aspect of compression schemes used in DBMSes is their being “lightweight” — easy to decompress despite exhibiting attractive compression ratios. This has guided the entirely of our exploration of columnar compression schemes in Chapter 3 above. We have, however, hinted — and made fully explicit in Section 4.1 above — that we hope to avoid materializing intermediate results as much as possible; and decompressed columns are intermediate results of our columnar circuits when the inputs are compressed. In other words, we would rather avoid actually decompressing our columns.
Several existing column stores have a partial capability to do this, via the “push-down” of operators into decompression routines — so that what eventually gets materialized may be far smaller than the full decompressed column. Selection predicates (and, perhaps, aggregation) are “pushed down” in C/̄Store/Vertica [AMF06, §5.1], Vectorwise [ZB12, §2], MS SQL Server [LCH*+*11], and likely also other systems. This is usually (perhaps always) achieved via custom decompression routines supporting such push-down.
The expressivity of the columnar circuit model allows column stores to surpass push-down optimizations. Since decompression is merely than another part of the larger circuit; and since the compression schemes devised in Chapter 3 are decomposable, and use simple, non-idiosyncratic operators as building blocks — it is often be able to conceptually commute the decompression with the following (parts of) the execution: Simple transformations will get us to a point where we apply a circuit to the compressed form, whose output is the compressed form of applying a subsequent subcircuit in the original plan; and it is the result of this application that we then decompress.
A few examples: If a column is compressed in RunEncoding (or RLE, or RPE), any elementwise operation can be applied to the run_values column only, typically much shorter than the entire column; and a selection by predicate can be applied to the values, positions and lengths columns, which, after having some corresponding elements removed, will now describe a subcolumn, compressed in RunEncoding. Two columns compressed using Dictionary can be Join’ed by computing their individual histograms, Join’ing their dictionaries (resulting in two columns of indices into the original dictionaries, a-la-MonetDB), and using the result to generate the appropriate subcolumn of the cartesian-product histogram. These three columns constitute the Join result — compressed in the Dictionary scheme and with the original dictionary for each column.
Unlike in existing systems, the examples above will not result in convoluted custom operators, which are nearly impossible to involve in further optimization. Instead, it will likely be possible to repeat the commutative process, pushing the decompression further and further into the circuit. Eventually, it may pass some vertex-cut in the circuit, beyond which a full materialization of the original column is no longer necessary. When this happens, the execution plan will have avoided decompression altogether.
Expecting to perform this kind of compressed-form execution, a column store considering compression schemes may assign less significance to maximal decompression bandwidth of a candidate scheme — in favor of, say, better compression ratio. On the other hand, not every scheme is so “permeable” to execution order switching; so that the amenability to compressed-form execution itself becomes a desirable metric in the choice among schemes.
Multi-column decoder fusion consideration in scheme choice
In Section 3.7 we listed several benefits of using joint compressed representations of correlated columns. Even if we refrain from considering them proper, the choice of individual column compression scheme may need to take inter-column correlation into consideration: The less the schemes chosen for two related columns have in common, the less likely the column store is to benefit from potential “decoder fusion”, i.e. avoiding the repetition of similar or identical work when decoding both correlated columns for the same query. Also, given a choice of scheme, we may prefer sub-optimal settings of its parameters — if these benefit decoder fusion with other columns. Examples could be a choice of segment length to fit the segmented representation of another column; choice of base functions and/or their coefficients for a NoisyGenerated representation; or reuse of another column’s dictionary despite it not being minimal for the reusing column.
Multiple (redundant) schemes for individual columns
When faced with several alternative compression schemes for a column, each with different relative advantages and none being overall-optimal — why should a column store only choose one of them? True, holding redundant copies of a column goes against the basic rationale of compression — reducing the amount of memory necessary for the column; but we have already noted this is just one of multiple qualities of a given scheme. Moreover — while more memory would be needed for holding the column, the time required for reading the data from memory by a processor, or loading segments of it into smaller memory spaces, is not increased by the existence of a redundant copy. This possibility expands the representation/compress scheme search space further, now with combinations of multiple schemes translating into different sets of parameters of scheme desirability.
Use of multiple schemes is even more relevant in a distributed setting, where each node only holds some of the columns (or some segments of some columns). As the number of nodes in such a system increases relative to the overall data size, columns will gradually become replicated among the nodes — improving both the availability of nodes with relevant information (needing less initial disk or network I/O), and the reliability / fault-tolerance of the system overall. When this is the case, it becomes even more attractive to choose different schemes for different copies of the column: Such asymmetric replication allows the system to use different copies differently depending on the incoming queries and the availability of computational, memory and network bandwidth resources — without paying the single-node premium of holding multiple copies of the same column: The risk is having the distribution of column replica schemes not match the distribution of “desirable” schemes w.r.t. the query workload.
Such a choice is described in [RDS02, §3], albeit with regards to a secondary disk array: Instead of employing RAID mirroring as protecting from hard disk faults, one stores different representation schemes for the same data (in the case of [RDS02] it was DSM vs NSM representation of tables; see the discussion in [ABH*+*13, §2.2]).
It should be noted that assymetric replication is potentially less robust as a fault tolerance measure: In the symmetric case, we simply need to get the same piece of data from a different replica; if replication is assymetric, however, restoring the part of a column representation stored at a certain node requires not just extra computational work, but possibly data from several distinct nodes.
Multi-column schemes: Derivation, co-encoding
As long as a column store has only one single representation per column, it is likely this will be a single-column, independent scheme; derivative or joint representation would be risky choices, considering the overhead of processing extra columns’ data when they are not even used in a query. But once we have opened the door to holding multiple redundant representations, or if we’re willing to adapt our schemes to the projected workload (see below), It becomes much more realistic for multi-column schemes to be used. This again expands the search space for compression schemes: In our description so far there has been a separate search spaces for each column (perhaps with some allowance for decoder fusion considerations); now it is a single search space, a choice of multiple schemes over all subsets of columns, with the constraint of their union covering every column.
Indices: Ordered multi-column representations
In general, table indices [AS10, §11] are data structures which make it easy to access table records according to a certain order of those records; and they are a key feature in non-columnar DBMSes, both for transactional and analytical queries.
In a column store, an index is essentially a copy of a sequence of columns, permuted into a lexicographic order of the induced records. But — that definition is only true for the uncompressed representation of the index; it would be quite wasteful to actually store a full copy: First, the permuted copy of a column shared its support and frequency distribution with the original column — which may well be enough to consider co-encoding them. Second, within every single column in the index, the lexicographic order induces long sorted stretches of elements, even if not all-column sortedness. Typically, this makes index columns compress very well with schemes such as RLE/RPE/RunEncoding, or something more complex — thus the overhead of keeping such sorted copies is limited. A specific (and useful) case of such index structures is the self-indexing of individual columns, i.e. keeping an extra, sorted copy of a column irrespective of any other column. Compression schemes used on a column’s self-index provide information about a column which may be put to good use when planning queries, even if the sorted copy is not used instead of the column itself. When a self-index is compressed using RunEncoding or RLE, it provides us with a (sorted) representation of the column’s support set. This fact was used for query plan optimization in [AMP*+*16].
Columnar DBMSes differ on the extent of the use of indices: MonetDB only offers support for self-indexing of a single column , and ignores other SQL statements involving table indexes [Monb]). C/̄Store (and possibly, Vertica) takes the diametrically opposite approach: Its integration of indices is so deep, that in the papers introducing C/̄Store, the storage scheme is not even presented in terms of columns, but rather in terms of multiple (relational algebra) projections of tables onto subsets of columns [AMF06, §3], each with some specific sort order. When processing a query, C/̄Store determines which are the relevant projections to decompress (often only a single one), according to the scan orders useful for the query’s execution plan. These projections typically decompose into a “key” and a “value”, in which case the “key” columns are a (multi-column) self-index, and the “value” column is indexd by the multi-column ones. all but the last of the “key” columns in the projection typically exhibit long runs of identical values, due to the lexicographic sorting, and are thus efficiently compressed. However, C/̄Store also always keeps the compressed permutation of the records relative to some basic order, offseting the saving in space somewhat. Also, other than the indices, the columns are compressed independently, so that correlation among the “non-key” columns of the projection is under-exploited [AMF06].
Note*.*
Some non-columnar DBMSes now utilize the column-store form of an index as their own index, to speed up analytic work, employing some upcasting and/or a Dictionary-like compression scheme followed by an RLE-like scheme [LCH*+*11]. The acceleration of non-columnar DBMSes by columnar indices is also explored in [EHRB*+*11, JSD*+*13] and in [ABH*+*13, §4.8].
Workload dependence
Adptation of the physical layout of data to the workload a system expects is both common and useful in row-oriented DBMSes, e.g. in the form of materializing table views and choosing indices/sort orders to index by [AS10, §24.1.6, §24.1.7]. Existing column stores can generally benefit from auxiliary, workload-tuned indexes, and some, like C/̄Store/Vertica, also have “column groups” [AMF06] which can be seen as a limited materialized views, and can be chosen according to an expected workload. This can well be done with a larger space of compression and representation schemes of (permuted sets of) columns: One alters the search or selection process to give more weight features which will benefit the processing of the expected queries with the available data (or expected future data), rather than trying to satisfty abstract general benefits.
A column store could also gradually adapt its choice of schemes to its workload, noticing when an alternative scheme it is now missing would better serve it, and switching at some threshold. This is easier if a column store holds multiple representations of columns, in which case it could “evaluate” schemes on actual data rather than only use analytic assumptions; and it does not have to discard all of its previously-held schemes, so that the threshold for adopting a scheme should not be as high. The practice of column cracking [IKM07] can be cast in terms of gradually refining a representation scheme of a column as multiple disjiont subcolumns (satisfying value range constraints), based on incoming range queries (and the prediction that future queries would be similar).
Port digraph grammars for optimization
A typical DBMS, columnar or otherwise, generates an initial execution plan from an SQL query, then proceeds to a distinct phase of plan optimization (in some systems these are two separated into two phases, optimization of the “logical” / relational algebra plan, and then the selection/optimization of a “physical” plan). [AS10, §12.1, §13]. These optimizations regard a set of operators which is fixed at compile-time, rather than variable and discovered at run-time; and so is the set of attributes, tags or meta-data which the system may compute. Under these circumstances, optimizers (especially for “physical plans”) tend to be implemented as general functions, implemented as part of the DBMS’ codebase, in the same programming language as the rest of its code, and with wide or unrestricted access to DBMS internals.For concrete examples in column stores, consider MonetDB’s default optimizer pipeline [Mon18]; or the compression-related optimizers of C/̄Store [AMF06, Fig. 3].
An alternative approach is exemplified by Spark SQL’s Catalyst optimization engine [AXL*+*15]. Spark SQL is not a column store, and its data model is quite dissimilar to the column-based model in this work; but the developers of Spark SQL’s optimization engine (named Catalyst) prioritized for extensibility and external-developer involvement. They therefore designed the engine to expose the query execution plans to user-supplied optimization rules. Catalyst takes “rules” which interact with the plan in a rather domain-specific fashion [AXL*+*15, §4]; and the results of rule application is eventually JITed along with the Scala code in which the engine is written. However, these “rules” are still really full-blown Scala functions [AXL*+*15, Pha16] which the column store executes.
In a column store following the columnar circuit execution model, execution plans are much more expressive, both in capabilities and in practical use: previous chapters (and sections in this chapter) demonstrate how various structural features of today’s column store can “implemeneted” through columnar circuit execution plans. This implies more (or most) optimization work will involve straightward circuit transformations; it is partly for this reason that we lengthily and carefully exposited circuit transformations in Chapter 1, even beyond what later chapters required. If we also allow for decorating vertices (operators), ports and edges with some property labels that optimization rules can match, the expressivity, and the coverage of optimization rules expands even further.
It is at this point that the need for utilizing a more general-purpose port-graph rewriting system, or (port-)graph grammar, becomes apparent: Without apriori knowledge of the port-digraphs we need to work on, nor of the set of usable vertices (operators), nor of the set of usable transformation rules — we require a mechanism for repeated rule selection and application, coupled with an abstract, general representation of what a transformation rule constitutes. With our model lending itself towards larger graphs and further decomposition than other column stores, match patterns will require some flexibility and may be larger sometimes than two or three vertices. The automation of rule consideration, prioritization, matching and application should prove to be quite challenging to implement efficiently (despite being computationally tractable). The choice of an appropriate formalism for is not immediately obvious, especially considering the variety of established models (see [Roz99, Vol. 1]) on one hand, and with our interest in rewriting rather than derivating from scratch or identifying a language. Going into any detail on this matter, however, would be well beyond the scope of this work.
Mutable columns and column store write support
The columnar circuit model regards columns as immutatble. Rather than columns changing, “new” columns are the result of an application of operators to existing ones, within a circuit. This restriction makes for a stark contrast with the extensive work on mutable, transactional DBMSes, both as practical implemented systems and as objects of theoretical study.
Could we complicate the model to also allow for column mutation? This is, perhaps, conceivable: Changes to input columns would propagate into the circuit (e.g. through an overlaying standard-representation subcolumn, see Subsection 2.2.2) — with operators having to either re-execute, or have a “delta version” execute on the original inputs and outputs, along with the changes. However, such a complication is probably too unwieldy to be worthwhile.
A more palatable alternative is for a column store utilizing the columnar circuit model to allow mutation, but have circuits isolated (in the ACID sense [HR83]) from mutations’ effects. Such isolation would be achieved if representations of mutated columns each contained a complete representation of the original column, which can remain intact (and in-place in physical memory), even as the column mutates. A system applying this principle to each and every change a column undergoes must necessarily utilize versioned data structures (a.k.a. persistent data structure for its columns — as defined in [DSST86], and used extensively in some non-columnar DBMSes, such as LogicBlox [AtCG*+*15].
For the purpose of an analytics-focused column store, however, we can make do with much weaker “isolative” nature of a column’s representation — and we need look no further for it than the schemes already presented in previous chapters. Recalling the discussion in Subsection 2.2.3, we can adapt SubcolumnOverlay, so that an overlaying subcolumn holds appended (or modified) elements; and deleted elements can be represented using an additional index subset representation (see Subsection 2.4.1). Alternatively, the deletions could also be represented by a subcolumn — to be “subtracted” from the SubcolumnOverlay-encoded column; this approach would be similar to that of MonetDB [Bon02] (see also the concise description in [HZN*+*10, §2]): Separate the main read-only data structure for a column (or a projection of columns) from an auxiliary but still columnar structure for insertions and deletions. Occasionally — either every period of time or when changes exceed a certain size — column data will be re-integrated by reconstructing a complete and up-to-date column with no mutations, overlaid by empty insertions and deletions subcolumns.
Other existing column stores use non-columnar representations (delta-structures) for column mutations. SAP HANA, for example, uses two-level structures situated in CPU cache: A row-major delta-table in L1 cache, and a column-major delta table in L2 cache; when the former fills up, it is merged into the latter, and when the latter fills up, it’s merged into the main columns in main memory [SFL*+*12]. Another prominent delta-structure design are the B-tree-like positional delta trees (PDTs) used in Vectorwise [HZN*+*10], which take more after index structures in row-oriented DBMSes rather than actual tables. While these may be faster for transaction processing workloads, they would be more difficult (if not impossible) to make usable with columnar circuits for analytic queries. This difficult is also an explanation of C/̄Store’s choice: Its columns are a Read Store, and a sepate Write-Store — for inserts, updates and deletions — is handled by a separqte non-columnar DBMS — external to C/̄Store proper — which uses B-trees under-the-hood [SAB*+*05, §6].
Execution progression and residual plans
The columnar circuit model abstracts away — at least prima facie — most aspects of execution on real machines. The following, at least, ones must somehow be accounted for when actually computing the output of a circuit (“executing” the circuit):
Operator execution status
Columnar circuits do not define an order of execution for their constituent operators. Operator execution is not instantaneous, and multiple operators may execute concurrently. How should a column store, adhering to the columnar circuit model, keep track of which operators have concluded execution; which have not started execution; and which are currently executing?
Multiple finite memory spaces
Memory is a limited resource, and the faster it is, the less of it real-life machines have. Even if we choose to treat faster memory as cache, and consider secondary storage (e.g. magnetic or flash drives) to be “large enough” to hold all relevant data — we would still not be able to fit the memory spaces on co-processors into a uniform, single-space view of memory. Also, performance considerations demand that column stores take great care to effectively utilize their small, faster memory. How would a column store reconcile this necessity with the hughe uniform columns in the circuits it is to execute/simulate?
Sub-operator-resolution scheduling
Simpler column store execution engines use the operator-at-a-time model for plan execution [MKB09]: A plan operator is executed as a whole; there are no multiple recognized states before its execution completes. A prominent example is MonetDB[Mona], which executes MAL [Monc] instructions in sequence (see Figure 1.3(b); but note that the multi-threaded capability makes MonetDB more of a per-thread operator-at-a-time system [IKG12, §3]). This can indicated trivially by decorating the nodes of a columnar circuit.
Other column stores use finer-resolution scheduling: They operate on relatively small chunks of a column (called “vectors” in Vectorwise [ZB12]; and “morsels” in a further development of this notion in [LBKN14]). For multiple reasons, this choice of chunk-at-a-time execution is quite beneficial, performance-wise, at least on CPUs. However — it is unreasoable to make column-chunks into “first-class citizens” of execution plans, as that would mean plan sizes would be huge — linear in the size of the data. In Vectorwise, and likely in other chunk-at-a-time systems, chunks are not represented in the plan; instead, the column store’s execution engine has the “hard-wired” capability of conceptually breaking columns up into chunks, keeping track of the different chunks, and recombining them after processing into a full column when necessary.
More generally, chunk-at-a-time execution seems to be paired with some idiosyncratic internal representation of query plan execution state. This implies that complex patterns of composition and de-composition of execution — the very ones which are core to the columnar circuit model — do not apply to this finer-resolution representation. The idiosyncracy also implies that very little optimization is possible on the currently-executing parts of the plan — as the column store’s optimizer mechanism is not aware (or not more than superficially aware) of the out-of-plan execution state information.
Splitting operators and circuits
It so happens, that all three challenges described above can be addressed using a single “silver bullet”: A well-developed capacity for splitting. The possibility of splitting an operator and its inputs is not fundamental to the columnar circuit model, and we have barely used it so far in this work (see Subsection 3.4.3 for an exception); but no column store implementation can avoid it.
Splitting operator input columns is less trivial than it seems. First note that a split of a column can result in two or many (subcolumn) parts; the part sizes can be uniform or small “chunk” vs large “rest”; and the resulting subcolumns can be contiguous or form a complex non-contiguous pattern. For a column unto itself, this is still perfectly trivial; and so is the case for splitting, say, an operator. But as the operator’s semantics are more complex, so does the splitting of its input become. A few examples:
- •
(see Subsection 3.2.2): A typical implementation of this operation — and any reduction/fold-like operator — is itself based on breaking up the column into smaller chunks: Compute a sum of the elements in the chunk; (recursively) compute a prefix sum of the chunk-sums, then, for each chunk add the sum of preceding chunks to the prefix sum within the single chunk. Partitioning the input column “outside” the operator merely adds another level of this procedure.
- •
Sort (see Subsection 3.1.2): Similarly to , the computation on each part is a smaller Sort; however, the combination of the parts is more involved — a merging of sorted sequences. Alternatively, one could go through making the two parts into bitonic sequences, then finally merging them into a proper sorted sequence (see [SHG09] regarding the relevance of bitonic sorting in parallel settings).
- •
Gather (see Subsection 3.1.2): While this is not an elementwise operator, it is elementwise operator with respect to its pos input, but not with respect to the data input. If we were to split up data — say, into the first and second halves — we could not then simply employ two Gather’s with the two halves (, ), since some of the indices in pos may be out-of-range; and for the second half, all indices would need to be adjusted. One straightforward approach to handling these difficulties would be splitting pos into two as well, using a filter computed by (the split may not be into halves of course); we then have to subtract , elementwise, from the elements of the second part of pos. Finally, the two Gather-resulting columns need to be re-integrated using the filter vector. (Note this approach is not the only one possible.)
How far do can these split recipes generalize? While they cannot exist for an arbitrary choice of input of any conceivable operator — they do exist essentially for all inputs of the operators we have been using in this work (see the Index of Operators). Moreover, these splits are nothing other than columnar circuit transformation rule with certain specific features; and a simple, localized rule at that. Of course the question of when these transformations are to be applied is a different matter: Some are relevant before execution has occured, but many become relevant during execution, repeatedly. Also, the decision to apply one of these requires additional information besides the circut itself, e.g. information regarding actual column length, execution status and so on. More on this in subsection below.
Splitting single operators also generalizes to subcircuits, i.e. instead of duplicating a single operator, the split inputs of a subcircuit are fed to two, potentially-but-not-necessarily-identical, circuits. This kind of subcircuit-split was used in the system described in [AMP*+*15] for schleduing parts of the data on different hardware devices and/or different threads. But perhaps a more prominent example is MonetDB’s mechanism for multi-threaded execution, named “Mitosis”: Some (easy to split) columns are split up, one part per each working thread, while others are unotuched; and the MAL execution plan (see the example in Figure 1.3(b)) has some of its instructions replicated for each of the split column parts. This is performed as one of MonetDB’s plan optimizers [Mon18], [IKG12, §3].
A precusor to the suggestions here is the effect by the author and others of splits and merges via execution plan transformations in [AMP*+*15, AMP*+*16]. It is also worth noting that MonetDB’s multi-threading is heavily based on involves splitting columns, with the parts visible in the execution plan — a procedure named “mitosis” and constituting an execution plan optimizer [IKG12, §3], [Mon18].
Putting splits to use
With subcircuit splits achievable through a circuit transformation (and no “unsplittable” operators in use) — any circuit is just a few transformations away from having an operator with small enough inputs to schedule a chunk for execution: At most one split transformation per input of the chosen operator. Similarly, the circuit is a few transformations away from having chunks of input columns which can be transmitted to a different memory space where another processor can access them and start working on a chosen operator. In both cases, the splitting can be expanded so that a larger subcircuit may execute using the split-off inputs; also in both cases, the actions above can be repeated several times to allow for concurrent execution on multiple chunks of the data, either using the same initial memory space or in different spaces. An example of both of the above would be concurrent execution of an operator on different chunks by different CPU threads and by a discrete GPU accessing chunks placed in its global memory. (A more simplistic form of such a mechanism was used in the AXE heterogeneous execution framework [AMP*+*15]).
In other words: Using splits, we reduce the challenge of executing circuits a-chunk-at-a-time to the more straightforward operator-at-a-time execution: Operators are only ever executed on input columns which are small enough not to merit further breakup, or tracking of the execution beyond the “awaiting-/during-/after- execution” trichotomy of operator-at-a-time column stores.
It should be stressed that the splitting described above, even when applied repeatedly, does not make the circuit balloon in size, to comprise the huge number of small column-chunks and small operators which end up being scheduled distinctly for execution: Only the single small part which is to be executed next is split-off; most of each column remains in a single large (sub)column; and the chunks already processed are also not kept separate — they too are consolidated occasionally into larger partial-result columns.
Finally, to address the remaining challenges listed at the beginning of this section, we can decorate the nodes and ports involved in splits, to indicate which column lies in which memory space, as well as the “awaiting-/during-/after- execution” status of each operator. Without the splits, each node and port would require complex information regarding what has happened to which part of it; the splits allow for the subsumption of execution engine idiosynctatic complexity by the complexity of of representation schemes for columns and subcolumns, which a column store must already contend with.
Residual state and a streamlined execution flow
A side-effect of represeting ongoing execution state within the execution plans (with the modification of allowing vertex and port tags) is that doing so is essentially maintaining an residual plan: A plan whose execution, given the various columns currently available to a column store, produces the same results as the original query. The initial residual plan when execution commences is the execution plan originally drawn-up; while the final residual plan simply has the final results as an input with no further execution necessary.
Residual plans, being (decorated) columnar circuits, are subject to the same kind optimizing transformations as initial execution plans (and see also Section 4.3). Now, this is also the case, essentially, for operator-at-a-time column stores like MonetDB; but with our model, plan optimizers or optimizing transformation grammars must already be tolerant of columns being being in a broken-up state, represented as multiple subcolumns with their own potentially different representation scheme, and requiring a circuit of computations just to re-materialize again. Thus there is more potential for optimization to be applicable during execution.
Considering our discussion above of the progression of execution using splits, and the potential for dynamic reisudal-plan optimization, we can conceive of the following rough outline for a column store’s plan execution step:
- •
Feeding the processing hardware: If some processor (CPU, GPU, FPGA etc.) is running low on scheduled work,
- –
Find an unscheduled operator with small enough input & output sizes, which are all accessible by said processor, and schedule it.
- –
If none was found, find such an operator but without the restriction on input & output sizes, which could be split up and scheduled
- –
If one was found, apply a split transformation.
- –
If none was found, search for a set of columns to move into to a memory space directly accessible to the proessor, and which would be schedulable
- –
If no such set of columns was found, search for a set of columns which could be split up (or their generating operators split up) so that it would constitute a set of inputs for an operator schedulable on the processor
- •
Feeding communication channels: If some channel or bus is running low on scheduled transfers:
- –
Find a column which one can estimate would could be copied or moved directly over the channel into a more beneficial location.
- –
If one was found, schedule it for transfer
- •
Acknowledging conclusion of computational work: If some operator has completed its execution,
- –
Remove the operator its outputs become assignmed inputs of the circuit. Unused inputs of the deleted operator are marked unused (a later optimization may remove them).
- –
Create new circuit inputs and assign the operator’s outputs to them.
- •
Optimization: Search for an optimizing transformation which could apply to the (residual) circuit. (The search could be longer and/or produce multiple optimizations; or may be timed and shorter, so as not to neglect minding the hardware, and continue the search at a later iteration.)
This procedure is already attractively succinct, considering how it covers decompression, use of index structures, parallel processing on heterogenous hardware, dynamic reoptimization, some memory management (through the deletion of unused nodes) and so on. We can go even further, however, in streamlining the execution step: Recall that most of the conditions-and-actions above are nothing but applications of specific (sub)circuit transformation rules. They may be more “structural” than “algorithmic”; there may be some importance to their relative order, or they may otherwise inter-relate — but then, this can be true for other transformations. We only need to extend our node and port tag sets, to cover not only execution status but location: Which processor is executing an operator, in which memory space a column is located and where it is being trasmitted. With this modification, the execution step can be described much more generically:
Determine out-of-circuit system changes not yet reflected in the plan (e.g. an operator having completed its execution or buffer transfer complete). 2. 2.
Update the residual plan (= residual circuit) to reflect the changes. 3. 3.
Update the (possibly-implicit) space of applicable circuit transformations, including transformations scheduling operator execution or transfers. The update includes the prior probability distributions of benefit for these transformations. 4. 4.
Search, or continue a search, within the space of applicable circuit transformations (including unused input removal, execution or transfer scheduling, a split of an operator or a subcircuit, etc.), and possibly choose to apply one to the plan. 5. 5.
Schedule executions or transfers according to the changes in the residual plan.
In this formulation, multiple generic steps will be taken to cover the different actions in one single step of the longer, more specific one formulated above.
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1[AB 09] Sanjeev Arora and Boaz Barak. Computational complexity: A modern approach, 2009.
- 2[ABH + 13] Daniel Abadi, Peter Boncz, Stavros Harizopoulos, Stratos Idreos, Samuel Madden, et al. The design and implementation of modern column-oriented database systems. Foundations and Trends in Databases , 5(3):197–280, 2013.
- 3[AMDM 07] Daniel J. Abadi, Daniel S. Myers, David J. De Witt, and Samuel R. Madden. Materialization strategies in a column-oriented DBMS. In Proceedings of the International Conference on Data Engineering (ICDE) , pages 466–475. IEEE, 2007.
- 4[AMF 06] Daniel Abadi, Samuel Madden, and Miguel Ferreira. Integrating compression and execution in column-oriented database systems. In Proceedings of the International Conference on Management of Data (SIGMOD) , pages 671–682, 2006.
- 5[AMP + 15] Adnan Agbaria, David Minor, Natan Peterfreund, Ofer Rosenberg, Eyal Rozenberg, and Roman Talyansky. Towards a real GPU-speedup in SQL query processing with a new heterogeneous execution framework. In GPU Technology Conference (GTC) . NVIDIA, 2015. https://www.gputechconf.com/ .
- 6[AMP + 16] Adnan Agbaria, David Minor, Natan Peterfruend, Ofer Rosenberg, and Eyal Rozenberg. Overtaking cpu dbmses with a gpu in whole-query analytic processing. In Proceedings of the International Workshop on Accelerating Analytics and Data Management Systems using Modern Processor and Storage Architectures (ADMS) , 2016.
- 7[AS 10] S. Sudarshan Abraham Silberschatz, Henry F. Korth. Database System Concepts . Mc Graw-Hill, 6 \xth edition, 2010.
- 8[At CG + 15] Molham Aref, Balder ten Cate, Benny Green, Todd J.and Kimelfeld, Dan Olteanu, Emir Pasalic, Todd L. Veldhuizen, and Geoffrey Washburn. Design and implementation of the logicblox system. In Proceedings of the International Conference on Management of Data (SIGMOD) , pages 1371–1382. ACM, 2015.