Understanding nodes, clusters, replication & sharding in ActorDB about actordb HOT 4 CLOSED

Mostly correct. More nodes in a cluster do not increase write throughput, but they do increase read throughput. Writes get replicated to all nodes within a cluster. You are actually decreasing write throughput with every additional node. More nodes in a cluster increases reliability.

More clusters increase throughput and storage capacity.

from actordb.

Thanks for the clarification.

Some related follow up questions:

• I imagine that actors of the same type will be spread over multiple clusters as their number grows.
• A complete backup would involve backing up the /path/to/source/lmdb for any node in each cluster for all clusters.

Is this right?

Is there a way to do realtime streaming backups?

from actordb.

I imagine that actors of the same type will be spread over multiple clusters as their number grows.

Yes

A complete backup would involve backing up the /path/to/source/lmdb for any node in each cluster for all clusters.

Yes. Generally you could get away with just backing up one of the nodes in the cluster, but backing up every node is safer because so you don't loose writes that may not have been fully replicated to the node you are backing up.

Real time streaming backups are not available at the moment yet. I think it's on the roadmap for LMDB, which we can piggy back on. It would be possible to do it without waiting for them, but it would not be as efficient.

We are considering a geo replication mode, which would basically be a backup option. Right now the plan is: An active cluster in one datacenter, replicates to another (or more) passive cluster in another datacenter. Then there is an API call that switches which of the two clusters is the active one. This idea may change however. It's our thinking at the moment.

from actordb.

This clarifies the idea I have of ActorDB in my head. It's great to see that streaming backups and geo replication are being considered and I agree with your view on waiting for LMDB to implement it.

I'll continue digging into ActorDB further and will probably be asking some more questions :)

from actordb.