I’m happy to introduce ProfaneDB. Before anything else; I’d like to make it clear that I’m not even trying to compete with all the NoSQL databases out there. I don’t have the competence nor the time those great developers put into the many flavours of database you might come across.
ProfaneDB wants to address a very specific scenario, that is serialising and storing Protobuf messages, avoiding data duplication and being able to retrieve them easily.
Storing a message tree
Imagine having a tree of messages. For instance
message Manufacturer {
string name = 1;
}
message Car {
string plate = 1;
Manufacturer manufacturer = 2;
int32 mileage = 3;
}
message User {
string email = 1;
repeated Car cars = 2;
}
Using plain old SQL
Now this could be stored
in a SQL database in 3 (or 4) tables.
But what if you were dealing with a mobile app and a central database?
You’d definitely need a backend server where the messages are taken as Protobuf, deserialized and made into SQL; and viceversa when sending them back to your app.
vs ProfaneDB solution
Consider a key-value database: what if we could just store messages like this?
| key | value |
|---|---|
| @Manufacturer/Ford | { name: "Ford" } |
| @Car/AB123CD | { plate: "AB123CD", manufacturer: @Manufacturer/Ford, mileage: 50000} |
| @User/test@email.com | { email: "test@email.com", cars: [ @Car/AB123CD, @Car/... ] } |
Let’s understand what we did here:
1. key:
the key is composed using the message name
and a unique identifier. For instance:
email for a User,
and plate for a Car.
2. value:
is shown as JSON-like heres,
but in fact it will be stored
as serialised Protobuf.
Nested messages are saved as a reference.
If we now edited mileage for @Car/AB123CD,
the change would be propagated
to the car owned by @User/test@email.com.
About relationships
We mentioned earlier how SQL could have used 3 or 4 tables. But why did I say this?
The first implementation I would think of,
would be with Car table
having a foreign key to User named owner.
Cars though, can have multiple owners,
hence requiring a many-to-many relationship.
If we realised this at a later stage, we’d now need yet another table, with references to both Car and User, and most of all, new code to deal with this.
You can forget about all this in ProfaneDB!
Protobuf allows arrays,
and a list of messages is made into
a list of references to them.