Checkpoints

Blocking

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.

Compression

Naïve (Record-Level)

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.

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 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.

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 variable length bytes in Kyoto Cabinet.

Foreign Keys

Not Supported

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.

Indexes

B+Tree Hash Table

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.

Isolation Levels

Read Uncommitted Serializable

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.

Joins

Not Supported

Kyoto Cabinet does not support any kind of join operation.

Logging

Shadow Paging

Query Compilation

Not Supported

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.

Query Execution

Tuple-at-a-Time Model

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.

Query Interface

Custom API Command-line / Shell

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.

Storage Architecture

Disk-oriented In-Memory

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.

Storage Model

N-ary Storage Model (Row/Record)

Stored Procedures

Not Supported

Kyoto Cabinet does not support Stored Procedure since it is not a relational database system.

System Architecture

Embedded

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.

Views

Not Supported

Kyoto Cabinet does not have the concept of views.