4 ms·
To me it looks like there are not many affordable options right now. CockroachDB understandably wants you to use their Cloud or Enterprise products: the OSS ve
by cuu508 6y ago
To me it looks like there are not many affordable options right now.
CockroachDB understandably wants you to use their Cloud or Enterprise products: the OSS version is quite limited. For example it doesn't support row-level partitioning (https://www.cockroachlabs.com/docs/stable/configure-replication-zones.html https://www.cockroachlabs.com/docs/stable/configure-replicat...). Which means, if I understand correctly, it is not of much help for scaling writes to a single big table.
- kevincox 6y agoOh, I didn't realize that the free version was that limited. I guess I need another name to use as the default open source distributed database.
- berns 6y agoNo, you didn't understand correctly. The feature that isn't supported is row level replication zones. Replication zones allows to define the location of replicas.
- nvanbenschoten 6y agoHi cuu508, CockroachDB engineer here. You are correct that row-level partitioning is not supported in the OSS version of CRDB. However, it sounds like there's a bit of confusion about where manual table partitioning is and is not needed. The primary use-case for row-level partitioning is to control the geographic location of various data in a multi-region cluster. Imagine a "users" table where EU users are stored on European servers and NA users are stored on North American servers. If you are only looking to scale write throughput then manual partitioning is not be needed. This is because CRDB transparently performs range partitioning under-the-hood on all tables, so all tables scale in response to data size and load automatically. If you are interested in learning more, https://www.cockroachlabs.com/docs/stable/architecture/distribution-layer.html https://www.cockroachlabs.com/docs/stable/architecture/distr... discusses these concepts in depth.
- cuu508 6y agoThanks for explaining, and sorry -- looks like I jumped to conclusions too quickly!