4 ms·

well the comparison section to RDS specifically claims that RDS is inferiors because "this forces all writes to travel to the primary copy of your data". So it

by pdeva1 9y ago

well the comparison section to RDS specifically claims that RDS is inferiors because "this forces all writes to travel to the primary copy of your data". So it doesn't explain how CDB is superior to RDS, since writes will incur the same penalty in CDB too.

irfansharif 9y ago
At the key-value level, CockroachDB starts off with a single, empty range (a set of sorted, contiguous data from your cluster). As you put data in, this single range eventually reaches a threshold size (64MB by default). When that happens, the data splits into two ranges, each again covering a contiguous segment of the entire key-value space. This process continues indefinitely; as new data flows in, existing ranges continue to split into new ranges, aiming to keep a relatively small and consistent range size. Each range is replicated 3-way (by default) as well, and is backed by a single Raft instance. When your cluster spans multiple nodes (physical machines, virtual machines, or containers), newly split ranges (or more specifically, replicas of these ranges) are automatically rebalanced to nodes with more capacity. Writes addressed to a range are handled by the Raft leader for that range (which can hop around its various replicas as needed). Writes to different ranges (non-overlapping key spaces by definition) are processed independently, and very well may be processed across multiple machines. Source: https://www.cockroachlabs.com/docs/stable/frequently-asked-questions.html https://www.cockroachlabs.com/docs/stable/frequently-asked-q...
- pdeva1 9y ago
  what you described is the mechanism to deal with scalability, ie throughput. What is being disputed is the claim to latency. Every bit of data needs to be replicated across multiple regions consistently and that will incur the same latency as rds or any other consistent database
  - irfansharif 9y ago
    Given the flexibility of where the range raft leader could be, CRDB makes an active effort to colocate it near to where the requests originate from (which is some part of what the CDN parallel was alluding to with low RTT for multi-region deployments). WRT to the writes here, if a majority of the replicas for that range are in the proximate regions, the requests would only travel that far before responding. I believe the argument is that this a more flexible design point than a single point of entry for all incoming writes, regardless of the origin. The cost to write out to the furthest region within any majority of replicas is of course inevitable to have cross-region durability, alternatively you could trade this off to have the majority of your replicas specific to requests from a specific region, be located to that specific region.
    - pdeva1 9y ago
      > The cost to write out to the furthest region within any majority of replicas is of course inevitable to have cross-region durability So we are in agreement that CDB has same write latency as rds for multi region deployments. The article seems to imply that is not the case, but as you yourself agree it actually is.
      - irfansharif 9y ago
        No? Apologies if I'm not able to communicate as clearly. The RTT would be to the furthest replica within `n` replicas ordered by proximity to the query origin, where `n` is the number it would take to have a majority within the specified replication factor (so 2 for a replication factor of 3, 3 for 5, etc.). It would be different from the RTT observed with Amazon RDS as long as the furthest replica, as described above, is in a different zone/region/DC as compared to RDS's primary instance (assuming a similar topology). So with a replication factor of 3, if your DCs are in the UK, Australia and the US, if the RDS primary was in the US, all write requests from Australia would have to travel over to the US. But with a replica in each zone, write requests from Australia would hit the DC in Australia, and the DC in UK, avoiding the larger RTT to the US. To reiterate: I believe the argument is that this a more flexible design point than a single point of entry for all incoming writes, regardless of the origin.
- redwood 9y ago
  How are ranges with implicit leader-region association associated with appropriate writers near to respective region? Seems like you must range by location for this to work

by pdeva1 9y ago

irfansharif 9y ago

At the key-value level, CockroachDB starts off with a single, empty range (a set of sorted, contiguous data from your cluster). As you put data in, this single range eventually reaches a threshold size (64MB by default). When that happens, the data splits into two ranges, each again covering a contiguous segment of the entire key-value space. This process continues indefinitely; as new data flows in, existing ranges continue to split into new ranges, aiming to keep a relatively small and consistent range size. Each range is replicated 3-way (by default) as well, and is backed by a single Raft instance. When your cluster spans multiple nodes (physical machines, virtual machines, or containers), newly split ranges (or more specifically, replicas of these ranges) are automatically rebalanced to nodes with more capacity. Writes addressed to a range are handled by the Raft leader for that range (which can hop around its various replicas as needed). Writes to different ranges (non-overlapping key spaces by definition) are processed independently, and very well may be processed across multiple machines. Source: https://www.cockroachlabs.com/docs/stable/frequently-asked-questions.html https://www.cockroachlabs.com/docs/stable/frequently-asked-q...

pdeva1 9y ago
what you described is the mechanism to deal with scalability, ie throughput. What is being disputed is the claim to latency. Every bit of data needs to be replicated across multiple regions consistently and that will incur the same latency as rds or any other consistent database
- irfansharif 9y ago
  Given the flexibility of where the range raft leader could be, CRDB makes an active effort to colocate it near to where the requests originate from (which is some part of what the CDN parallel was alluding to with low RTT for multi-region deployments). WRT to the writes here, if a majority of the replicas for that range are in the proximate regions, the requests would only travel that far before responding. I believe the argument is that this a more flexible design point than a single point of entry for all incoming writes, regardless of the origin. The cost to write out to the furthest region within any majority of replicas is of course inevitable to have cross-region durability, alternatively you could trade this off to have the majority of your replicas specific to requests from a specific region, be located to that specific region.
  - pdeva1 9y ago
    > The cost to write out to the furthest region within any majority of replicas is of course inevitable to have cross-region durability So we are in agreement that CDB has same write latency as rds for multi region deployments. The article seems to imply that is not the case, but as you yourself agree it actually is.
    - irfansharif 9y ago
      No? Apologies if I'm not able to communicate as clearly. The RTT would be to the furthest replica within `n` replicas ordered by proximity to the query origin, where `n` is the number it would take to have a majority within the specified replication factor (so 2 for a replication factor of 3, 3 for 5, etc.). It would be different from the RTT observed with Amazon RDS as long as the furthest replica, as described above, is in a different zone/region/DC as compared to RDS's primary instance (assuming a similar topology). So with a replication factor of 3, if your DCs are in the UK, Australia and the US, if the RDS primary was in the US, all write requests from Australia would have to travel over to the US. But with a replica in each zone, write requests from Australia would hit the DC in Australia, and the DC in UK, avoiding the larger RTT to the US. To reiterate: I believe the argument is that this a more flexible design point than a single point of entry for all incoming writes, regardless of the origin.
redwood 9y ago
How are ranges with implicit leader-region association associated with appropriate writers near to respective region? Seems like you must range by location for this to work