A CPU core is an independent processing unit inside a CPU. In ScyllaDB, each core can anchor a shard, making the core an important unit for node capacity and on-node data processing. section 9.2.2 section 8.3.2
Each ScyllaDB shard is a miniature part of a node with a dedicated CPU core and memory. Seastar pins asynchronous work to cores and gives each shard its own scheduler, TCP/IP stack, storage APIs, row cache, memtable, and commit log; shared memory queues connect shards. section 8.3.2
CPU cores matter operationally in three ways:
- Node sizing accounts for CPU cores alongside disk space, memory, network bandwidth, and cost; production-level testing supplies the practical validation. section 9.2.2
- On-node sharding distributes work across cores, while a hot partition can overload one shard and affect cross-shard operations. section 8.3.2
- Shard details are mostly invisible during ordinary use but can appear in logs and metrics when diagnosing performance problems. section 8.3.2
Figure 8.12 Scylla further distributes the dataset by sharding it per CPU core in each node.
The figure shows how ScyllaDB distributes a node’s dataset across shards associated with individual CPU cores. section 8.3.2
Figure 9.5 Using smaller nodes in your cluster can be a cost-effective way to meet your throughput goals, as well as increase your cluster’s availability if you were to lose a quorum.
The figure illustrates why smaller nodes can meet throughput goals while improving availability when quorum is lost. section 9.2.2
