By default, a compute node can process both streaming jobs and ad-hoc queries (i.e. serving). Alternatively, you can process streaming and serving by different compute nodes respectively, to mitigate resource contention or to isolate streaming or serving failure. This guide introduces how to set up such dedicated compute nodes to decouple streaming and serving.
streaming
role and one compute node with the serving
role.
When launching a compute node, its role can be specified via either the --role
command-line argument, or RW_COMPUTE_NODE_ROLE
environment variable.
You need to restart the node to update the role. A role can be one of:
both
: The default role, if not specified. Indicates that the compute node is available for both streaming and serving.serving
: Indicates that the compute node is read-only and executes batch queries only.streaming
: Indicates that the compute node is only available for streaming.both
mode, which allows a node to handle both batch and streaming queries, is more suited for testing scenarios. While it’s possible to execute batch and streaming queries concurrently, it’s recommended to avoid running resource-intensive batch and streaming queries at the same time.serving
compute node for batch queriesserving
compute node. For detailed instructions, see Node-specific configurations.
Unlike a general-purpose both
compute node, a serving
compute node doesn’t require memory allocation or reservation for shared buffer and operator caches. Instead, it’s more efficient to increase the sizes of the block and meta caches. However, making these caches too large can limit the scope of data that batch queries can execute.
Here’s an example configuration for a serving
compute node with 16GB of memory which you can find in /risingwave/src/config/serving.toml
: