Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- ## Consistency?
- ### Weak
- - After a write, reads may or may not see it
- - Best effort only
- - Memcached
- - VoIP, live online video
- - Online multiplayer games
- ### Eventual
- - After a write, reads will eventually see it
- - Mail
- - Search engine indexing
- - DNS, SMTP
- - Amazon S3, SimpleDB
- ### Strong
- - After a write, reads will see it
- - File systems
- - RDBMSes
- - Azure tables
- ## Why transactions?
- Transfer money from A to B:
- 1. Subtract from A
- 2. Add to B
- What if something else happens between those operations?
- - Correctness
- - Consistency
- - Enforce invariants
- - ACID
- A (atomic):
- C (consistent):
- I (isolated):
- D (durable):
- ## Why across datacenters?
- - Catastrophic failures: fires, power shortage
- - Geolocality: server close to the user => less latency
- - CDN
- Within a datacenter
- - High bandwidth: 1 - 100Gbps
- - Low latency: < 1 ms within rack, 1 - 5 ms across
- - Cheap
- Between datacenters
- - Low bandwidth: 10 Mbps - 1 Gbps
- - High latency: 50 - 150 ms
- - Fiber is expensive!
- ## Multihoming
- - Hard problem
- - ... consistenly? -> harder
- - ... with real time writes? -> hardest
- Option 1: don't
- - Bunkerize: MS Azure, Amazon SimpleDB
- - Bad at catastrophic failure: data loss
- - Not great for serving: no geolocation
- Option 2: primary with hot failover(s)
- - Better but not ideal: mediocre at catastrophic failure, window of lost data, failover data may be inconsistent
- - Amazon Web Services: EC2, S3, SQS, choose US or EU; EC2 - availability zones, ELB
- - Banks, brokerages
- - Geolocated for reads, not for writes
- Option 3: true multihoming
- - Simultaneous writes in different DCs
- - Two way: hard
- - N way: harder
- - Handle catastrophic failure, geolocality
- - ... but pay for it in latency
- ## Techniques and tradeoffs
- ## Conclusions
- - No silver bullet!
Add Comment
Please, Sign In to add comment