There's too many databases that abbreviate to CDB :P
This is interesting, but the weird thing is that I'm not sure this is all that different from e.g. hand sharding at the application level. By that I mean that ComDB2 doesn't seem to provide a real way of seamlessly sharding your data. Near the end of the paper:
> Under our design, each portion of the table has its own master (getting many of the benefits of a multi-master system) and is able to write to the portion it owns without coordinating with partitions uninvolved in the transaction.
Maybe the paper is missing some details on how queries and transactions are coordinated between masters, but it seems to imply that the application level has to handle this kind of stuff.
The section you're referring to is the work underway to increase write performance, which is currently bounded by the master node's ability to process bplogs (an internal structure used to detect write-write conflicts).
re: 'the application level has to handle [sharding]', the table partitioning described in this section is merely a conceptual model 'assigning' masters to what are presumably non-overlapping row ranges in order to increase write throughput (writes/reads will be processed via that specific master). The behaviour of the system still resembles a single node database, this is alluded to intermittently throughout.
(also CRDB is the preferred acronym for CockroachDB haha, source: interning there)
> The behaviour of the system still resembles a single node database, this is alluded to intermittently throughout.
The impression that I get from reading the paper is that this is only true as long as the interaction involves only a single master. Or at the very least, situations where the working set has to be sharded among multiple masters are not described in any detail.
This is interesting, but the weird thing is that I'm not sure this is all that different from e.g. hand sharding at the application level. By that I mean that ComDB2 doesn't seem to provide a real way of seamlessly sharding your data. Near the end of the paper:
> Under our design, each portion of the table has its own master (getting many of the benefits of a multi-master system) and is able to write to the portion it owns without coordinating with partitions uninvolved in the transaction.
Maybe the paper is missing some details on how queries and transactions are coordinated between masters, but it seems to imply that the application level has to handle this kind of stuff.