Class RowIndexEntry

java.lang.Object
org.apache.cassandra.io.sstable.AbstractRowIndexEntry
org.apache.cassandra.io.sstable.format.big.RowIndexEntry
All Implemented Interfaces:
IMeasurableMemory

public class RowIndexEntry extends AbstractRowIndexEntry
Binary format of RowIndexEntry is defined as follows: (long) position (64 bit long, vint encoded) (int) serialized size of data that follows (32 bit int, vint encoded) -- following for indexed entries only (so serialized size > 0) (int) int/Uint DeletionTime.localDeletionTime (uint if version >= "oa" (5.0)) (long) DeletionTime.markedForDeletionAt (int) number of IndexInfo objects (32 bit int, vint encoded) (*) serialized IndexInfo objects, see below (*) offsets of serialized IndexInfo objects, since version "ma" (3.0) Each IndexInfo object's offset is relative to the first IndexInfo object.

See IndexInfo for a description of the serialized format.

For each partition, the layout of the index file looks like this:

  1. partition key - prefixed with short length
  2. serialized RowIndexEntry objects

Generally, we distinguish between index entries that have index samples (list of IndexInfo objects) and those who don't. For each portion of data for a single partition in the data file, an index sample is created. The size of that portion is defined by Config.column_index_size.

Index entries with less than 2 index samples, will just store the position in the data file.

Note: legacy sstables for index entries are those sstable formats that do not have an offsets table to index samples (IndexInfo objects). These are those sstables created on Cassandra versions earlier than 3.0.

For index entries with index samples we store the index samples (IndexInfo objects). The bigger the partition, the more index samples are created. Since a huge amount of index samples will "pollute" the heap and cause huge GC pressure, Cassandra 3.6 (CASSANDRA-11206) distinguishes between index entries with an "acceptable" amount of index samples per partition and those with an "enormous" amount of index samples. The barrier is controlled by the configuration parameter Config.column_index_cache_size. Index entries with a total serialized size of index samples up to column_index_cache_size will be held in an array. Index entries exceeding that value will always be accessed from disk.

This results in these classes:

  • RowIndexEntry just stores the offset in the data file.
  • RowIndexEntry.IndexedEntry is for index entries with index samples and used for both current and legacy sstables, which do not exceed Config.column_index_cache_size.
  • RowIndexEntry.ShallowIndexedEntry is for index entries with index samples that exceed Config.column_index_cache_size for sstables with an offset table to the index samples.

Since access to index samples on disk (obviously) requires some file reader, that functionality is encapsulated in implementations of RowIndexEntry.IndexInfoRetriever. There is an implementation to access index samples of legacy sstables (without the offsets table), an implementation of access sstables with an offsets table.

Until now (Cassandra 3.x), we still support reading from legacy sstables - i.e. sstables created by Cassandra < 3.0 (see BigFormat.