Actorbase, or the Persistence Chaos

everybody out there is talking about big data, nosql databases, reactive programming, and so on. there are a lot of buzzwords that are constantly used in this era and those are only some of them.

the idea i will describe to you in a moment is something that's i've been thinking about for a couple of years. my busy life brings me very little time to work on side projects out of work, so i decided to let some other people try to transform my idea into a real thing.

but as usual, let’s start from the beginning.

why we need nosql databases

this section won't be a detailed list of the reasons why we need nosql databases. certainly, we've learned so far that the word "nosql" stands for "not only sql." we've learned that properties of sql database are awesome. being acid is such a great thing.

the problem is that a database that tries to guarantee acid properties cannot scale in a distributed fashion. scalability is what we need to allow our massive applications to adapt themselves to because of the constant increases in load. (do you really own such an application? i mean, i don’t!)

so, why not only sql ? because if we don’t specifically need the relational part, we love to query our databases using sql!

what kinds of nosql databases are out there?

there is a variety of types of nosql databases. the most famous are the following:

• document-oriented such as mongodb .
• graph-oriented such as neo4j .
• column-oriented such as apache hbase .
• key-value maps such as amazon dynamodb .

more or less, all the above types of database are a specialization of key-value maps in which the values may or may not have some form of structure. in my opinion, the killing feature of a database based on the key-value model is that it is naturally ported to scale . different sets of keys can be stored in different nodes, located in different places, replicated many types, and so on.

now, the only thing you have to choose is how to scale. which kind of mechanism will manage your key-value couples?

the actor model

the actor model is a well-known mathematical model that abstracts concurrent and distributed programming into actors . as john mitchell wrote once:

each actor is a form of reactive object, executing some computation in response to a message and sending out a reply when the computation is done.

the only action that an actor can do is receive messages (requests), respond to other actors’ requests, and create a new actor if it is needed. the state of an actor is not accessible from outside the actor. every operation the actor does can be considered as being done in isolation. no race conditions. no mutable shared state. no shared state at all. boom!

during its life, an actor can change its interface, which means that it can change the type of messages it is able to manage. virtually every change of interface corresponds to the creation of a new actor.

in addition to actors, messages are the other core component of an actor system. there can be different implementation messages. one possibility is to have a message compose of:

• a tag : an identifier of the request.

• a target : an identifier of the actor to which sending the message.

• data : information to be sent within the message.

why are we talking about the actor model? because actors can be distributed physically in different nodes of a network. in this way, it should be simpler to develop a distributed application as well as a nosql database.

actor model + nosql database = actorbase

what can happen if we try to implement a nosql database using actors? first of all, we have to choose a nosql database model that can fit the actor model. let’s choose a key-value map database and let each actor manage a portion of the map. we can call these kinds of actors storekeepers (sk). the number of sk actors that hold a map can be decided by the user with a parameter or it can be derived directly from the number of rows contained in the map.

every sk actor has one or more ninja (nj) actor associated with it. this kind of actor executes on a different node of the architecture with respect to its sk actor. its aim is to replicate the data held by an sk actor. in the case of death of the sk, an available nj actor will be elected as leader (aka the new sk actor; please refer to leader election documentation for more info).

actors of type storefinder (sf) will receive data modification/query requests from outside and they will forward them to the relative sk. actors of type sf define something similar to indexes on map keys — the more sf, the fewer messages will be needed to perform an action to data. the access point to the database from drivers and command uis is an actor of type sf called the main actor (mn).

another type of actor that populates our architecture is the warehouseman (wh). these actors have the responsibility to persist to disk information stored into maps by the sk actors.

last but not least, manager actors (mn) try to maintain the equilibrium inside the sks. in fact, mn actors trace the number of entries stored in each map. if their heuristic tells them that some sk actor is under heavy load, they will create a new actor of type sk to properly redistribute that load.

the figure below shows a logical schema of the possible interactions between the actor described above.

the story so far

okay, okay, wait a minute. which is the syntax of the query language? which are the technical features of this database? well, this is simply a proposal i gave to my computer science students of the software engineering course at the department of mathematics of the university of padova.

they have to develop a system that respects the above constraints using scala as programming language and akka as the reference actor model. they already produced the document containing the software requirement analysis and they are now approaching to the design and development processes.

once the database is ready, it will be interesting to study which properties it will satisfy. for example, which features of the cap theorem will it have? which will be the use cases for such database?