Datastore Axes: Choosing the Scalability Direction You Need
summary
Argues datastores must pick which axis to optimize because hardware and protocols prevent scaling all ways at once, and names four orthogonal axes: read rate, write rate, data size and data complexity. Gives concrete tradeoffs: replication raises write cost, sharding splits tables across servers and slows cross-shard joins, cluster systems (MySQL Cluster/Galera/Cassandra) limit query features, and MySQL + compression + Booking.com’s open source serial library are used in production. Notes a real surprise: hotel catalog assumptions of ~500,000 properties grow to millions after adding home rentals, forcing rework.
AI-written summary · about
chapters (23)
- 0:00Start
- 0:45Genesis - Developers
- 1:52Small systems
- 2:15Large systems
- 2:50Relating to the real world (business)
- 5:06Relating to the real world (tech)
- 6:20Capacity and load trouble
- 6:30CPU? But what about...
- 7:13Fundamentals
- 10:22Axes of Datastore scalability
- 11:03Data size
- 13:16Schema growth
- 14:41Read query rate
- 16:06Write query rate
- 17:12Notation
- 17:31Application coding • Client-side join and filter, divide effort client and server-side
- 18:27Simplified query support
- 19:5290% Cache Hit Rate
- 22:48Cluster databases (Galera, Cassandra, MySQL Group Replication)
- 23:00MySQL Cluster database
- 24:08Split Schemas
- 24:39Shard data
- 25:52Example: Core transaction data • Requires
related talks
42mContemporary Approaches to Data at Scale
28mThe Next Decade in Data Management
25mData-intensive PostgreSQL: Three ways to scale
46mBig Data. Or Just Too Much Data?
29mBuilding on Strengths, Learning from Differences
40mData warehouse or conventional database: Which is right for you?
52mHow shit works: Databases
40mArchitecting for Data-Intensive Workloads