Hacker News Reader

Comment by muxator | Hacker News Reader

1) Apart from interleaved tables [0], what are the possibile solutions for multi tenancy?

2) Is there a published benchmark on performance on join-heavy workloads?

https://www.cockroachlabs.com/docs/stable/interleave-in-pare...

I'm not sure how interleaved tables help you with multi-tenancy, but I'd be curious to find out. If, by multi-tenancy, you mean sharing a CRDB cluster between different applications or different instances of the same application, or different organizations all-together (say, in a hosted cluster that 3rd parties get access to), we don't have particular support for any of these. If each client is configurable with a user and a database, you can created different users/databases for each one and set the appropriate permissions. You can even set different placement options for the different databases if you want some in Asia and some in Africa. When it comes to usage accounting, resource isolation, specific monitoring, there's nothing built-in at the moment.

I’m currently a developer at Cockroach working on interleaved tables.

If by multi tenancy you mean sharding by a particular column (or set of columns) to groups of nodes, interleaved tables are probably not what you’re looking for. Table partitioning is currently on the roadmap and you can find the RFC here https://github.com/cockroachdb/cockroach/blob/master/docs/RF....

Thanks rwu1997, I am referring to this advice given by Ben Darnell: https://forum.cockroachlabs.com/t/multi-tenancy-best-practic...

Interleaving does try to colocate the interleaved tables by taking advantage of the fact that the underlying SSTable storage sorts the data by their keys. It doesn't however guarantee that a sufficiently large interleave hierarchy of tables will be colocated on the same node(s) due to range splits (each range has a default maximum size of 64MB).

I'm looking forward to the partitioning work being done right now since one could in theory have a top-level (or root) table (with some tenantID) and tenant-specific tables interleaved, then easily partition on the tenantID to have tenancy isolation on all tenant-specific data.

re: #2 - We don’t have a published benchmark yet, but we will start sharing these in the coming months. Our early tests on key-value workloads (the published benchmarks will include TPC-C like workloads) have shown that our throughput is on par with Postgres when it's running with similar guarantees (ie serializable mode rather than read-committed).

Reply on news.ycombinator.com