README: talk a bit more about the limits of DODB.
This commit is contained in:
parent
9fed7145e5
commit
f2a76c288e
36
README.md
36
README.md
@ -13,16 +13,42 @@ A brief summary:
|
|||||||
- no SQL
|
- no SQL
|
||||||
- objects are serialized (currently in JSON)
|
- objects are serialized (currently in JSON)
|
||||||
- indexes (simple symlinks on the FS) can be created to improve significantly searches in the db
|
- indexes (simple symlinks on the FS) can be created to improve significantly searches in the db
|
||||||
|
- db is fully integrated in the language (basically a simple array with a few more functions)
|
||||||
|
|
||||||
|
Also, data can be `cached`.
|
||||||
|
The entire base will be kept in memory (if you can), enabling incredible speeds.
|
||||||
|
|
||||||
## Limitations
|
## Limitations
|
||||||
|
|
||||||
**TODO**: speed tests, elaborate on the matter.
|
DODB doesn't fully handle ACID properties:
|
||||||
|
|
||||||
DODB is not compatible with projects:
|
- no *atomicity*, you can't chain instructions and rollback if one of them fails ;
|
||||||
- having an absolute priority on speed,
|
- no *consistency*, there is currently no mechanism to prevent adding invalid values ;
|
||||||
however, DODB is efficient in most cases with the right indexes.
|
|
||||||
- having relational data
|
|
||||||
|
|
||||||
|
*Isolation* is partially taken into account, with a locking mechanism preventing a few race conditions.
|
||||||
|
FYI, in my projects the database is fast enough so I don't even need parallelism (like, by far).
|
||||||
|
|
||||||
|
*Durability* is taken into account.
|
||||||
|
Data is written on-disk each time it changes.
|
||||||
|
|
||||||
|
**NOTE**: what I need is mostly there.
|
||||||
|
What DODB doesn't provide, I hack it in a few lines in my app.
|
||||||
|
DODB will provide some form of atomicity and consistency at some point, but nothing fancy nor too advanced.
|
||||||
|
The whole point is to keep it simple.
|
||||||
|
|
||||||
|
## Speed
|
||||||
|
|
||||||
|
Since DODB doesn't use SQL and doesn't even try to handle stuff like atomicity or consistency, speed is great.
|
||||||
|
Reading data from disk takes about a few dozen microseconds, and not much more when searching an indexed data.
|
||||||
|
|
||||||
|
**On my more-than-decade-old, slow-as-fuck machine**, the simplest possible SQL request to Postgres takes about 100 to 900 microseconds.
|
||||||
|
To reach a data on-disk: 13 microseconds.
|
||||||
|
To reach a data that is indexed: same thing, 13 microseconds, since it's just a link.
|
||||||
|
|
||||||
|
With the `cached` version of DODB, there is not even deserialization happening, so 7 nanoseconds.
|
||||||
|
|
||||||
|
**NOTE:** of course SQL and DODB cannot be fairly compared based on performance since they don't have the same properties.
|
||||||
|
But still, this is the kind of speed you can get with the tool.
|
||||||
|
|
||||||
# Installation
|
# Installation
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user