The What and Why of Cassandra Datamodelling at Scale
summary
Verizon migrates legacy DB2 mainframe workloads to Cassandra with a read-first real-time DB2 -> Cassandra replication strategy, using Cassandra timestamps to absorb out-of-order messages and a CDC pipeline back to RDBMS for analytics. The backend ends up with 800+ tables to support ~1,000 APIs, running ~1.7M read TPS and 300+ writes/s. Large partitions are solved with bucket + t-shirt sizing and parallel driver queries; Spark-based reconciliation, tombstone avoidance and compaction tuning keep it stable.
AI-written summary · about
chapters (16)
- 0:00Cassandra migration at Verizon
- 3:54Legacy mainframe migration challenges
- 6:02System of record migration strategy
- 9:15Cassandra modeling myths
- 10:40Telecom use case in Cassandra
- 12:04Large partitions and consistency
- 14:13Customer data distribution sizing
- 18:07Real-time DB2 to Cassandra sync
- 19:54Timestamps for out-of-order updates
- 20:39Reconciling Cassandra inconsistencies
- 22:02Tombstone issues in hot tables
- 24:11Thousands of tables at scale
- 25:58Combining tables for API efficiency
- 26:43CDC pipeline for analytics
- 27:23Migration lessons learned
- 29:48Q&A
related talks
45mMigrating Mission Critical Workloads from Mainframe to Open...
29mCassandra - an introduction
26mBuilding Financial Systems on Eventually Consistent DBs
46mApache Cassandra: 8 years in production
35mReplacing Cassandra: A Digital Transformation for the World’s Largest Digital Identity Network
21mModeling Financial Data In Cassandra To Serve Real Time And Batch Workloads
32mCassandra at Yammer #bbuzz
55mSolving Classical Data Analytic Task by Using Modern Distributed Databases