Re:The Uber Engineering Tech Stack, Part I: The Foundation
by scaleout1 on Sunday July 24, 2016 @01:33PM
(#12153968)
Thats an interesting approach. One question though, in our use case user often travel from city to city and country to country. How do you model that if you are only using local DC and local replications?
Re:The Uber Engineering Tech Stack, Part I: The Foundation
by methehack on Sunday July 24, 2016 @02:34PM
(#12154216)
I think the regional keyspaces would be have to be caches -- denormalize it, basically. Pop/re-fresh people into the geo-based caches as they moved around. Truth sits behind it, centralized (perhaps partitioned in some way that makes sense globally but is sub-optimal from a regional cache perspective). Might not be worth it -- hard to know from here. :)
Re:The Uber Engineering Tech Stack, Part I: The Foundation
by ajslater on Sunday July 24, 2016 @07:00PM
(#12155358)
afaik, this is how Facebook does it, but with regional sources of truth.
If you signed up for FB in Paris and move to San Francisco, your master profile lives in Europe in perpetuity and you'll use your regional cache forever in the USA.
The number of people moving far away from their home DC's should be a reasonably small fraction of the total for it not to matter.
Create a global Cassandra cluster with regional datacenters.
Use one keyspace per region
Use per-keyspace replication to only replicate that region's data locally, and to one or more additional datacenters
Have stateless app servers colocated with Cassandra in each DC handling all local traffic
Run spark on top of Cassandra to do analytics, or to do the etl to a dedicated analytics system
Optionally have a single "master" DC, with replicas of all data from all locations, that doesn't serve end user traffic, but is to allow efficient cross region analytics.
Profit (optional step)
And yes, the company I work for (Datastax) has a product and services to help make it simple.