RethinkDB

RethinkDB is an open source scalable JSON database. It was built from scratch with C++, and it is intended for the real-time web. The most significant advantage of RethinkDB is it can continuously push updated query result to applications. Another advantage of RethinkDB is it offers a flexible query language. It is called ReQL, and it could do nearly anything SQL can do, including table joins and aggregation functions. It could even mix queries with JavaScript expressions and map-reduce.

History

RethinkDB was founded in 2009. The RethinkDB was first released open source version 1.2 in Nov. 2012. It had been developed for 5 years by a team of database experts before the first release. In the first release, it covered the JSON data model, immediate consistency support, Hadoop-style map/reduce, sharing, multi-datacenter replication, and failover. The very first version of RethinkDB was an SSD-optimized storage engine for MySQL. They then switched to build a document DBMS like MongoDB. In Jun. 2013, it introduced lots of new features for ReQL, like basic access control, regular expression matching, new array operations, random sampling and better error handling. The ReQL is an essential feature for RethinkDB, and this release gave lots of improvement for ReQL. In Apr. 2015, it released version 2.0.0, and it was the first production-ready release of RethinkDB. In Aug. 2015, it supported automatic failover using a Raft-based protocol. In Nov. 2015, it introduced atomic changefeeds, which include existing values from the database into the changefeed result, and then atomically transition to streaming updates. In Oct. 2016, RethinkDB company shut down. The reason was they could not build a sustainable business. After one year, the source code was purchased by the Cloud Native Computing Foundation. Moreover, it released a new version with community effort in July 2017.

Checkpoints

Not Supported

The RethinkDB storage engine is log-structured. There are some implementation details with mini-logs and flushes implemented for efficiency. It was done on a small-scale basis, compared to a traditional system. So, the traditional notion of checkpoints doesn't quite apply -- there is no separate log and pages that are periodically flushed.

Concurrency Control

Multi-version Concurrency Control (MVCC)

RethinkDB implements block-level multiversion concurrency control. When a write operation comes while there is an ongoing read operation, RethinkDB takes a snapshot of the B-Tree for each relevant shard. Then it maintains different versions of the blocks in order to execute read and write operations concurrently. RethinkDB takes exclusive block-level locks when multiple writes are performed on documents when they are close to each other in B-Tree. In the most case, it will not present performance problems because the top levels of B-Tree are cached along with the frequently used blocks.

Data Model

Document / XML

RethinkDB stores JSON documents with a binary on disk serialization. The data types supported by RethinkDB are: number (double precision floating-point), string, boolean, array, object, null.

Indexes

B+Tree

RethinkDB index the data based on the primary key. If the user did not specify the primary key, a random unique is generated for the index automatically. RethinkDB to place the document into an appropriate shard based on primary key, and index it within that shard using a B-Tree data structure. RethinkDB supports both secondary and compound indexes.

Isolation Levels

Repeatable Read

On a single node, the isolation level is closest to repeatable read. It's done via copy-on-write, so the user can execute long-range reads, do concurrent writes, and have each read query run on its own snapshot constructed just in time. On a cluster, it is true on a per primary node basis. That is, if the table is shared across two nodes and you execute a long query along with concurrent writes, there is no synchronization of snapshot creation across primary nodes. So your range query may execute on two snapshots taken at different points in time. RethinkDB supports immediately consistent. In RethinkDB, a single authoritative primary replica will be in charge of a shard of data. When reads and writes come to a given shard, they will get directed to their respective primary. Data remains immediately consistent and conflict-free. A read following the acknowledged write is always guaranteed to see the write. RethinkDB supports both up-to-date and out-of-date reads. By default, the client always sees the latest, consistent, artifact-free view of the data. The developer can also do a read query for out-of-date data. In this mode, the query may be routed to its closet replica. Out-of-date queries may have lower latency and have stronger availability guarantees.

Joins

Index Nested Loop Join

In RethinkDB, joins are automatically distributed. The appropriate nodes will receive the join commands. Then the combined data will be presented to the user. It supports using primary keys and secondary indexes to join the data.

Logging

Physical Logging

The data is stored in a log-structured storage engine built specifically for RethinkDB and inspired by the architecture of BTRFS. The log is implicitly integrated into the storage engine. For data replication across the replicas, it doesn't require log-shipping. RethinkDB replication is based on B-Tree diff algorithms.

Query Execution

Vectorized Model

ReQL queries are constructed by making function calls in the JavaScript/Python/Ruby/Java. They will execute entirely on the database server when the user runs the query. Queries are executed lazily. RethinkDB will do just enough work to read the data requested. All queries are automatically parallelized on the RethinkDB server. It could also break complicated queries up into stages, and execute each stage in parallel. Then it will combine the data to return a complete result.

Query Interface

Custom API

RethinkDB provides a unified chainable query language. It can start with a table and incrementally chain transformer operations to the end of the query. It supports CRUD operations, aggregations including map-reduce & group-map-reduce, joins, full sub-queries and changefeeds. Changefeeds allow clients to receive changes on a table from a specific query when they happen. Nearly any ReQL query can become a changefeed. When specifying the start point, the changefeed stream will start with the current contents of the monitored table.

Storage Architecture

Disk-oriented

The data is stored in a log-structured storage engine built specifically for RethinkDB and inspired by the architecture of BTRFS, which is a file system based on the copy-on-write (COW) principle The storage engine is also used in conjunction with a custom B-Tree-aware caching engine which allows file sizes much greater than the amount of memory.

Storage Model

N-ary Storage Model (Row/Record)

RethinkDB organizes data based on rows like a traditional database does. It does not have a column-oriented storage engine.

Storage Organization

Log-structured

The data is stored in a log-structured storage engine built specifically for RethinkDB and inspired by the architecture of BTRFS.

Stored Procedures

Not Supported

System Architecture

Shared-Nothing

In RethinkDB, a single authoritative primary replica will be in charge of a shard of data. Given the primary replica, every replica is exactly the same. When reads and writes come to a given shard, they will get directed to their respective primary.

RethinkDB Logo
Website

http://www.rethinkdb.com/

Source Code

https://github.com/rethinkdb/rethinkdb

Tech Docs

https://www.rethinkdb.com/docs/

Developer

RethinkDB

Country of Origin

US

Start Year

2009

Acquired By

Cloud Native Computing Foundatio

Project Type

Open Source

Written in

Bash, C++, Java, JavaScript, Python

Supported languages

C#, C++, Clojure, Dart, Delphi, Elixir, Erlang, Go, Haskell, Java, JavaScript, Lua, Nim, Perl, PHP, Python, R, Ruby, Rust, Swift

Operating Systems

BSD, Linux, OS X, Windows

Licenses

Apache v2

Wikipedia

https://en.wikipedia.org/wiki/RethinkDB