6. Efficiency

6.1 Batching

ActorDB is very good at batching multiple operations together into a single event.

Per-actor it will batch reads and writes before sending them to the SQL engine. If two concurrent writes are sent to the same actor, they are likely to be combined into a single call to SQL/storage engine.

If concurrent writes are sent to different actors on the same node, they are likely to be a part of the same LMDB transaction.

ActorDB will even batch together RPC calls between nodes.

To make batching work well, ActorDB should be accessed concurrently through many connections. Having a single connection and running queries only through it will work poorly.

6.2 Parameterized queries

You should always use parameterized queries. This will cut down on the SQL parsing time and it will prevent any SQL injection attacks.

6.3 Schema

A common question is how to split your data model into actors. There can be multiple ways of thinking about it.

1. - Scalability: keep a single actor under 1000 reqs/s.
2. - Size: keep an actor in the megabyte range. Though having 100GB should work fine. But once the actor gets this large, so do its indexes and tables. Large actors are much more cumbersome and schema changes and queries get slower.
3. - Natural sharding key: are your queries almost always relating to a user, file or some other identity? This is your actor name.

ActorDB encourages splitting the problem into a smaller chunk. If you find yourself using actor mytype(*), think about extracting your data into a new actor type. Even if that data is a single actor. There is nothing wrong with having an actor type and only having a single actor for that type.

If your sharding factor is fine grained (i.e. small amount of data per key), instead of using regular actors use the KV store.