70 TB Servers – How and Why We Use Cassandra
summary
Claims running up to ~80 TB per physical server using Cassandra with production customers and it works: achieves dense 5×16 TB instance layouts on Dell/HP chassis, uses a keyspace-per-month scheme to avoid TTLs and keep SSTable counts low, sets replication factor = node count so failed instances clone quickly from system keyspaces and snapshots, uses sstable split by partition plus nodetool import for fast rebuilds, limits per-instance ingest to ~300–350 GB/month to keep repairs (≈3 MB/s effective) within a one-hour off‑peak window.
AI-written summary · about
chapters (14)
- 0:00Cassandra introduction
- 1:02Cassandra for time-series data
- 2:28Availability and scalability
- 3:54Hardware efficiency
- 4:58Business benefits at scale
- 5:41Instance size limits
- 7:06Limits on instance size
- 8:31Keyspace partitioning
- 11:41Replication factor equals nodes
- 13:29Horizontal scaling reasons
- 15:38Cost optimization
- 18:48Replacing instances with more nodes
- 20:33Bulk data import
- 21:57Q&A
related talks
35mReplacing Cassandra: A Digital Transformation for the World’s Largest Digital Identity Network
23mArchitecting for Performance, Scalability and Real-time Data with AWS
31mCassandra for giant 3D tables
52mHow Netflix Provisions Optimal Cloud Deployments of Cassandra
46mCassandra Serving Netflix @ Scale
45m8ms/99th write percentile latency - is it fast? (...)
29mCassandra - an introduction
53mApache Cassandra. Inception - all you need to know