Seastar is a framework for asynchronous I/O and shared-nothing execution. ScyllaDB uses it to divide work within each node, pinning each shard to a CPU core with dedicated memory and supporting resources. section 1.2.3 section 8.3.2
A Seastar-powered shard can contain:
- A dedicated CPU core, memory, internal task scheduler, TCP/IP stack, and storage APIs. section 8.3.2
- Its own row cache, memtable, and commit log, with shards communicating through shared-memory queues. section 8.3.2
- A limited failure and traffic boundary: a hot partition can degrade one shard without immediately overwhelming the entire node. section 1.2.3 section 8.3.2
Tracing a hot partition
When one data partition receives unusually heavy traffic, Seastar keeps its work associated with the shard handling it. That shard may slow down, while other shards remain less affected; cross-shard operations can still experience delays. section 1.2.3 section 8.3.2
Figure 1.8 ScyllaDB shards data not only within the cluster but also within each instance.
Trace how ScyllaDB distributes data first across the cluster and then across CPU cores within each instance. section 1.2.3
Figure 8.12 Scylla further distributes the dataset by sharding it per CPU core in each node.
Inspect the per-core distribution that gives each ScyllaDB shard dedicated execution and storage components. section 8.3.2
