4 releases (2 breaking)

0.3.0 Apr 18, 2024
0.2.1 Jan 16, 2024
0.2.0 Oct 14, 2023
0.1.0 Sep 8, 2023

#48 in Database implementations

48 downloads per month
Used in 3 crates (via izihawa-tantivy)

MIT license

755KB
18K SLoC

Columnar format

This crate describes columnar format used in tantivy.

Goals

This format is special in the following way.

  • it needs to be compact
  • accessing a specific column does not require to load the entire columnar. It can be done in 2 to 3 random access.
  • columns of several types can be associated with the same column name.
  • it needs to support columns with different types (str, u64, i64, f64) and different cardinality (required, optional, multivalued).
  • columns, once loaded, offer cheap random access.
  • it is designed to allow range queries.

Coercion rules

Users can create a columnar by inserting rows to a ColumnarWriter, and serializing it into a Write object. Nothing prevents a user from recording values with different type to the same column_name.

In that case, tantivy-columnar's behavior is as follows:

  • JsonValues are grouped into 3 types (String, Number, bool). Values that corresponds to different groups are mapped to different columns. For instance, String values are treated independently from Number or boolean values. tantivy-columnar will simply emit several columns associated to a given column_name.
  • Only one column for a given json value type is emitted. If number values with different number types are recorded (e.g. u64, i64, f64), tantivy-columnar will pick the first type that can represents the set of appended value, with the following prioriy order (i64, u64, f64). i64 is picked over u64 as it is likely to yield less change of types. Most use cases strictly requiring u64 show the restriction on 50% of the values (e.g. a 64-bit hash). On the other hand, a lot of use cases can show rare negative value.

Columnar format

This columnar format may have more than one column (with different types) associated to the same column_name (see Coercion rules above). The (column_name, columne_type) couple however uniquely identifies a column. That couple is serialized as a column column_key. The format of that key is: [column_name][ZERO_BYTE][column_type_header: u8]

COLUMNAR:=
    [COLUMNAR_DATA]
    [COLUMNAR_KEY_TO_DATA_INDEX]
    [COLUMNAR_FOOTER];


# Columns are sorted by their column key.
COLUMNAR_DATA:=
    [COLUMN_DATA]+;

COLUMNAR_FOOTER := [RANGE_SSTABLE_BYTES_LEN: 8 bytes little endian]

The columnar file starts by the actual column data, concatenated one after the other, sorted by column key.

A sstable associates `(column name, column_cardinality, column_type) to range of bytes.

Column name may not contain the zero byte \0.

Listing all columns associated to column_name can therefore be done by listing all keys prefixed by [column_name][ZERO_BYTE]

The associated range of bytes refer to a range of bytes

This crate exposes a columnar format for tantivy. This format is described in README.md

The crate introduces the following concepts.

Columnar is an equivalent of a dataframe. It maps column_key to Column.

A Column<T> asssociates a RowId (u32) to any number of values.

This is made possible by wrapping a ColumnIndex and a ColumnValue object. The ColumnValue<T> represents a mapping that associates each RowId to exactly one single value.

The ColumnIndex then maps each RowId to a set of RowId in the ColumnValue.

For optimization, and compression purposes, the ColumnIndex has three possible representation, each for different cardinalities.

  • Full

All RowId have exactly one value. The ColumnIndex is the trivial mapping.

  • Optional

All RowIds can have at most one value. The ColumnIndex is the trivial mapping ColumnRowId -> Option<ColumnValueRowId>.

  • Multivalued

All RowIds can have any number of values. The column index is mapping values to a range.

All these objects are implemented an unit tested independently in their own module:

  • columnar
  • column_index
  • column_values
  • column

Dependencies

~8MB
~128K SLoC