3 ms·

ActorDB is a neat project. Simplified, it's a distributed SQLite where consistency is guaranteed by the Raft protocol. However, it has a unique and initially c

ActorDB is a neat project. Simplified, it's a distributed SQLite where consistency is guaranteed by the Raft protocol. However, it has a unique and initially confusing data model where the database is divided into "actors", which are self-contained shards. For example, a database modeled on Hacker News would probably have an actor per user and an actor per story, and probably an actor per thread. Every actor acts like a self-contained database, with its own set of tables. When you want to query or update data, you first tell it which actor(s) to operate on; but unlike systems like Cassandra, the sharding is explicit, in that the shards have identifiers, and there's no automatic sharding function. Indeed, you can have actors that act like a basic database, e.g. a global, shared list of lookup values could be a single actor. You have ACID transactions within actors, and you can also do transactions across actors, and queries can also span multiple actors. You can't do joins across actors, as far as I recall. Schema migrations also become interesting, since each actor has its own, entirely separate schema.

smt88 8y ago
This model is pretty interesting and might make GDPR compliance easier, if I'm understanding it correctly
- bonesss 8y ago
  In terms of GDPR compliance the fundamental element is pseudonymization of internal dataflows and data management -- that'll work with any data store. I mean, there is some possible advantage by having all users in their own actor-namespace, for bulk deletes and concrete mapping of data-usage, but IME you're always stuck with a need to preserve the operational state of the application and the quality of its legacy data. Regardless of sharding strategy, somehow your datawarehouse needs to be able to pull out or confirm data from the previous quarter...
dnomad 8y ago
> You have ACID transactions within actors, and you can also do transactions across actors I gotta say... this project strikes me as very strange. If you're going to go through all the trouble of sharding your data across a set of HA actors... why not also shard behavior? Co-locate data and behavior! Isn't that a key driver Actor model? Then you wouldn't communicate with your actors using a very limited language like SQL you could send them real domain-specific messages. Most importantly, when it comes to transactions across actors... you don't need it. All you need is guaranteed message delivery to the various actor mailboxes and all that complexity melts away. You need this anyways if you want your actors to be able to actually collaborate and send each other messages. This whole project seems to be designed to eliminate many of the benefits of the actor model... (I don't like the all-too-common HN cynicism but I also worry when I see stuff like this. Either I'm crazy and missing something obvious... or everybody else is crazy. But then much of what comes out of the Erlang space is... strange to me. That culture seems to have a very unique idea of distributed computing.)
- atombender 8y ago
  I think you have to think of the "actors" in ActorDB as shards, not as actors in the "actor model" sense. The nomenclature here is unfortunate, because actors themselves are sharded. This is a database that permits any application to read and write data without coupling it to a specific language or platform, e.g. Erlang. You just write SQL. People know SQL. The difference is that your app must be shard-aware, which can be an acceptable compromise for apps that wants to scale far. The sharding also gives you some measure of enforced encapsulation, since you can't have foreign keys (that I know) across actors. This project might be particularly suitable for SaaS-type multitenant systems that need to have a clear boundary between each tenant.
  - bobwaycott 8y ago
    Admittedly, I read through all the docs in one rapid sitting, but I thought I came across mention of foreign keys across actors being supported. I’ll have to double-check that, though.
abledon 8y ago
You have a great knack for explaining these concepts clearly for a beginner like myself . If you ever consider writing a technical book I think it would be great!

smt88 8y ago

This model is pretty interesting and might make GDPR compliance easier, if I'm understanding it correctly

bonesss 8y ago
In terms of GDPR compliance the fundamental element is pseudonymization of internal dataflows and data management -- that'll work with any data store. I mean, there is some possible advantage by having all users in their own actor-namespace, for bulk deletes and concrete mapping of data-usage, but IME you're always stuck with a need to preserve the operational state of the application and the quality of its legacy data. Regardless of sharding strategy, somehow your datawarehouse needs to be able to pull out or confirm data from the previous quarter...

dnomad 8y ago

> You have ACID transactions within actors, and you can also do transactions across actors I gotta say... this project strikes me as very strange. If you're going to go through all the trouble of sharding your data across a set of HA actors... why not also shard behavior? Co-locate data and behavior! Isn't that a key driver Actor model? Then you wouldn't communicate with your actors using a very limited language like SQL you could send them real domain-specific messages. Most importantly, when it comes to transactions across actors... you don't need it. All you need is guaranteed message delivery to the various actor mailboxes and all that complexity melts away. You need this anyways if you want your actors to be able to actually collaborate and send each other messages. This whole project seems to be designed to eliminate many of the benefits of the actor model... (I don't like the all-too-common HN cynicism but I also worry when I see stuff like this. Either I'm crazy and missing something obvious... or everybody else is crazy. But then much of what comes out of the Erlang space is... strange to me. That culture seems to have a very unique idea of distributed computing.)

atombender 8y ago
I think you have to think of the "actors" in ActorDB as shards, not as actors in the "actor model" sense. The nomenclature here is unfortunate, because actors themselves are sharded. This is a database that permits any application to read and write data without coupling it to a specific language or platform, e.g. Erlang. You just write SQL. People know SQL. The difference is that your app must be shard-aware, which can be an acceptable compromise for apps that wants to scale far. The sharding also gives you some measure of enforced encapsulation, since you can't have foreign keys (that I know) across actors. This project might be particularly suitable for SaaS-type multitenant systems that need to have a clear boundary between each tenant.
- bobwaycott 8y ago
  Admittedly, I read through all the docs in one rapid sitting, but I thought I came across mention of foreign keys across actors being supported. I’ll have to double-check that, though.

abledon 8y ago

You have a great knack for explaining these concepts clearly for a beginner like myself . If you ever consider writing a technical book I think it would be great!