Kyoto Cabinet

View Current Viewing Revision #6 from 12/02/2018 12:47 a.m.

Kyoto Cabinet is a library of routines to manage a database. It is a multithreaded key-value embedded database manager, where key must be unique and both keys and values are simply made up of variable length bytes. Kyoto Cabinet is a representative successor of UNIX DBM with the claim of higher performance. The supported operations, including adding, deleting, querying and traversal, run fast with the speed of at most logarithmic to the scale of the database. The scalability is as well outstanding with the database size be up to 8EB. Kyoto Cabinet also has other highlights such as smaller database file size, various database manager implementations, great usability with object-oriented user API and high robustness.

History

Kyoto Cabinet is announced as the modern implementation of DBM library originally coined by AT&T in 1979. After the release of the original DBM library, similar DBM libraries were then written by different groups. In 2009, Kyoto Cabinet was developed by FAL Labs to be the successor of QDBM, one of the UNIX DBM-like products developed in 2003, for performance reason. The stable version (1.2.76) was released on December 2012, and the most recent release (1.2.77) was on October 2018.

Compression

Dictionary Encoding

The default compression encoding is method is ZLIB Deflate because the records in the same page share similar patterns. There are configuration commands that could disable Deflate and enable other compression encodings such as LZO or LZMA. All the compression encodings here are of lossless dictionary type.

Foreign Keys

Supported

Kyoto Cabinet does not support foreign keys since there is no concept of data tables in it.

Data Model

Key/Value

Each record in the database consists of a key and a value. Kyoto Cabinet supports adding key-value pair, deleting by key, retrieval by key and traversal every key. Every key must be unique in a database since there is no table concept. Keys and values are simply variable length bytes in Kyoto Cabinet.

Checkpoints

Blocking

The checkpointing procedure basically blocks all other threads no matter whether they are updating or reading. Any backup procedures can be done by using BasicDB::copy method. Besides, cache hash database and cache tree database can use BasicDB::dump_snapshot method to complete 'pseudo-snapshot' procedure. The checkpointing procedure backs up database records and status into a stream or output file. There is also a non-blocking backup mechanism called 'hot backup', using the snapshot command provided by the operating system and the File::synchronize method to synchronize any later updates.

Concurrency Control

Not Supported

The connections to the database are in either reader mode or writer mode. Readers can only retrieve records, while writers can call all the methods. If a reader process has connected to the database, only other reader processes can connect to the database. However, writer processes have the exclusive access to the database, thus no later processes will be granted the access. There is no concurrency control since database has different permissions for different connection modes and the concurrency is done in the process level.

Indexes

B+Tree Hash Table

Kyoto Cabinet has several database manager implementations that inherited from the base dbm. Some of them organizes records in hash table, while others organizes them in B+ tree.

Revision #6 | Updated 12/02/2018 12:47 a.m.