 |
Version 10.0.2
|
|
Version 10.0.2
|
WiredTiger supports three underlying file formats: row-store and column-store, with an underlying special case of column-store for bit-field values. All three formats are B+tree implementations of key/value stores. WiredTiger also supports Log-Structured Merge Trees, implemented as a tree of B+trees.
In a row-store, both keys and data are variable-length byte strings. In a column-store, keys are 64-bit record numbers (key_format type 'r'), and values are variable-length byte strings, except for the special case format for bit-field values, where the values are a fixed number of bits between 1 and 8. The two flavors of column-store are accordingly called "variable-length" and "fixed-length".
Generally, row-stores are faster for queries where all of the columns are required by every lookup (because there's only a single set of meta-data pages to read into the cache and search). Column-stores are faster when most queries require only a subset of the columns (because columns can be separated into multiple files and only the columns being returned need be present in the cache).
Row-store keys and values, and variable-length column-store values, can be up to (4GB - 512B) in length. Keys and values too large to fit on a normal page are stored as overflow items in the file, and are likely to require additional file I/O to access.
Fixed-length column-store values (value_format type 't') are limited to 8 bits. Thus, at most values between 0 and 255 may be stored. Additionally, there is no out-of-band fixed-length "deleted" value, and deleting a value is the same as storing a value of 0.
WiredTiger does not support duplicate data items: there can be only a single value associated with any given key, and applications are responsible for creating unique key/value pairs.
WiredTiger allocates space from the underlying files in block units. The minimum file allocation unit WiredTiger supports is 512B and the maximum is 512MB. File offsets are signed 8B values, making the maximum file size very, very large.
The row-store format is the default choice for most applications. When the primary key is a record number, there are advantages to storing columns in separate files, or the underlying data is a set of bits, column-store format may be a better choice.
Both row- and column-store formats can maintain high volumes of writes, but for data sets requiring sustained, extreme write throughput, Log-Structured Merge Trees are usually a better choice. For applications that do not require extreme write throughput, row- or column-store is likely to be a better choice because the read throughput is better than with LSM trees (an effect that becomes more pronounced as additional read threads are added).
Applications with complex schemas may also benefit from using multiple storage formats, that is, using a combination of different formats in the database, and even in individual tables (for example, a sparse, wide table configured with a column-store primary, where indexes are stored in an LSM tree).
Finally, as WiredTiger makes it easy to switch back-and-forth between storage configurations, it's usually worthwhile benchmarking possible configurations when there is any question.
Row-stores support four types of compression: key prefix compression, dictionary compression, Huffman encoding and block compression.
Key prefix compression reduces the size requirement of both in-memory and on-disk objects by storing any identical key prefix only once per page.
The cost is additional CPU and memory when operating on the in-memory tree. Specifically, sequential cursor movement through prefix-compressed page in reverse (but not forward) order, or the random lookup of a key/value pair will allocate sufficient memory to hold some number of uncompressed keys. So, for example, if key prefix compression only saves a small number of bytes per key, the additional memory cost of instantiating the uncompressed key may mean prefix compression is not worthwhile. Further, in cases where the on-disk cost is the primary concern, block compression may mean prefix compression is less useful.
Applications may limit the use of prefix compression by configuring the minimum number of bytes that must be gained before prefix compression is used with the WT_SESSION::create method's prefix_compression_min configuration string.
Key prefix compression is disabled by default.
Dictionary compression reduces the size requirement of both the in-memory and on-disk objects by storing any identical value only once per page. The cost is minor additional CPU and memory use when writing pages to disk.
Dictionary compression is disabled by default.
Huffman encoding reduces the size requirement of both the in-memory and on-disk objects by compressing individual value items. The cost is additional CPU and memory use when returning values from the in-memory tree and when writing pages to disk. Note the additional CPU cost of Huffman encoding can be high, and should be considered. (See Huffman Encoding for details.)
Huffman encoding is disabled by default.
Block compression reduces the size requirement of on-disk objects by compressing blocks of the backing object's file. The cost is additional CPU and memory use when reading and writing pages to disk. Note the additional CPU cost of block compression can be high, and should be considered. (See Compression considerations for details.)
Block compression is disabled by default.
Variable-length column stores support four types of compression: run-length encoding, dictionary compression, Huffman encoding and block compression.
Run-length encoding reduces the size requirement of both the in-memory and on-disk objects by storing sequential, duplicate values in the store only a single time (with an associated count). The cost is minor additional CPU and memory use when returning values from the in-memory tree and when writing pages to disk.
Run-length encoding is always enabled and cannot be turned off.
Dictionary compression reduces the size requirement of both the in-memory and on-disk objects by storing any identical value only once per page. The cost is minor additional CPU and memory use when returning values from the in-memory tree and when writing pages to disk.
Dictionary compression is disabled by default.
Huffman encoding reduces the size requirement of both the in-memory and on-disk objects by compressing individual value items. The cost is additional CPU and memory use when returning values from the in-memory tree and when writing pages to disk. Note the additional CPU cost of Huffman encoding can be high, and should be considered. (See Huffman Encoding for details.)
Huffman encoding is disabled by default.
Block compression reduces the size requirement of on-disk objects by compressing blocks of the backing object's file. The cost is additional CPU and memory use when reading and writing pages to disk. Note the additional CPU cost of block compression can be high, and should be considered. (See Compression considerations for details.)
Block compression is disabled by default.
Fixed-length column stores support a single type of compression: block compression.
Block compression reduces the size requirement of on-disk objects by compressing blocks of the backing object's file. The cost is additional CPU and memory use when reading and writing pages to disk. Note the additional CPU cost of block compression can be high, and should be considered. (See Compression considerations for details.)
Block compression is disabled by default.