-
Is it fast?
-
Fast to read, slow to write
-
Is it smart?
-
No
-
So what is YEDB for?
-
YEDB is ultra-reliable, thread-safe and very easy to use.
-
I don't like Python
-
There are other implementations
https://www.youtube.com/watch?v=i3hSWjrNqLo
YEDB is absolutely reliable rugged key-value database, which can survive in any power loss, unless the OS file system die. Keys data is saved in the very reliable way and immediately flushed to disk (this can be disabled to speed up the engine but is not recommended - why then YEDB is used for).
-
YEDB database objects are absolutely thread-safe.
-
YEDB has built-in tools to automatically repair itself if any keys are broken.
-
If the tools failed to help, YEDB can be easily repaired by a system administrator, using standard Linux tools.
-
YEDB can automatically validate keys with JSON Schema (https://json-schema.org/)
-
YEDB has a cool CLI
Practical usage:
-
Create a database and start writing continuously
-
Turn the power switch off
-
Boot the machine again. The typical result: the latest saved key isn't survived, but the database is still valid and working. In 99% of cases, the latest key can be automatically restored with built-in repair tools.
We created YEDB to use in our embedded products as config registry trees and rugged key-value data storage. We use it a lot and hope you'll like it too.
Note: YEDB is good on SSDs and SD cards. As it immediately syncs all the data written, it can work on classic HDDs really slowly.
Modern SSDs give about 200-300 keys/sec written with auto-flush enabled. The write speed can be 10-15 times faster without it, but we would not recommend turning auto-flush off, as it is the key feature of YEDB.
Reading speed varies:
-
for embedded: 30-40k keys/second (70-100k keys/second when cached).
-
for UNIX/TCP socket: 7-15k keys/second
-
for HTTP: 700-800 keys/second. Transport via HTTP is mostly slow because YEDB client uses synchronous "requests" library (while the default server is async). To get better results, consider tuning the server manually and use a custom async client.
# install YEDB
pip3 install yedb
# to use as embedded or client/server - go on. to use CLI - install additional
# required libraries
pip3 install "yedb[cli]"
# create a new database and go interactive
yedb /path/to/my/database
# set a key
yedb set key1 value1
# get the key value
yedb get key1
# Install required system packages
# Debian/Ubuntu: apt-get install -y --no-install-recommends python3 python3-dev gcc
# RedHat/Fedora/CenOS: yum install -y python3 python3-devel gcc
sudo mkdir /opt/yedbd
cd /opt/yedbd && curl https://raw.githubusercontent.com/alttch/yedb-py/main/setup-server.sh | sudo sh
Use env to specify extra options:
- YEDBD_BIND - override bind to (tcp://host:port, http://host:port or path to UNIX socket)
- YEDBD_SERVICE - system service name
- YEDB_PS - CLI prompt
- PIP_EXTRA_OPTIONS - specify pip extra options
- PYTHON - override Python path
- PIP - override pip path
from yedb import YEDB
with YEDB('/path/to/db', auto_repair=True) as db:
# do some stuff
# OR
db = YEDB('/path/to/db')
db.open()
try:
# do some stuff
finally:
db.close()
- If socket transport requested, the built-in in server requires "msgpack" Python module
- If HTTP transport requested, the built-in server requires "aiohttp" Python module
# listen to tcp://localhost:8870 (default), to bind UNIX socket, specify the
# full socket path, to use http transport, specify http://host:port to bind to
python3 -m yedb.server /path/to/db
- If socket transport requested, the built-in in client requires "msgpack" Python module
- If HTTP transport requested, the built-in client requires "requests" Python module
from yedb import YEDB
with YEDB('tcp://localhost:8870') as db:
# do some stuff, remember to send all parameters as kwargs
YEDB creates thread-local objects. If the software is using permanent threads or a thread pool, it is recommended to use sessions to correctly drop these objects at the end of the statement:
from yedb import YEDB
with YEDB('tcp://localhost:8870') as db:
with db.session() as session:
# do some stuff, remember to send all parameters as kwargs
session.key_set(key='key1', value='val1')
print(session.key_get(key='key1'))
YEDB uses JSON RPC (https://www.jsonrpc.org/) as the API protocol. Any method, listed in yedb.server.METHODS can be called. Payloads can be packed either with JSON or with MessagePack.
If working via UNIX or TCP socket:
-
only MessagePack payload encoding is supported
-
Request/response format: PROTO_VER + DATA_FMT + FRAME_LEN(32-bit little-endian) + frame
Where PROTO_VER = protocol version (0x01) and DATA_FMT = data encoding format (0x02 for MessagePack, which is the only protocol supported by the built-in server).
from yedb import YEDB
with YEDB('/path/to/db') as db:
with db.key_as_dict('path/to/keydict) as key:
key.set('field', 'value')
# If modified, the key is automatically saved at the end of the statement.
The default engine data format is JSON (https://github.com/python-rapidjson/python-rapidjson is detected and imported automatically if present)
Other possible formats and their benefits:
-
YAML - (requires manually installing "pyyaml" Python module) slow, but key files are more human-readable and editable
-
msgpack - (requires manually installing "msgpack" Python module). Fast, reliable binary serialization format. If used, keys can hold binary values as well.
-
cbor - similar to msgpack (requires manually installing "cbor" Python module)
-
pickle - native Python pickle binary data serialization format. Is slower than msgpack/cbor, but keys can hold Python objects and functions as-is.
Databases can be easily converted between formats using "yedb" CLI tool or "convert_fmt" method, unless format-specific features are used (e.g. if keys have binary data, they can't be converted to JSON properly).
See https://github.com/alttch/yedb
As all keys are serialized values, they can be automatically schema-validated with JSON Schema (https://json-schema.org/).
To create the validation schema for the chosen key, or key group, create a special key ".schema/path/to", which has to contain the valid JSON Schema.
E.g. the schema, stored in the key ".schema/groups/group1" will be used for validating all keys in "groups/group1", including the group primary key. And the schema, stored in ".schema/groups/group1/key1" will be used for validating "groups/group1/key1" only (if key or subgroup schema is present, the parent schemas are omitted).
YEDB also supports a non-standard scheme:
{ "type" : "code.python" }
which requires the key to have valid Python code, without syntax errors.
If schema validation fails on set or structure "with" statement exit, an exception yedb.SchemaValidationError is raised.
Full backup: simply backup the database directory with any preferred method.
Partial/server backup:
Use "dump_keys" / "load_keys" methods. If dump is created with CLI (requires "msgpack" Python module for that), it has the format:
DUMP\_VER + DUMP\_FMT
KEY_LEN(32-bit little-endian) + KEY
KEY_LEN(32-bit little-endian) + KEY
KEY_LEN(32-bit little-endian) + KEY
KEY_LEN(32-bit little-endian) + KEY
....
KEY_LEN(32-bit little-endian) + KEY
Start client/server with DEBUG=1 env variable:
DEBUG=1 yedb /path/to/db
to debug when embedded, enable debug logging
import yedb
yedb.debug = True
After, lower the default logging level.