> Looking forward to when joins are implemented so I can try using it with something non-trivial.
these types of databases typically don't have joins. you'll be waiting a while.
these types of databases typically don't have joins. you'll be waiting a while.
For instance, suppose you want to join on a column that's not a primary key. No big deal in a typical RDBMS; just do an index lookup on the join column. But if your data is sharded across machines, that doesn't work, because you can't update the index without running the risk that readers will observe it in an inconsistent state. Unless you can do transactions, that is.
So I'm optimistic that Cockroach will get join support before too long. The necessary primitives are available, making it "merely" a matter of figuring out the engineering details.
So, while any distributed database can do a join, it may not be fast or flexible enough to be worth it.
Best way to solve a problem is to avoid it.
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?
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.
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.
Please forgive me, but what are you really trying to get at? Otherwise it just seems like naysaying and rabble rousing to me..
Re joins: we have top men working on it right now. Joins are definitely an interesting problem for a distributed database.
Also, what levels of isolation do you actually offer? Serialized snapshot isolation appears to be MVCC, but I see you also have just snapshot isolation - what is the difference?
Edit: oh brother, the proof you link to, I just realized I bought that book some time ago and never got around to reading it... Transactional Information Systems by Weikum & Vossen, right? time for me to hit the books I guess. Still trying to get my head around that second graph you have drawn, can't work out how you have gotten it :(
For now CockroachDB's supports a subset of the SQL implemented by other databases, with some extensions of its own. This subset will grow over time.
The two levels of isolation offered are snapshot (SI) and serializable (SSI). Snapshot means that concurrent transactions are atomic with regards to each other and "see" the same initial state from the DB. Serializable adds into this that they can't introduce write skews, ie if there are concurrent transactions they will "see" each others effects in some order.
Joins over a distributed database aren't easy. Love to see what you have going! The main issue I see with distributed joins are that they need to be done in a single transaction - if even one table gets an insert, delete or update then it invalidated the join. But this distributed serialised snapshot isolation, that sounds like it might be the best way around it.
And if you add an additional requirement to correctly execute ad hoc consistent joins under very high write workloads and continuous failures, then it is definitely non-trivial engineering. But it is possible, I've designed implementations like this before, it just requires a very high degree of effort and skill that is rarely applied to the design of typical NoSQL databases.