6 ms·

Joins in distributed databases all must make some sort of unsavory tradeoff be it speed or space or limiting what you can join. So, while any distributed datab

Joins in distributed databases all must make some sort of unsavory tradeoff be it speed or space or limiting what you can join. So, while any distributed database can do a join, it may not be fast or flexible enough to be worth it.

wichsen 10y ago
You are right. And without data and performance numbers there is no way to extrapolate beyond "potential" scenarios and outcomes. Please forgive me, but what are you really trying to get at? Otherwise it just seems like naysaying and rabble rousing to me..
teraflop 10y ago
One could say exactly the same thing about joins in non-distributed databases. "You have to make some kind of tradeoff" is a platitude.
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.

wichsen 10y ago

You are right. And without data and performance numbers there is no way to extrapolate beyond "potential" scenarios and outcomes. Please forgive me, but what are you really trying to get at? Otherwise it just seems like naysaying and rabble rousing to me..

teraflop 10y ago

One could say exactly the same thing about joins in non-distributed databases. "You have to make some kind of tradeoff" is a platitude.

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.