Data Modeling for Distributed SQL
summary
Explains how YBDB (YugaByte) uses the primary key to determine sharding: choose hash sharding for write distribution and range sharding for range scans, since hash defaults to one tablet per node. Covers sequence cache tuning (default 100 per connection, can increase to 1,000 per tserver to reduce hotspots), tablet sizing costs (~1,000 tablets ≈ 0.4 vCPU) and avoiding unnecessary splits via colocation and split_in, and recommends using the Voyager migration tool with small test clusters, schema analysis, and tuning before full imports.
AI-written summary · about
chapters (13)
- 0:00Welcome
- 1:08Distributed vs traditional SQL
- 2:57Data sharding with primary keys
- 4:44Hash vs range sharding
- 6:543 sharding design points
- 7:16Primary key design methods
- 9:27Secondary indexes in action
- 14:20Table sizing and colocation
- 17:15Best practices for models
- 17:35Voyager migration tool
- 21:07UUID anti-patterns vs sequences
- 24:03Denormalizing data models
- 28:03Summary and Q&A
related talks
27mData Modeling: Master This Critical Step to Adopting a Distributed Database
30mPerformance: Tips & Tricks to Optimize the Speed of Your Mission-Critical Database
02h 27mDistributed SQL Tuning and Optimization in YugabyteDB
01h 27mYugabyteDB YSQL Development
27mIntroduction to YugabyteDB: Design and Architecture
29mEnterprise Scale: How a Distributed Architecture Can Deliver Scale and Resilience
27mIntroduction to YugabyteDB – Design and Architecture
01h 00mParallel Asynchronous Replication b/t YDB Database Instances
