Joins

Not Supported

Joins are not supported by Tokyo Cabinet.

Stored Procedures

Not Supported

Stored procedures are not supported by Tokyo Cabinet.

Query Interface

Custom API

Tokyo Cabinet does not support SQL. Applications need to use a custom non-SQL API to invoke insert, delete, update operations on data and other management functions. In addition, Tokyo Cabinet supports repeatedly appending to a value, characterized as a "concatenate" operation.

Tokyo Cabinet has native support for C and C++ and wrapper APIs for other languages.

Data Model

Key/Value

Tokyo Cabinet is not a relational database management system; It is a dedicated key-value store. Applications need to use a custom non-SQL API to invoke insert, delete, update operations on data and other management functions.

Tokyo Cabinet also implements a thin "table" abstraction which simulates columns over a key-value store. Schemas and data types are not supported, and therefore, the a Tokyo Cabinet table can contain tuples with a different kind and number of columns. In the table abstraction, a key and a column index (a non-negative integer) together serve as a pointer to a value, unlike a standard key-value record, where only the key serves as such a pointer.

System Architecture

Embedded

Concurrency Control

Not Supported

Tokyo Cabinet implements transactions with ACID properties. It supports serializable isolation for transactions using a global latch (only one transaction is active at a time). Therefore, Tokyo Cabinet does not support concurrent concurrent transactions.

Further, Tokyo Cabinet supports multiple threads or processes using the database file at a time using latching at different levels. At the highest level, processes or threads open the database file for reading or writing. There can be multiple concurrent readers. However, concurrent readers and writers are not allowed: whenever the database file is opened for writing, other writers and readers are blocked.

Data structures, including the fixed-size array and the hash table, in the storage layer are protected using fine-grained latching. The B+ tree implementation, however, does not support fine-grained latching: each process or thread acquires a global latch over the entire tree for operations on it.

Views

Not Supported

Views are not supported by Tokyo Cabinet.

Storage Architecture

Disk-oriented In-Memory Hybrid

Compression

Naïve (Page-Level) Naïve (Record-Level) Prefix Compression

A Tokyo Cabinet database file is not globally compressed. Compression is done at the record (key and value) level or the page level (for a B+ Tree-based store) using the Burrows–Wheeler transform or the Lempel–Ziv compression algorithm.

Storage Model

N-ary Storage Model (Row/Record)

Tokyo Cabinet implements a thin "table" abstraction which simulates columns over a key-value store. In this table abstraction, a key and a column index (a non-negative integer) together serve as a pointer to a value, unlike a standard key-value record, where only the key serves as such a pointer. All parts of a record (key and value, or key and column values) are stored together in a row-oriented manner.

Indexes

B+Tree Hash Table Inverted Index (Full Text)

Query Compilation

Not Supported

Isolation Levels

Serializable

Tokyo Cabinet implements transactions with ACID properties. It supports serializable isolation for transactions using a global latch (only one transaction is active at a time).

Foreign Keys

Not Supported

Foreign keys are not supported by Tokyo Cabinet.

Checkpoints

Not Supported

Checkpoints are not supported by Tokyo Cabinet.

Logging

Shadow Paging

Tokyo Cabinet implements write-ahead logging for transactions using shadow paging. However, the data for all the operations performed in a single transaction — inserts, updates, etc. — should fit in memory.