3 ms·

Joins in ActorDB work great. Of course that is because we use an entirely different way of making an SQL database distributed and our joins aren't actually dist

by biokoda 10y ago

Joins in ActorDB work great. Of course that is because we use an entirely different way of making an SQL database distributed and our joins aren't actually distributed even though the database is. Best way to solve a problem is to avoid it.

tyingq 10y ago
I looked at ActorDB, with the thought of using it as a sort of "Sql Enabled" version of etcd. Meaning, storing config data, mostly reads, with no big performance requirements. But, the use case is to ensure that the config data is available on all nodes....high availability. So, for example, sharding isn't wanted or needed. It was difficult, however, to get my arms around the whole "actor model", and understand how to use ActorDB in this relatively simple deployment. Long story short, is there some reference, or dead simple example of a "single actor" deployment with a small number of tables?
- biokoda 10y ago
  It's no different from any other deployment really. You have a single actor type in your init.sql then when you send in queries you always specify the same actor. It's easier to explain if you tell me what you don't understand.
  - tyingq 10y ago
    It's basically trying to figure out what the purpose of an "actor" is, and what it means in terms of schema design. I can't tell if I'm supposed to use multiple actors because it adds some kind of resilience, or performance, or something else? On the surface, it seems analogous to "CREATE DATABASE" / "USE DATABASE", but then the examples show applications using multiple actors...which wouldn't be typical (one app / multiple databases). So, it seems clear the idea is multiple actors within a single app, but what drives the choice of what the actors are? If the documentation started with some deeper explanation of actors, it might be easier to follow...as is, it jumps into actor syntax, creation, etc, without the reader really knowing what one is first. I do get that this might be unique to me...I'm just not grocking the concept.
    - biokoda 10y ago
      If you're an email host, an actor would be an email account. If you're dropbox/evernote/wunderlist, an actor would be a user account. If you're a payment processor, every payment would be an actor. If you're a messaging app, an actor would again be a user. If you have user groups, then every group would also be an actor. For your use case. An actor would be configuration for an app. If you have multiple apps (or services), they would have their own actors.

by biokoda 10y ago

tyingq 10y ago

I looked at ActorDB, with the thought of using it as a sort of "Sql Enabled" version of etcd. Meaning, storing config data, mostly reads, with no big performance requirements. But, the use case is to ensure that the config data is available on all nodes....high availability. So, for example, sharding isn't wanted or needed. It was difficult, however, to get my arms around the whole "actor model", and understand how to use ActorDB in this relatively simple deployment. Long story short, is there some reference, or dead simple example of a "single actor" deployment with a small number of tables?

biokoda 10y ago
It's no different from any other deployment really. You have a single actor type in your init.sql then when you send in queries you always specify the same actor. It's easier to explain if you tell me what you don't understand.
- tyingq 10y ago
  It's basically trying to figure out what the purpose of an "actor" is, and what it means in terms of schema design. I can't tell if I'm supposed to use multiple actors because it adds some kind of resilience, or performance, or something else? On the surface, it seems analogous to "CREATE DATABASE" / "USE DATABASE", but then the examples show applications using multiple actors...which wouldn't be typical (one app / multiple databases). So, it seems clear the idea is multiple actors within a single app, but what drives the choice of what the actors are? If the documentation started with some deeper explanation of actors, it might be easier to follow...as is, it jumps into actor syntax, creation, etc, without the reader really knowing what one is first. I do get that this might be unique to me...I'm just not grocking the concept.
  - biokoda 10y ago
    If you're an email host, an actor would be an email account. If you're dropbox/evernote/wunderlist, an actor would be a user account. If you're a payment processor, every payment would be an actor. If you're a messaging app, an actor would again be a user. If you have user groups, then every group would also be an actor. For your use case. An actor would be configuration for an app. If you have multiple apps (or services), they would have their own actors.