liveBook · Manning

Single-partition query

As explained in ScyllaDB in Action

A single-partition query retrieves data from exactly one ScyllaDB partition identified by a partition key.

A single-partition query retrieves data from exactly one ScyllaDB partition identified by a partition key. Querying this way minimizes the nodes serving a request and reduces database load, making it a basic performance target established during schema design. section 7.2.2 section 7.2.2

Use single-partition queries as a starting point, then check the remaining causes of latency:

  • Limit each request to one partition key to reduce the number of nodes involved. section 7.2.2
  • Remember that a single partition can still be slow when rows are large, the partition contains many rows, or the serving node lacks CPU, disk I/O, or memory. section 7.2.2

Restaurant-review data

A query against a small article_summaries_by_date partition illustrates the preferred shape. A single-partition query can still perform poorly if it reads a very large partition or unusually large review rows. section 7.2.2 section 7.2.2

How ScyllaDB in Action covers it

How deep it goes
Explains the performance rationale and three latency factors but stops short of implementation details.
Examples
Uses article_summaries_by_date partitions and oversized restaurant-review rows to contrast small and slow reads.
What it assumes
Assumes familiarity with partition keys and query-first schema design.
What you can do after
Diagnose slow single-partition reads by checking row size, partition row count, and node resources.
How it connects
Connects partition keys with query-first design, schema design, and query performance.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of ScyllaDB in Action. The section links point to the parts of the book it draws on.