History

An informal history of the origins of quasardb: http://blog.quasardb.net/quasardb-2-0-beta-5/

Concurrency Control[03]

If two transactions attempt to write to the same entry, the first transaction to operate on the entry wins and the other transaction is canceled. When a transaction writes to an entry, other transactions may access the previous value of the entry.

Data Model[04]

quasardb is a distributed key-value store technology.

Foreign Keys

quasardb interface is not in SQL and so it does not support foreign keys

Isolation Levels[03]

Transactions in quasardb are snapshot based and provide repeatable reads.

Joins

Query Compilation

Query Interface[05]

quasardb supports rich set of APIs in various languages. Currently APIs are supported in C, C++, Go, Hadoop integration, Java, .NET, Node.js, PHP, Python, REST API, Spark connector

Storage Architecture[06]

Entries are often kept resident in a write cache so the daemon can rapidly serve a large amount of simultaneous requests. When a user adds or updates an entry on the cluster the entry’s value may not be synced to the disk immediately. However, quasardb guarantees the data is consistent at all times, even in case of hardware or software failure.

Storage Model[07]

QuasarDB is a column-oriented time series database. The time series are column oriented and can have an arbitrary number of columns, each column has an unique name.

Stored Procedures

quasardb interface is not in SQL and so it does not support stored procedures.

System Architecture[08]

The data is stored on multiple nodes that are linked together into a cluster. This is a peer-to-peer distributed hash table based on Chord in which the nodes self-organize to share data and handle client requests.

Views