How Hypertable Powers one of the World's Largest Email Services
summary
Rediffmail moves metadata off its SAN into Hypertable to stop outages caused when over 75% of storage requests are inbox metadata updates; headers and user actions live in Hypertable while bodies remain on the storage appliance, sharded with primary/secondary Hypertable replicas per datacenter and update buffering for offline clusters. A 30-day cache holds recent metadata and bodies, most of the read traffic fits in memory, and Hypertable’s C++ implementation vs HBase Java targets lower memory and latency.
AI-written summary · about
chapters (18)
- 0:00Start
- 1:03High Performance, Open Source Scalable Database
- 2:24How Hypertable Differs from A Relational Database
- 3:28Hypertable Deployments
- 4:14Table: Visual Representation
- 6:13Anatomy of a key
- 8:07Caching
- 8:52Column Family Options
- 11:26User Interface
- 11:47Architectural Overview
- 13:05How it Works
- 14:25Mall Headers
- 16:14single machine
- 17:07Queries
- 18:54Query Latency
- 19:16Machine Activity - Off peak Load
- 20:04Machine Activity - Peak Load
- 20:37Next generation Architecture
related talks
30mBuilding a metadata ecosystem using the Hive Metastore
29mHow to Handle 1 Billion Emails?
48mHyper Speed! When Big Data Blooms
50mApache Hudi : The Data Lake Platform
38mKeynote | Data Warehouse, Data Lakes, What's Next?
36mHow Can HTAP Databases Simplify Your Data Infrastructure?
01h 08mApache Hudi: A Database Layer Over Cloud Storage for Fast Mutations & Queries
29mMulti Tenancy — Apache Hbase