Genevieve LaLonde, Senior Customer Success at SingleStore walks through a deep dive of how partitions and sharding (partitioning) work in SingleStore's distributed relational database.
0:00 - Introduction
0:22 - Distributed Cluster Architecture
0:32 - Directory structure
4:19 - Aggregator and Leaf don't share memory
7:09 - Distributed query processing
7:19 - Table types
13:41 - Reference tables are stored on each node
14:00 - Can't use RAND when inserting into shard keys
17:18 - Use a hint to redistribute partitions when copying data to a new table
18:13 - Show partition for each row
19:37 - Reference tables are not partitioned, they're copied to each node
20:43 - Partitions are stored internally as separate databases
21:31 - Select data from one partition
23:20 - Reference tables are only in the reference database, not in the partitions
24:09 - Reference tables are also in the child aggregators
24:41 - Child aggregator has no regular data, but does have the reference table
25:37 - Can't add data to a reference table on child aggregators
26:51 - Adding data to reference tables replicates to child aggregators nearly instantly
27:30 - Partitioning groups similar data
27:49 - Insert data into a rowstore
33:23 - Show primary key groupings for a row store
35:26 - Add more columns to shard key to split across more partitions and avoid data skew
36:30 - Column stores store columns in different segments
37:23 - Conclusion
#MemSQL is now #SingleStore
