性能相关的常见问答
本文涵盖了与流处理和批处理查询相关的常见问答，以调优性能并提高效率。
如何调整分配给每个流式查询的资源？
使用会话变量streaming_parallelism来调整流式查询的并行度。将该变量设置为特定数字后，会影响同一会话内创建的所有流式查询。
假设有一个具有 3 个 Compute 节点的 RisingWave 集群，每个节点有 8 个 CPU。默认情况下，streaming_parallelism 设为 0，允许流式查询访问最多 24 个 CPU。然而，由于数据读取不足或计算不足等因素，实际情况下可能不会达到 100% 的 CPU 利用率。如果将 streaming_parallelism 更改为 2，则流式查询可以使用的最大 CPU 资源为 3*2=6 个 CPU。
如果有多个流式查询，它们最多会使用 24 个 CPU 怎么办？有两种情况：
如果所有流式查询的实际汇总 CPU 利用率不超过 24 个 CPU，则 CPU 资源足够。每个查询都运行正常。
如果超过了，可以考虑每个流式查询的 CPU 资源份额大约与查询创建时的
streaming_parallelism成比例。例如，一个查询最多可以使用 15 个 CPU，另一个查询最多可以使用 24 个 CPU。这样一来，第一个查询获得24*15/(15+24)~=9个 CPU，而第二个查询获得其余的 15 个 CPU。
开始时不必担心流式查询的配置设置不理想，RisingWave 将支持运行时调整流式查询的并行度，您可以在熟悉查询资源需求后不断调整变量。
如何调整分配给每个批处理查询的资源？
使用会话变量 batch_parallelism，其使用方式与 streaming_parallelism 相同，但适用于批处理查询。
需要注意的是，我们不建议用户频繁通过 RisingWave 对大量输入数据进行即席 OLAP 查询。RisingWave 有能力做到，但它永远无法超过基于列的 OLAP 系统。因此建议将 RisingWave 的输出导入专用的 OLAP 数据库以处理此类查询。
我们建议用户处理那些可以通过索引加速和/或以相对较小的行数作为输入的批处理查询，这些查询通常在几毫秒到几秒钟的范围内完成，并且不需要太多的 CPU 资源。稍后我们将详细讨论创建索引的良好实践。
简而言之，需要更改 batch_parallelism的情况很少。
何时选择部署专用的批处理集群？
默认情况下，所有 Compute 节点既会运行流处理查询和批处理查询。每个 Compute 节点的 CPU 和内存资源都在两种查询之间共享，导致资源竞争，因此很难保证两种查询的性能。
正如前面提到的，适合 RisingWave 处理的批处理查询是具有亚秒级延迟的查询。在生产环境中，由于资源竞争可能导致巨大的延迟波动是不可容忍的。这就是专用批处理集群发挥作用的时候。
此外，用于流处理的 Compute 节点故障不会影响批处理查询的可用性。
配置仅用于流处理或仅用于批处理的 Compute 节点有区别吗？
有区别。默认配置，即不提供自定义的 toml 配置文件（请查看示例），主要针对流处理查询进行了优化。从本质上讲，我们为流处理查询的操作缓存分配了更多的内存，以减少从对象存储中提取数据和状态的次数，并为存储的块缓存和元缓存分配了较少的内存。
当 Compute 节点仅用于批处理服务时，不再需要操作缓存。我们可以增加块缓存和元数据缓存的内存大小，以缓存更多用于批处理查询的数据，从而减少与 S3 的远程 I/O 次数。
我们建议使用此配置。
有关性能优化的任何其他问题，请关注我们的 RisingWave 中文开源社区公众号并加入社群，或加入 Slack 英文社区，与广大用户群体一同参与讨论、寻求帮助、分享经验，我们的工程师将提供相应的解决方案。
