Download as PDF, PPTX
![Partitioning a (read) cache i = hash(key) % len(servers) server = servers[i]](https://image.slidesharecdn.com/databasescalability2010-100219145240-phpapp01/75/What-every-developer-should-know-about-database-scalability-PyCon-2010-14-2048.jpg)
What every developer should know about database scalability, PyCon 2010
- 1. Database scalability Jonathan Ellis/ @spyced
- 3. operations / s = throughput money What scaling means
- 4. “It scales, but” •It scales, but we have to keep adding people to our ops team • It scales, but when the netapp runs out of capacity we're screwed • It scales, but it's not fast
- 5. 2000 2010
- 6. Problem 1 Index Data
- 7.
- 8.
- 9. Two kinds ofoperations • Reads • Writes
- 10. Band-aids • (Not actuallyscaling your database)
- 11. Problem 1: btreessuck • ~100 MB/s sequential writes • ~1.5 MB/s random writes – ~10ms to seek – ~5ms on expensive 15k rpm disks
- 12. Magic bullets • SSD – ~100MB/s random writes (of 4KB) – ~$800 for 64GB • vs ~$200 for 2 TB rotational • Moore's law – Aka the 37signals approach
- 13. Caching • Memcached • Ehcache •etc cache DB
- 14. Partitioning a (read)cache i = hash(key) % len(servers) server = servers[i]
- 15. The cold startproblem
- 16.
- 17. Consistent hashing • libketemafor memcached – Multiple “virtual nodes” per machine for better load balancing
- 18. Cache coherence strategies •Write-through • Explicit invalidation • Implicit invalidation
- 19. Cache set invalidation defget_cached_cart(cart, offset): key = 'cart:%s:%s' % (cart, offset) return get(key) # cart:13:10 def invalidate_cart(cart): ?
- 20. Set invalidation 2 defget_cached_cart(cart, offset): prefix = get_cart_prefix(cart) key = '%s:%s' % (prefix, offset) return get(key) def invalidate_cart(cart): del(get_cart_prefix(cart)) http://www.aminus.org/blogs/index.php/2007/1
- 21. Pop quiz • Cancaching reduce write load?
- 22. Write-back caching foo.bar =1 foo.bar = 2 foo.bar = 4 cache UPDATE foos SET bar=4 WHERE id=3 DB
- 23. Achtung! • Commercial solutions – Terracotta • Roll your own – Memcached – ehcache – Zookeeper?
- 24.
- 25.
- 26. Types of replication •Master → slave – Master → slave → other slaves • Master ↔ master – multi-master
- 27. Types of replication2 • Synchronous • Asynchronous
- 28.
- 29. Synchronous multi-master • Synchronous= slow(er) • Complexity (e.g. 2pc) • PGCluster • Oracle
- 30. Asynchronous master/slave • Easiest •MySQL replication • Slony, Londiste, WAL shipping • Tungsten • MongoDB • Redis
- 31. Asynchronous multi-master • Conflictresolution – O(N3) or O(N2) as you add nodes – http://research.microsoft.com/~gray/replicas.ps • Bucardo • MySQL Cluster • Tokyo Cabinet
- 32. Achtung! • Asynchronous replicationcan lose data if the master fails
- 33. “Architecture” • Primarily abouthow you cope with failure scenarios
- 34. Replication does notscale writes
- 35.
- 36.
- 37. Partitioning • sharding /horizontal / key • Functional / vertical
- 38. Key based partitioning •PK of “root” table controls destination – e.g. user id • Retains referential integrity
- 39.
- 40. Example: blogger.com Users Blogs Comments' Comments
- 41. What server getseach key? • Consistent hashing • Central db that knows what server owns a key – Makes adding machines easier (than – Single point of failure & query bottleneck – MongoDB
- 42. Vertical partitioning • Tableson separate nodes • Often a table that is too big to keep with the other tables, gets too big for a single node
- 43. Users2 Users1 Products1 Vertical segments Both Trans3 Trans2 Trans1 Sharding
- 44.
- 45.
- 46. What these havein common • Not application-transparent • Ad hoc • Error-prone • Manpower-intensive
- 47. To summarize • Scalingreads sucks • Scaling writes sucks more
- 48.
- 49. NoSQL • Distributed (partitioned,scalable) – Cassandra – HBase – Voldemort • Not distributed – Neo4j – CouchDB – Redis
- 50. * Distributed databases • Data is automatically partitioned • Transparent to application • Add capacity without downtime • Failure tolerant *Like Bigtable, not like Lotus Notes
- 51. Two famous papers •Bigtable: A distributed storage system for structured data, 2006 • Dynamo: amazon's highly available key- value store, 2007
- 52. Two approaches • Bigtable:“How can we build a distributed database on top of GFS?” • Dynamo: “How can we build a distributed hash table appropriate for the data center?”
- 53. Cassandra • Dynamo-style replication •Bigtable ColumnFamily data model • High-performance – Digg phasing out memcached • Open space, Saturday at 17:30
- 54.