Kyoto Cabinet is a library of routines to manage a database. It is a multithreaded key-value embedded database manager. Both keys and values are composed of variable-length bytes since there is no concept of data types in Kyoto Cabinet. All keys must be unique since there is no concept of tables in Kyoto Cabinet, which means a database contains a single table. Kyoto Cabinet is a successor and modern implementation of UNIX DBM by AT&T in 1979. It provides different object-oriented database implementations, which differ in whether using Hash Table or B+ Tree, or whether enabling cache. They are
BasicDB (common interface),
ProtoHashDB (on-memory hash database),
ProtoTreeDB (on-memory tree database),
StashDB (lightweight on-memory hash database with cache),
CacheDB (on-memory database with LRU cache),
GrassDB (on-memory tree database with cache),
HashDB (file hash database),
TreeDB (file tree database),
DirDB (directory hash database),
ForestDB (directory tree database),
TestDB (text database) and
PolyDB (polymorphic database). All of the implementations in Kyoto Cabinet support inserting, deleting and query operations. Moreover, the B+ Tree based implementations also support traversal operation. The file size for each record in Kyoto Cabinet can take either 4KB or 16KB space, based on whether using B+ Tree or Hash Table, and the total database size can be up to 8EB.
Kyoto Cabinet is announced by its author as the modern implementation of DBM library originally implemented by AT&T in 1979. After the release of the original DBM library, variant DBM libraries were then written by different groups. In 2009, Kyoto Cabinet was developed by FAL Labs to be the variant of QDBM, one of the UNIX DBM-like products developed in 2003, for some performance reasons.
The checkpointing procedure basically blocks all other threads no matter whether they are updating or reading. Any backup can be done by using the copy method. Besides, database implementations that support cache in Kyoto Cabinet can use dump_snapshot method to complete pseudo-snapshot functionality. The checkpointing backs up database records and status into a stream or output file. There is also a non-blocking backup mechanism called 'hot backup', which uses the built-in snapshot functionality by the operating system and the synchronize method in Kyoto Cabinet to synchronize any later updates.
The default compression encoding method is ZLIB Deflate because the records in the same page share similar patterns. It is also configurable to disable ZLIB Deflate and enable LZO or LZMA compression encodings.
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 that 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.
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 variable length bytes in Kyoto Cabinet.
Since Kyoto Cabinet does not have concept of data tables, in other words, a database only contains one single table, foreign keys are not supported.
Kyoto Cabinet has several database implementations that implement their common interface. Some of them organizes records in hash table style, while others organize them in B+ tree style. It is users who decide which implementations to use.
Kyoto Cabinet does support two isolation levels: 'Serializable' and 'Read Uncommitted' and each database implementation has its own isolation level. For example, from the source code, HashDB is Serializable, while CacheDB is Read Uncommitted. It's not configurable.
Kyoto Cabinet does not support any kind of join operation.
Since all the operations Kyoto Cabinet supported are inserting, deleting, traversal and retrieval, it does not generate any forms of byte code or intermediate representation. It does not compile the query and will execute the operations themselves.
All the operations (inserting, deleting, retrieval and traversal) in Kyoto Cabinet are key-based. So it maintains a cursor object that can jump to any tuple or check each tuple one at a time.
Kyoto Cabinet supports direct shell commands through the terminal. Which database implementation and operation name need to be pointed out. Kyoto Cabinet also supports API in multiple programming languages such as C, C++, Java, Lua, Perl, Python, Ruby by using namespace or importing packages. The application is then compiled (if applicable) and executed through the terminal.
Some of the database implementations in Kyoto Cabinet primarily rely on memory for storage, including ProtoDB, StashDB, CacheDB and GrassDB. Others mainly rely on disk for storage, such as HashDB, TreeDB, DirDB and ForestDB. For those whose storage is disk-oriented, they can choose to either store in single file, or in multiple files in a same directory.
Kyoto Cabinet does not support Stored Procedure since it is not a relational database system.
Kyoto Cabinet is an embedded database system since it is created and connected inside the application. It is the application which implicitly controls the database. The database system is not a standalone tool and is hidden from the user.
Kyoto Cabinet does not have the concept of views.