31 lines
1.0 KiB
ReStructuredText
31 lines
1.0 KiB
ReStructuredText
Motivation
|
|
==========
|
|
|
|
This page describes reasons for certain design decisions.
|
|
|
|
General structure
|
|
-----------------
|
|
|
|
* We're making a key-value database.
|
|
* Keys and values are python objects.
|
|
* While the DB is offline (after a correct shutdown), all its KVPs are stored as lines in one editable file.
|
|
* DB should be able to survive powercut at any point (D in ACID).
|
|
|
|
AP/LP get
|
|
------
|
|
|
|
The central idea for this database is the zero-latency (as far as python goes) reads. Therefore, the DB has all its data stored as a :code:`dict`.
|
|
|
|
CAP/CLP set
|
|
-------
|
|
|
|
The database allows both availability-(zero)latency and consistency (note: it's not ACID consistency, it's CAP consistency and ACID durability) variants for its writes.
|
|
All zero-latency writes are also consistent with respect to (zero-latency) reads.
|
|
|
|
Consistent get
|
|
------
|
|
|
|
Later versions of the database will include remote connections, and thus also consistent reads.
|
|
These will probably be implemented as requests (same as writes).
|
|
Some connection variants may not even include availability reads/writes.
|