LedisDB

LedisDB is a NoSQL database written in Go. It is similar to Redis and implements redis protocol. It can be used as a replacement of Redis. However, it uses RocksDB, LevelDB or goleveldb as storage engine. Therefore, unlike Redis, the storage is not limited by memory. The name LedisDB comes from Level-Redis-DB.

History

In 2014, Chinese programmer Siddon Tang was developing an application which depended on Redis heavily. He noticed that as the number of users of the application increased, the memory size was not enough for Redis. He found that SSDB could solve the problem. SSDB implements redis protocol using LevelDB as storage. This design inspired him. Finally, LedisDB, a database similar to SSDB but written in Go was developed.

The motivation for LedisDB can be concluded as follows:

  1. Reimplement SSDB's idea in Go rather than C++.
  2. As a project for learning LevelDB and Redis.

Now, Siddon Tang is the Chief Engineer of PingCAP. He works on TiDB and TiKV. But LedisDB is still under his maintenance.

Concurrency Control

Not Supported

There is no concurrency control protocol in LedisDB because it does not support transactions. Like Redis, LedisDB processes requests as command sequences. Each command is treated as a single atomic operation. However, LedisDB does not provide any mechanism to combine commands into transactions.

Data Model

Key/Value

LedisDB is a key/value store but has rich data structures. In addition to simple key/value pair, it provides Hash, List, Set, ZSet. ZSets are sorted sets in Redis, every element is also associated with a score (a floating point value). They are ordered by score and use their own value to break the tie.

Storage Organization

Log-structured

All storage engines of LedisDB use Log-structured storage organization, but LedisDB does not leverage anything specific for that.

Logging

Logical Logging

LedisDB has its own write-ahead log. It logs write operations in its log first, before committing the changes in the storage engine.

Query Interface

Custom API HTTP / REST Command-line / Shell

LedisDB can be embedded in Go programs and programs can use its API to perform queries. LedisDB also provides a query interface in redis protocol called RESP(REdis Serialization Protocol), and can be queried via redis-cli. LedisDB has HTTP API support too.

System Architecture

Shared-Nothing Embedded

LedisDB can be embedded in Go programs.

It can also be used as an independent server.

Multiple LedisDB nodes and coordinator nodes can form a cluster with partition and Master-Replica replication. Each server does not share anything with others and only communicates with each other through the network connection. LedisDB provides a SLAVEOF command thus a LedisDB server can be configured as a master node or a replica of some master node on the fly. It also provides a PING command for checking whether a server is alive. LedisDB cluster needs a group of dedicated coordinators (redis-failover) that use this two commands to monitor and manage the Master-Replica groups. LedisDB is Active-Passive, logs are continuously streamed from master to replicas. Both asynchronous and semi-synchronous propagation schemes are supported. To support partition, another group of coordinators (xcodis) is needed, which serve as proxies that dispatch requests to different Master-Replica groups based on partition. LedisDB does physical partition based on the hash of a key. Unfortunately, in GitHub issue, the developer states that he will not maintain this part anymore, because he does not have enough time. For more detail, you can see this article about LedisDB cluster written by the developer.

Compression

Dictionary Encoding Naïve (Page-Level)

Compression is disabled by default. The compression feature of the storage engine can be enabled via configuration. Data and index blocks are compressed individually. User can choose from a list of supported compression algorithms, like LZ4 and Snappy. User can choose to use Dictionary Compression too. Data are decompressed when LedisDB retrieves them from the underlying storage engine.

Query Execution

Tuple-at-a-Time Model

For queries that involve multiple key-value pairs, LedisDB uses iterators to access and process key-value pairs one-by-one.

Checkpoints

Non-Blocking Consistent Blocking

LedisDB provides two command line tool: ledis-dump and ledis-load, for taking a checkpoint and restoring from a checkpoint, which depends on the storage engine's mechanism. LedisDB also uses that internally for synchronization between master and replica. No other way to access the checkpoint mechanism is found.

Indexes

Skip List Log-Structured Merge Tree

LedisDB does not make its own indexes, it just uses underlying storage engines' index data structure, which is the Log-Structured Merge Tree. They also use Skip List in the MemTable part.

Storage Architecture

Disk-oriented In-Memory Hybrid

LedisDB uses RocksDB, LevelDB or goleveldb as storage engine and thus inherits their storage architecture. It also provides an option to use memory-backed storage (via goleveldb).

Stored Procedures

Not Supported

LedisDB does not support stored procedures, but like Redis, it provides the capability to evaluate scripts using the bulit-in Lua interpreter. Scripts will be cached by LedisDB and can be invoked from the cache later. However, they are just cached rather than stored.

Storage Model

N-ary Storage Model (Row/Record)

In LedisDB, data are stored in the form of ordered key-value pairs.

Isolation Levels

Not Supported

Because LedisDB does not support transactions.

Joins

Not Supported

As a key/value store, no join feature is provided in LedisDB.

LedisDB Logo
Website

http://ledisdb.com/

Source Code

https://github.com/siddontang/ledisdb

Tech Docs

https://github.com/siddontang/ledisdb/wiki

Developer

Siddon Tang

Country of Origin

CN

Start Year

2014

Project Type

Open Source

Written in

Go

Supported languages

C, Go, JavaScript, Lua, Python

Derived From

LevelDB, RocksDB

Inspired By

SSDB

Compatible With

Redis

Operating Systems

Linux, OS X

Licenses

MIT