Wikimedia Content API: A Cassandra Use-case #bbuzz
summary
Wikimedia stores roundtripable HTML generated by Parsoid and cached by Restbase as durable blobs in Cassandra to serve low-latency editors and mobile clients. The deployment uses Parsoid -> Restbase -> Cassandra, a 54-node cluster on 18 hosts with six replicas (three per DC), read/write ~5:1, and asynchronous cache priming on every edit. Uses deflate compression and Brotli-like Brley tests (250KB pages compress to ~1.73% with 4MB chunks). It works for availability and throughput but hits pain points: DTCS compaction issues, GC and upgrade/usability headaches.
AI-written summary · about
chapters (8)
- 0:00Introduction and background
- 3:18Visual editor and parsoid
- 9:42Cassandra architecture overview
- 11:26Data model and compression
- 17:04Compaction strategies
- 22:21Garbage collection and node density
- 27:44Cassandra usability and pain points
- 34:05Q&A session
related talks
37mWikimedia Content API: A Cassandra Use-case
16mThe Wikimedia infrastructure
32mCassandra at Yammer #bbuzz
29mCassandra - an introduction
36mStories of Cassandra in Adobe Audience Manager
01h 01mOK S3
35mThe What and Why of Cassandra Datamodelling at Scale
57mCassandra for Metadata Storage: Successes and Failures