This page is forked from LevelDB's document on table format, and reflects changes we have made during the development of RocksDB.

BlockBasedTable is the default SST table format in RocksDB.

File format

  1. <beginning_of_file>
  2. [data block 1]
  3. [data block 2]
  4. ...
  5. [data block N]
  6. [meta block 1: filter block]                  (see section: "filter" Meta Block)
  7. [meta block 2: index block]
  8. [meta block 3: compression dictionary block]  (see section: "compression dictionary" Meta Block)
  9. [meta block 4: range deletion block]          (see section: "range deletion" Meta Block)
  10. [meta block 5: stats block]                   (see section: "properties" Meta Block)
  11. ...
  12. [meta block K: future extended block]  (we may add more meta blocks in the future)
  13. [metaindex block]
  14. [Footer]                               (fixed size; starts at file_size - sizeof(Footer))
  15. <end_of_file>

The file contains internal pointers, called BlockHandles, containing the following information:

  1. offset:         varint64
  2. size:           varint64

See this document for an explanation of varint64 format.

(1) The sequence of key/value pairs in the file are stored in sorted order and partitioned into a sequence of data blocks. These blocks come one after another at the beginning of the file. Each data block is formatted according to the code in block_builder.cc (see code comments in the file), and then optionally compressed.

(2) After the data blocks, we store a bunch of meta blocks. The supported meta block types are described below. More meta block types may be added in the future. Each meta block is again formatted using block_builder.cc and then optionally compressed.

(3) A metaindex block contains one entry for every meta block, where the key is the name of the meta block and the value is a BlockHandle pointing to that meta block.

(4) An index block contains one entry per data block, where the key is a string >= last key in that data block and before the first key in the successive data block. The value is the BlockHandle for the data block. If kTwoLevelIndexSearch is used as IndexType the index block is a 2nd level index on index partitions, i.e., each entry points to another index block that contains one entry per data block. In this case, the format will be

  1. [index block - 1st level]
  2. [index block - 1st level]
  3. ...
  4. [index block - 1st level]
  5. [index block - 2nd level]

Up to RocksDB version 5.14, BlockBasedTableOptions::format_version=2, the format of index and data blocks are the same, where the index blocks use same key format of <user_key,seq> but special values, <offset,size>, that point to data blocks. format_version=3,4 offer more optimized, yet forward-incompatible format for index blocks.

  • format_version=3 (Since RocksDB 5.15): In most of the cases the sequence number seq is not necessary for keys in the index blocks. In such cases, this format_version skips encoding the sequence number and sets index_key_is_user_key in TableProperties, which is used by the reader to know how to decode the index block.
  • format_version=4 (Since RocksDB 5.16): Changes the format of index blocks by delta encoding the index values, which are the block handles. This saves the encoding of BlockHandle::offset of the non-head index entries in each restart interval. If used, TableProperties::index_value_is_delta_encoded is set, which is used by the reader to know how to decode the index block. The format of each key is (shared_size, non_shared_size, shared, non_shared). The format of each value, i.e., block handle, is (offset, size) whenever the shared_size is 0, which included the first entry in each restart point. Otherwise the format is delta-size = block handle size - size of last block handle.The index format in format_version=4 would be as follows:
  1. restart_point   0: k, v (off, sz), k, v (delta-sz), ..., k, v (delta-sz)
  2. restart_point   1: k, v (off, sz), k, v (delta-sz), ..., k, v (delta-sz)
  3. ...
  4. restart_point n-1: k, v (off, sz), k, v (delta-sz), ..., k, v (delta-sz)
  5. where, k is key, v is value, and its encoding is in parenthesis.

(5) At the very end of the file is a fixed length footer that contains the BlockHandle of the metaindex and index blocks as well as a magic number.

  1.    metaindex_handle: char[p];      // Block handle for metaindex
  2.    index_handle:     char[q];      // Block handle for index
  3.    padding:          char[40-p-q]; // zeroed bytes to make fixed length
  4.                                    // (40==2*BlockHandle::kMaxEncodedLength)
  5.    magic:            fixed64;      // 0x88e241b785f4cff7 (little-endian)

Filter Meta Block

Full filter

In this filter there is one filter block for the entire SST file.

Partitioned Filter

The full filter is partitioned into multiple blocks. A top-level index block is added to map keys to corresponding filter partitions. Read more here.

Block-based filter

Note: the below explains block based filter, which is deprecated.

If a "FilterPolicy" was specified when the database was opened, a filter block is stored in each table. The "metaindex" block contains an entry that maps from "filter." to the BlockHandle for the filter block, where "" is the string returned by the filter policy's Name() method.

The filter block stores a sequence of filters, where filter i contains the output of FilterPolicy::CreateFilter() on all keys that are stored in a block whose file offset falls within the range

  1. [ i*base ... (i+1)*base-1 ]

Currently, "base" is 2KB. So, for example, if blocks X and Y start in the range [ 0KB .. 2KB-1 ], all of the keys in X and Y will be converted to a filter by calling FilterPolicy::CreateFilter(), and the resulting filter will be stored as the first filter in the filter block.

The filter block is formatted as follows:

  1.  [filter 0]
  2.  [filter 1]
  3.  [filter 2]
  4.  ...
  5.  [filter N-1]
  7.  [offset of filter 0]                  : 4 bytes
  8.  [offset of filter 1]                  : 4 bytes
  9.  [offset of filter 2]                  : 4 bytes
  10.  ...
  11.  [offset of filter N-1]                : 4 bytes
  13.  [offset of beginning of offset array] : 4 bytes
  14.  lg(base)                              : 1 byte

The offset array at the end of the filter block allows efficient mapping from a data block offset to the corresponding filter.

Properties Meta Block

This meta block contains a bunch of properties. The key is the name of the property. The value is the property.

The stats block is formatted as follows:

  1.  [prop1]    (Each property is a key/value pair)
  2.  [prop2]
  3.  ...
  4.  [propN]

Properties are guaranteed to sort with no duplication.

By default, each table provides the following properties.

  1.  data size               // the total size of all data blocks. 
  2.  index size              // the size of the index block.
  3.  filter size             // the size of the filter block.
  4.  raw key size            // the size of all keys before any processing.
  5.  raw value size          // the size of all value before any processing.
  6.  number of entries
  7.  number of data blocks

RocksDB also provides users the "callback" to collect their interested properties about this table. Please refer to UserDefinedPropertiesCollector.

Compression Dictionary Meta Block

This metablock contains the dictionary used to prime the compression library before compressing/decompressing each block. Its purpose is to address a fundamental problem with dynamic dictionary compression algorithms on small data blocks: the dictionary is built during a single pass over the block, so small data blocks always have small and thus ineffective dictionaries.

Our solution is to initialize the compression library with a dictionary built from data sampled from previously seen blocks. This dictionary is then stored in a file-level meta-block for use during decompression. The upper-bound on the size of this dictionary is configurable via CompressionOptions::max_dict_bytes. By default it is zero, i.e., the block is not generated or stored. Currently this feature is supported with kZlibCompression, kLZ4Compression, kLZ4HCCompression, and kZSTDNotFinalCompression.

More specifically, the compression dictionary is built only during compaction to the bottommost level, where the data is largest and most stable. To avoid iterating over input data multiple times, the dictionary includes samples from the subcompaction's first output file only. Then, the dictionary is applied to and stored in meta-blocks of all subsequent output files. Note the dictionary is not applied to or stored in the first file since its contents are not finalized until that file has been fully processed.

Currently the sampling is uniformly random and each sample is 64 bytes. We do not know in advance the size of the output file when selecting the sample offsets, so we assume it'll reach the maximum size, which is usually true since it's the first file in the subcompaction. In case the file is smaller, some sample intervals will refer to offsets beyond EOF, which just means the dictionary will be a bit smaller than CompressionOptions::max_dict_bytes.

Range Deletion Meta Block

This metablock contains the range deletions in the file's key-range and seqnum-range. Range deletions cannot be inlined in the data blocks together with point data since the ranges would then not be binary searchable.

The block format is the standard key-value format. A range deletion is encoded as follows:

  • User key: the range's begin key
  • Sequence number: the sequence number at which the range deletion was inserted to the DB
  • Value type: kTypeRangeDeletion
  • Value: the range's end keyRange deletions are assigned sequence numbers when inserted using the same mechanism as non-range data types (puts, deletes, etc.). They also traverse through the LSM using the same flush/compaction mechanism as point data. They can be obsoleted (i.e., dropped) only during compaction to the bottommost level.