Column-Based RLE in Row-Oriented Database
Mingyuan An
Key Laboratory of Computer System and Architecture, Institute of Computing Technology, Chinese Academy of Sciences
Graduate University of Chinese Academy of Sciences
Beijing, China
anmingyuan@ncic.ac.cn
Abstract—In database systems, disk I/O performance is usually
the bottleneck of the whole query processing. Among many
techniques, compression is one of the most important ones to
reduce disk accesses so to improve system performance. RLE
(Run-Length Encoding) is one light-weight compression
algorithm which incurs negligible CPU cost. A lot of work
show that, although RLE is one of the most effective
compression techniques in column-oriented systems, it is very
hard to use due to bad value locality in row-oriented systems
where values from multiple attributes are stored in the same
page. We propose CRLE (Column-based RLE), one
compression algorithm to apply RLE to row-oriented data
storage. On row-oriented storage page, CRLE can exploit
value locality in individual column and encode values from the
same column in run-length format. Experiments show that
CRLE can lead to very good compression ratio and
performance in spite of row-oriented data storage.
Keywords-RLE; column-based compression; row-oriented
database; storage
I. INTRODUCTION
In database systems, the cost of disk I/O is one of the
most important factors influencing the whole query
performance. Many techniques in the database are for
reducing the disk I/O. Of these techniques, compression is
one effective approach to improve system performance. The
research in database compression has been around nearly as
long as there has been research in databases [1], and there
has been much work in this field [2][3][4][5][6]. Data
compression trades off CPU power for disk bandwidth
resource, and one should balance the CPU and I/O capacity
to chose an appropriate compression method in a real system.
Although some heavy-weight compression techniques could
lead to much better compression ratios, they may incur too
many CPU instructions and tend to make the system CPU
bound [7]. But with the gap between CPU and disk
performance being larger and larger [1], more so-called
heavy-weight compression techniques have become popular
in practice and database compression has obtained much
attention recently.
Database compression has different effect in row-
oriented systems and column-oriented systems. Researches
comparing these two architectures show that column-
oriented storage are better for compression [1][8][9], and
some important compression approaches such as run-length
encoding (RLE) in column-oriented systems are hard to use
in row-oriented systems. Some work [1][8][9][10] concludes
that RLE could barely be used in row-oriented system.
We propose column-based RLE (CRLE) algorithm which
can apply RLE based on columns in a row-oriented database.
CRLE incorporates RLE into the row-oriented system
compression framework. Experiments on the real dataset and
the synthetic dataset show that CRLE could totally bring the
advantage of the RLE into the row-oriented storage.
II. BACKGROUND AND RELATED WORKS
A. Database Compression
According to whether the data semantics could be used,
the database compression techniques can be classified into
physical compression and logical compression [11]. The
physical compression treats data just as unstructured byte
stream. Before read or after written by the upper query
engine, data goes through the compression module which is
apparent to the query engine, and the compression module
need not know any extra information about the data. Any
kind of compression techniques can be used as physical
compression in a direct way in the database system. To the
contrast, the logical compression takes use of the schema
information about the data when compressing and
decompressing. For example, the data can be taken as fields
not just bytes so that better value locality can benefit the
compression. Because of this better use of data semantics,
the logical compression is more effective than the physical
compression and is more widely used in database systems.
The database compression we discuss in this paper refers to
the logical compression.
In a compression process, one can chose fields or a whole
record as basic compression unit. For example, in Huffman
coding, one field can be a message, or the record can be a
message. Reference [3] is the first who studied the
compression taking the field as basic compression unit. This
kind of compression need only decompress the required field
when querying the data, but it causes some space overhead to
record the variable field length after compression.
Commercial database systems usually use the record as basic
compression unit [2][5][10][12], so the length of the
compressed record could be stored into the length field in the
record header. It should decompress the whole record instead
of just the revolved fields during query.
Popular implementations of compression take page as
compression granularity [10][12]. Sometimes, like for text
attribute, the granularity may be a field [1], which means a
single field value is compressed as a complete compression
process.
The mostly used compression approach is dictionary
coding [1]. It writes all distinct values into a dictionary, and
in the source dataset, each value is symbolled as the index
value of the dictionary. For example, we would use 4 bytes
to represent an IP address, but if in one compression
granularity, there are only 4 distinct IP value, we could use
just 2 bits to represent each occurrence of an IP address.
Dictionary coding is one kind of fixed length encoding, and
decompressing need only lookup the dictionary using the
index code, so it has very high decompressing performance.
Huffman coding [13] creates a Huffman tree according to
the word frequencies, the higher the word frequency is, the
shorter its Huffman code. Using these codes, the whole
compressed data has the smallest expected value in length.
Although Huffman coding can reach high compression ratio,
it is a heavy-weight approach needing more CPU cycles.
Run-length encoding (RLE) packs consecutive same
values into a (value, length) pair to compress the data. For
example, sequence ‘1, 1, 1, 2, 2’ will be encoded into ‘(1, 3),
(2, 2)’. When there exists many runs of the same values,
RLE can lead to a very high compression ratio. At the same
time, RLE is very light-weighted in terms of both the
compression and decompression performance.
Beside the ones mentioned above, there are other
compression approaches used in real systems such as null
suppression, delta coding, bit packing [1][8], et al.
B. Column-Oriented Storage, Row-Oriented Storage and
Database Compression
Traditional databases use row-oriented storage (column-
store) under which all the fields from the same record are
stored consecutively on the same page. Some other databases
adopt column-oriented storage (row-store) [14] under which
values from the same attribute of all records are stored
consecutively on the page, and values from different
attributes are on different pages. Compared to row-oriented
storage, column-oriented storage is read-optimized. During a
query, only the required fields are accessed so that the disk
I/O is reduced.
Researches on column-oriented systems show that
compression in column-store has better effect than in row-
store. In a row-oriented system, values from different
attributes are stored together, and different attributes often
have different value domains. This makes the value locality
on the page very poor. To the contrast, column-oriented
system apparently overcomes this disadvantage which can
lead to good compression result. Dense-packed other than
slotted page format also make the column-oriented page
more compressible [8]. As one of the most important
compression approach in the column-oriented system, RLE
is reluctant to use in the row-oriented system [1][8][10]. That
is because it is rare that there are consecutive identical
records in the storage and it also has no effective method to
compress values from the same attribute of different records,
so RLE in the row-oriented system is often used to compress
the text fields [1].
About which one is better between column-store and
row-store, there is much debate [7][8][9][10]. Actually,
column-store and row-store are optimized for different
workloads. It is impossible that one form take place of the
other form. Many techniques in the column-store can also be
used in the row-store. Row-store can use dense-packed page
format to improve read performance. In the terms of
compression, row-store can compress the data column-wise,
for example, MySQL builds different Huffman tree for
different fields during compression. Dense-packed page in
the row-store also facilitates compression like that in the
column-store [10][17].
All seem available except for RLE. In the case that there
are many consecutive identical values in some attribute, it is
unclear how to exploit this property in row-oriented storage.
No matter whether we take record or field as compression
unit, it will make no sense to use RLE directly. So far as we
know, there is no work on this topic. In the later sections we
will introduce our approach on how to run-length encode the
data based on column in the row-store.
III. COLUMN-BASED RLE
In this section, we will first give a brief introduction to
the storage module and the whole process of compression
and decompression, and then we will introduce CRLE. For
the basic algorithm, we further make some improvement.
A. Storage Module and the Compression/Decompression
Process
CRLE is not limited to the specific storage architecture,
but the whole compression and decompression process
involves many environmental details. So we will give a brief
introduction to the storage module and the
compression/decompression module.
We have a read-optimized storage implementation in
MySQL using the pluggable storage engine mechanism. Our
storage is row-oriented and dense-packed. In traditional
storage, there will be a header for each record which contains
meta data such as record length, variable length field offsets,
et al. We design our storage for fixed-length record, so the
header is omitted in the storage. The page size is set
appropriately so that any record will not cross the page
boundary.
The compression/decompression chooses page as
granularity. Compressed page will be variable in length, so
we need a compression index for compressed data. Every
block offset after compression will be recorded into the
compression index. When access the compressed data, it is
convenient to get the required block using this index.
Fig. 1 is the storage module. When a full table scan is
taken, the compressor will scan and decompress the data in
the support of the compression index. Fixed-length block
after decompression is sent to the page buffer. The tuple
reader parses the record and sends it up to the query engine
in a iterative manner. When an index scan is used, the record
offset got from the index will be transformed into block id
and offset in the block. Through the compression index,
block id is used to get the block offset in the data file. After
reading the compressed block at the offset, the compressor

Query Engine
tuple
Index Tuple reader Storage Engine
Page buffer
Compressor
Compressed data
Compression
index
Figure 1. The storage module.
decompresses the whole block and sends it to the page buffer.
The tuple reader then gets the specific record using the offset
in the block. To the index scan, it will incur some extra cost
because of the page level decompression. This problem
exists when it comes to some compression approaches like
RLE and delta coding. One size doesn’t fit all, and we only
care about the performance of table scan queries.
B. Basic Algorithm
The basic process is to scan the fields of all records, write
out uncompressed fields directly, for RLE fields, make a run-
length recording for the run of the same values from the
same field. Doing this mixes the records together during run-
length encode values from different records.
Here is an example in Fig. 2. The left is the block before
compression. There are 4 records each consisting of 4 fields.
There exists long runs of the same value in the second and
the fourth fields, so CRLE should be used in these two fields.
The right is the data storage after compression. In row-store,
CRLE packs identical values from the same attribute into
run-length format. Next we will describe the CRLE
algorithm.
Assume a record consists of m attributes. Set a counter li
(1 <= i <= m) for each attribute. We refer compressed fields
to the fields on which RLE runs, and uncompressed fields to
the other ones. All counters for compressed fields are set to 0
initially, and other counters are set to -1.
Compression. Sequentially scan every field of each
record, if current accessing field is a uncompressed field, it
is written to the output buffer without any operation; if the
field is a compressed field, read the counter li for this
attribute: if li equals 0, starting from current record, compute
the run length len on this field of subsequent records, write
the (value, len) pair into the output buffer, then assign len – 1
Figure 2. Example of CRLE compression.
to li; if li is greater than 0, it means this value has already
been coded into the previous run-length code, and will be
skipped with only decreasing li by 1 for this attribute.
Decompression. In decompression, we read the input
buffer, and fill into the fields of records in the output buffer.
For uncompressed fields, directly put the next value in the
input buffer into the output buffer. For compressed fields, if
li equals 0, read the (value, len) pair from the input buffer,
then put the value into the next len records in the output
buffer and assign len – 1 to li; if li is greater than 0, it means
the value of current field in the output buffer has already
been set previously and we just skip this field with
decreasing li by 1.
C. Refinement
The basic algorithm is intuitive. But it doesn’t do a
totally sequential access to the buffer, instead it jumps over
the records to handle run-length code. Doing this could cause
two problems:
First, random access to the memory leads to poor cache
performance. Especially when the work size exceeds the L2
cache capacity, L2 cache misses give a considerable penalty.
This means that the compression granularity should be less
than the L2 cache size, while small granularity loses much
compression efficiency for RLE in terms of compression
ratio.
Second, for fixed-length record, random access is easy.
But if we consider records with variable length, it is no easy
task to jump between records. Random access to fields of
records with variable length needs to resort to some kind of
index such as record offset or length information. So it will
cost much overhead using the basic algorithm on variable
length records.
We adjusted the basic algorithm to overcome the
problems. In compression, we use a new counter structure
li{value, len, offset}, where value and len are used to record
the run length information, offset is to record the storage
location in the output buffer for this (value, len) pair. The
initial value of li is set when scanning the first record: for
uncompressed fields, len is set to -1; for compressed fields,
value is set to the field value, len is set to 1, and offset is set
to the current pointer to the output buffer, then the buffer
pointer is added to pre-allocate space for later storage of the
(value, len) pair. Sequentially scan the subsequent records
one by one, uncompressed fields are written into output
buffer, and compressed fields need some process: if the
current field value is identical to li.value, increase the li.len
by 1; otherwise, write (li.value, li.len) pair into the li.offset of
the output buffer, then assign the field value to li.value, set
the li.len to 1, and set li.offset to current output buffer pointer,
in the mean while increase the pointer for reallocation
purpose. Table I gives a brief description of the algorithm.
Accordingly, in decompression, when reading in the
(value, len) pair for some compressed field, it doesn’t
immediately assign this value to the fields of all subsequent
len records, instead it records this information into the
counter li. During the process of sequentially writing the
record in the output buffer, li.value is put into the
corresponding field, and the li.len is decreased by 1 at a time
 TABLE I. CRLE COMPRESSION ALGORITHM TABLE II. CRLE DECOMPRESSION ALGORITHM

Counter l[fieldCount]; Counter l[fieldCount];

for (c = 0; c < fieldCount; c++) // Initiate counters. for (c = 0; c < fieldCount; c++) // Initiate counters.
{ {
if (column c needs compressing) if (column c needs compressing)
l[c].len = 0; l[c].len = 0;
else else
l[c].len = -1; l[c].len = -1;
} }
for (r = 0; r < recCount; r++) for (r = 0; r < recCount; r++)
{ {
for (c = 0; c < fieldCount; c++) for (c = 0; c < fieldCount; c++)
{ {
Read v from input buffer; if (l[c].len == -1) //uncompressed field
if (l[c].len == -1) //uncompressed field {
{ Read v from input buffer;
Write v into output buffer; Write v into output buffer;
current_offset_in_outBuf += size_of_v; }
} else //compressed field
else //compressed field {
{ if (l[c].len == 0)
if (v == l[c].value) Read l[c].value, l[c].len from input buffer;
l[c].len++; Wirte l[c].value into output buffer;
else l[c].len--;
{ }
if ( this is not the first record) // We can extract out }
codes for the first record in real implementation. }
Write (l[c].value, l[c].len) into l[c].offset of the out put
buffer; need to code every value in this column before writing it into
l[c].value = v; the output buffer. So CRLE doesn’t conflict with other
compression approaches, but it actually incorporates RLE
l[c].len = 1;
into the row-store compression framework.
l[c].offset = current_offset_in_outBuf;
current_offset_in_outBuf += size_of_value_and_len; IV. EXPERIMENTS
} The experiments compare CRLE with other compression
} approaches in the compression ratio and
} compression/decompression performance. We also choose
} different compression granularities to analyze its impact on
the compression.
until it reaches 0, then a new (value, len) pair should be read
A. Experiments Configuration
from the input buffer. Table II gives the description of
decompression algorithm. We use two datasets, real dataset A and synthetic dataset
B.
D. Discussion Dataset A is from the network security monitor
To compress based on column, there is another approach. application. The whole dataset consists of about 181,000,000
We can set separate buffers for each field, and physically records each of which has 8 integer attributes. The original
split the record into field buffers. This way actually is much storage used by A is 5.4GB. There are large runs of the same
like a column-store approach. There will be a problem value respectively in five attributes including the time stamp
allocating buffers for all fields. Because fields have variable attribute. This property is the one motivated our research in
length, we have to allocate a big enough buffer for each this paper. Here we don’t describe the detailed data
attribute, and that will cause much memory overhead. distribution of A, and experiments on A are to show the
Alternatively, using just one buffer and compressing all effect of CRLE in real application.
attributes together greatly reduce the memory usage. We give more detailed analysis in experiments on B.
In the CRLE process, for the non-RLE fields, we can also Dataset B is the one used in [10]. It is a TPCH dataset with
use other compression approach. For example, if we want to some skew adjustments. The data comes from the natural
use Huffman coding to compress the first column, we just join of the lineitem, customer and supplier. Seven attributes
are extracted, and they are partkey, l_extendedprice,
o_quantity, o_totalprice, o_orderdate, s_nationkey and
c_nationkey. Introduce some skew into the o_orderdate,
s_nationkey and c_nationkey: (1) 99% the o_orderdate are
weekdays, 40% of that are in the two weeks before
Christmas Day and Mother’s Day respectively; (2)
s_nationkey and c_nationkey are according the distribution
of the statistics released by WTO. There are two reasons of
making these adjustments. First, to evaluate compression,
some data skew is required. Second, it is more real after
adjustments. To better use the locality of o_orderdate, this
attribute is split into the week, the day of week and the year.
The final schema of B thus becomes (LPK, LPR, QTY, OPR,
WK, DAYOFWK, YR, SNAT, CNAT). The data consists of
about 134,000,000 records sorted on the skewed attributes
and uses 4.5GB storage.
We choose two other compression approaches that are fit
for the data property. One is the heavy-weight Huffman
coding, and the other is light-weight dictionary coding. The
Huffman coding we use is Canonical Huffman coding [8, 14],
the one optimized for decoding.
Experiments of compression and decompression are in an
integrated system to avoid the disparity between papers and
real scenes. Compression is done in an offline manner using
the compression program directly on the data file.
Decompression is evaluated by using ‘select count(*) from
T’. The whole running time will be broken up to give
detailed analysis.
The hardware configuration is two way Dual-Core AMD
Opteron™ Processor 2216, 4GB DRAM, 135GB SCSI disk.
The operating system is Linux kernel 2.6.9-42. We use
OPROFILE to catch performance data.
B. Experiments on Dataset A
traditional RLE, the data size will be larger than the original
one because there are barely consecutive identical field
values or records.
Fig. 4 shows the compression time of different
approaches. We denote basic and improved CRLE by
CRLE-1 and CRLE-2 respectively. Before the compression,
source data is not in the memory buffer, and during
compression, the compressed data is written to output file
continuously. We break down the whole time into
compression time, OS relevant time used in system call, and
disk I/O time. The disk I/O time is the I/O time excluding the
overlap part with CPU time. Although Huffman coding need
create the Huffman tree, the number of the distinct values is
very small, and this cost is negligible. So the performances
of Huffman coding and dictionary coding are almost the
same. CRLE is 25% faster than the other two in terms of
completion time, and 1.5~2.5 times faster in terms of
compression time. Because of the better cache efficiency,
CRLE-2 compression time is 33% faster than CRLE-1.
Fig. 5 is the data access time. Before reading, the data is
not in the memory buffer. The init represents the access time
when the data is not compressed at all. When compressed,
the disk I/O is greatly reduced, so the data access is
60%~90% faster than the init. If all data is in the memory
before access, there will be decompression overhead when
using compression than that without compression. However,
in application with large scale data, compression can make
more data reside into the memory, hence leads to a better
overall performance. The access time of CRLE is 20% faster
than that of Huffman coding and dictionary coding. For the
160 io
140 os
compression
elapsed time (sec)

120
We choose 32KB compression granularity and compress 100
on the five compressible attributes. Of the whole 5.4GB, the 80
storage of the data on the five compressible attributes are
3.4GB. 60
Fig. 3 gives the data size of compressible attributes after 40
compression. Three approaches all achieve very high 20
compression ratio. The data sizes are below 150MB. 0
Huffman coding and dictionary coding have similar effect. CRLE-1 CRLE-2 Huffman Dic
Data being Huffman coded is a little bigger than that of
dictionary coding because of the Huffman symbol table cost. Figure 4. Compression time.
CRLE is 10 times better than the other two. If we use
140 80
120 70 io
elapsed time (sec)

db/os
60 decompression
data size (MB)

100
80 50
60 40
30
40
20
20
10
0
0
CRLE Huffman Dictionary
init CRLE-1 CRLE-2 Huffman Dic

Figure 3. Data size of compressible attributes after compression. Figure 5. Data access time
decompression time, dictionary coding is 20% faster than
Huffman coding, and CRLE-2 is 1 time faster than
dictionary coding, 40% faster than CRLE-1.
C. Experiments on Dataset B
Like that on dataset B, we run
compression/decompression on the data and actually data of
five compressible attributes is compressed. Of the whole
4.5GB data, the data size of the five compressible attributes
is 2.5GB. We choose different compression granularities to
give detailed analysis.
Fig. 6 shows the data size of compressible attributes after
compression. Under different granularities, CRLE has a
compression ratio 10 times larger than Huffman coding and
dictionary coding at the best case. For Huffman coding and
dictionary coding, the compression ratio becomes larger
when the granularity ranges from 4KB to 32KB. The
Huffman symbol table cost makes the compression ratio
smaller than dictionary coding. When the granularity is
bigger than 32KB, the compression ratio begins to drop,
because the number of distinct values in one page grows
which makes the codes for the values get longer. For CRLE,
the compression ratio goes up with the growth of the
granularity.
Fig. 7 shows the time of compression under different
granularities. In the chart, in each granularity group, the bars
respectively represent CRLE1, CRLE2, Huffman coding,
and dictionary coding from the left to the right. Because the
CPU L2 cache size is 1MB, the performance degrades when
the granularity is larger than 512KB for every approach. For
Huffman coding and dictionary coding, the growth of
symbol table size is also one important reason for longer
running time under big granularity. Compared to CRLE-1,
CRLE-2 doesn’t vary too much in terms of running time
because of better cache behavior.
The decompression performance under different
granularities has similar property with compression. Fig. 8
shows the access time of compressed data. Access time
becomes longer after 1MB granularity. The decompression
performance of Huffman coding relates to the Huffman
symbol table size, so bigger granularity leads to longer
decompression time. To the contrast, Dictionary coding
refrains from performance degradation because of the direct
index decompression approach. The decompression time of
CRLE-1 varies greatly with the growth of the granularity.
Especially when the granularity exceeds the L2 cache, the
decompression time almost reaches that of the Huffman
coding. CRLE-2 keeps a steady performance whatever the
granularity is.
We can see from Fig. 9 that CRLE-1 has a very poor
cache efficiency when the granularity is larger than 512KB.
This supports the decompression performance finger of
CRLE-1.
Fig. 10 shows the micro-ops executed by the CPU during

250 CRLE
Huffman coding
200 Dictionary coding
data size (MB)

150

100

50

0
4MB
2MB
1MB
512KB
256KB
128KB
64KB
32KB
16KB
8KB
4KB

Figure 6. Data size of compressible fields after compression Figure 7. Compression time

500 CRLE-1
L2 cache misses (million)

450 CRLE-2
400 Huffman coding
350 Dictionary coding
300
250
200
150
100
50
0
4MB
2MB
1MB
512KB
256KB
128KB
64KB
32KB
16KB
8KB
4KB

Figure 8. Data access time Figure 9. Number of L2 cache misses during decompression
 70
REFERENCES
[1] Daniel J. Abadi, Samuel R. Madden, and Miguel C. Ferreira.,
60 “Integrating compression and execution in column-oriented database
micro-ops (billion)

50 systems,” Proc. SIGMOD 2006, ACM, 2006, pp. 671-682.

40 [2] G. V. Cormack, “Data compression on a database system,” Commun.
CRLE-1
CRLE-2 ACM, 28(12):1336-1342, 1985.
30 Huffman coding [3] G. Graefe, and L. Shapiro, “Data compression and database
Dictionary coding
20 performance,” Proc. ACM/IEEE-CS Symp. On Applied Computing,
1991, pp. 22.
10 [4] J. Goldstein, R. Ramakrishnan, and U. Shaft, “Compressing relations
0 and indexes,” Proc. ICDE 1998, IEEE Computer Society, 1998, pp.
370-379.
4MB
2MB
1MB
512KB

256KB
128KB
64KB

32KB
16KB
8KB
4KB
[5] B. R. Iyer, and D. Wilhite, “Data compression support in databases,”
Proc. VLDB 1994, Morgan Kaufmann, 1994, pp. 695-704.
[6] G. Ray, J. R. Haritsa, and S. Seshadri, “Database compression: A
performance enhancement tool,” Proc. COMAD 1995, 1995.
Figure 10. Micro-ops executed by CPU during decompression
[7] S. Harizopoulos, V. Liang, D. J. Abadi, and S. Madden,
“Performance tradeoffs in read-optimized databases,” Proc. VLDB
decompression. CRLE needs much less operations than 2006, Morgan Kaufmann, 2006, pp. 487-498.
Huffman coding and dictionary coding. Due to the [8] Allison L. Holloway, and David J. DeWitt, “Read-optimized
implementation, CRLE-2 takes a bit less ops than CRLE1, so databases, in depth,” Proc. VLDB 2008, Morgan Kaufmann, 2008, pp.
under small granularity CRLE-2 is still a little faster than 502-513.
CRLE-1. [9] D. J. Abadi, S. R. Madden, and N. Hachem, “Column-stores vs. row-
stores: how different are they really?” Proc. SIGMOD 2008, ACM,
V. CONCLUSION 2008, pp. 967-980.
[10] A. L. Holloway, V. Ramon, G. Swart, and D. J. Dewitt, “How to
Traditional RLE is often used in column-oriented barter bits for chronons: compression and bandwidth trade offs for
systems. In row-oriented systems, RLE compresses data database scans,” Proc. SIGMOD 2007, ACM, 2007, pp. 389-400.
from different columns together, so it is hard to achieve good [11] Oracle 11g Data Compression Tips for the DBA. http://www.dba-
compression ratio due to poor value locality. CRLE exploits oracle.com/oracle11g/sf_Oracle_11g_Data_Compression_Tips_for_t
the value locality in columns, so brings the efficiency of he_DBA.html.
RLE into row-oriented system. CRLE doesn’t conflict with [12] M. Poess et al, “Data compression in oracle,” Proc. VLDB 2003,
other compression approaches, but incorporates RLE into the Morgan Kaufmann, 2003, pp 937-947. .
row-store compression frame work. [13] D. Huffman, “A method for the construction of minimum redundancy
Refinement to basic CRLE further improves the codes,” Proc. I.R.E, 40(9), pp. 1098-1101, September 1952.
performance through optimizing the cache efficiency. [14] M. Stonebraker, et al, “C-Store: a column-oriented DBMS,” Proc.
VLDB 2005, Morgan Kaufmann, 2005, pp. 553-564.
Experiments show that the adjustments can refrain CRLE
from performance degradation when the granularity exceeds [15] Partrick O’Neil, Elizabeth O’Neil, “Database: principles,
programming, and performance”, 2nd edition.
the L2 cache capacity.
[16] The MySQL documentation. http://dev.mysql.com/doc.
[17] V. Raman, and G. Swart, “How to wring a table dry : entropy
compression of relations and querying of compressed relations.,”
Proc. VLDB 2006, Morgan Kaufmann, 2006, pp. 858-869.