Hacker News new | past | comments | ask | show | jobs | submit login

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



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.


> 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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: