> "With Clustrix, you never have to worry about database scalability again."
That's a huge claim. My two super-basic questions, which I can't find answered on the site, are:
1) Let's say I need to join 100,000 rows in one table to 100,000 rows in another table, all matching ID's and indexed, and then SUM certain values in the second table. If Clustrix has distributed the rows/tables across different machines, how long is this going to take, compared to a single-machine solution?
2) How do transactions work on a single table? If four people are doing INSERT's with an AUTOINCREMENT on the same table, but on four different machines (because it's distributed), how is this going to wind up being faster than on a single server? How are the four new ID's not going to collide? And since presumably one machine is responsible for preventing collision, how does that machine not become a bottleneck?
I'd love to know what kind of advanced techniques can solve these problems.
That's a huge claim. My two super-basic questions, which I can't find answered on the site, are:
1) Let's say I need to join 100,000 rows in one table to 100,000 rows in another table, all matching ID's and indexed, and then SUM certain values in the second table. If Clustrix has distributed the rows/tables across different machines, how long is this going to take, compared to a single-machine solution?
2) How do transactions work on a single table? If four people are doing INSERT's with an AUTOINCREMENT on the same table, but on four different machines (because it's distributed), how is this going to wind up being faster than on a single server? How are the four new ID's not going to collide? And since presumably one machine is responsible for preventing collision, how does that machine not become a bottleneck?
I'd love to know what kind of advanced techniques can solve these problems.