Scylla 读取路径和 Cassandra 读取路径有什么区别？当我强调 Cassandra 和 Scylla 时，Scylla 的读取性能比使用 16 核和普通 HDD 的 Cassandra 差 5 倍。
与使用普通 HDD 的 Cassandra 相比，我希望 Scylla 的读取性能更好，因为我的公司不提供 SSD。
有人可以确认一下，使用普通硬盘是否可以实现更好的读取性能？
如果是，需要对 scylla 配置进行哪些更改？请指导我！
【问题讨论】：
您没有充分利用 Scylla 集群的原因可能有多种。
来自您的客户端/加载器的并发连接数不够高，或者您没有使用足够数量的加载器。在这种情况下，一些分片将完成所有工作，而其他分片将大部分处于空闲状态。您希望保持较高的并行度。
Scylla likes 每个分片至少有 2 个连接（您可以在 /etc/scylla.d/cpuset.conf 中查看分片数）
您的数据集的大小是多少？您是在读取大量分区还是仅读取几个分区？您可能遇到热分区情况
我强烈建议您阅读以下文档，这些文档将为您提供更多见解：
【讨论】：
@Sateesh，我想补充一下@TomerSan 的答案，即 Cassandra 和 ScyllaDB 都使用相同的磁盘存储架构 (LSM)。这意味着它们具有相对相同的磁盘访问模式，因为算法基本相同。 LSM 树的构建考虑了不需要进行即时就地更新的想法。它由不可变的数据桶组成，这些数据桶是磁盘上的大量连续数据。这意味着更少的随机 IO，更多的顺序 IO，HDD 工作得很好（不包括现代数据库实现使用的并行性）。
以上所有意味着您看到的差异并不是由这些数据库使用磁盘的方式差异引起的。它必须与配置差异以及下面发生的事情有关。也许 ScyllaDB 试图利用更多的并行性或更积极地进行压缩。视情况而定。
为了能够说出具体的内容，请分享您的测试、环境和配置。
【讨论】：
两个数据库都使用 LSM 树，但 Scylla 在顶部具有每核线程架构，而且我们使用 O_Direct 而 C* 使用页面缓存。 Scylla 还具有复杂的 IO 调度程序，可确保不会使磁盘过载，因此 scylla_setup 会自动运行基准测试以进行调整。在 io.conf 中检查它的输出。
要查看的内容要多得多，最好将您的数据发送到邮件列表。一般来说，Scylla 在这种情况下也应该表现得更好，但在这两种情况下，您的磁盘可能都是瓶颈。
【讨论】：
作为总结，我会说 Scylladb 和 cassandra 具有相同的读/写路径 内存表、提交日志、sstable。
但是实现方式有很大不同： - cassandra 依赖操作系统来实现低级 IO 和网络（大多数 DBMS 都这样做） - scylladb 依靠自己的 lib (seastar) 独立于操作系统页面缓存等处理低级别的 IO 和网络。这就是为什么它们可以提供在同一集群中很难在 cassandra 中实现的工作负载调度等功能.
【讨论】：
其他一些回复侧重于写入性能，但这不是您所问的 - 您问的是读取。
在 Cassandra 和 Scylla 中，HDD 上的未缓存读取性能肯定很差，因为从磁盘读取每次都需要在 HDD 上进行 几次 寻道，即使是最好的 HDD 也只能做到以下几点：每秒搜索 200 次。即使使用其中几个磁盘的 RAID，您也很少能够执行超过每秒 1000 个请求的操作。由于现代多核可以处理比每秒 1000 个请求多几个数量级的 CPU 工作，因此在 Scylla 和 Cassandra 的情况下，您可能会看到空闲 CPU。因此，当磁盘成为性能瓶颈时，Scylla 的主要优势（每个请求使用更少的 CPU）甚至都无关紧要。在这种情况下，我希望 Scylla 和 Cassandra 的性能（我假设您在谈论性能时正在测量吞吐量？）应该大致相同。
如果您仍然看到 Cassandra 的吞吐量比 Scylla 更好，那么除了其他响应中提出的一般客户端错误配置问题之外，还有几个细节可以解释原因：
如果您的数据少量可以放入内存，Cassandra 的缓存策略更适合您的工作负载。 Cassandra 使用操作系统的页面缓存，它读取整个磁盘页面，并且可以在一次读取中缓存多个项目，以及多个索引条目。虽然 Scylla 的工作方式不同，并且具有行缓存 - 仅缓存读取的特定数据。 Scylla 的缓存对于大量无法放入内存的数据来说效果更好，但当数据可以放入内存时就更糟糕了，直到整个数据集都被缓存（在所有东西都被缓存之后，它再次变得非常高效）。
在 HDD 上，压缩的细节对于读取性能非常重要 - 如果在一个设置中您有更多的 sstable 要读取，它会增加读取次数并降低性能。这可以根据您的压缩配置更改，甚至可以随机更改（取决于上次运行压缩的时间）。您可以通过在两个系统上进行主要压缩（“nodetool compact”）并随后检查读取性能来检查这是否解释了您的性能问题。您可以将压缩策略切换到 LCS，以确保随机访问读取性能更好，但代价是更多的写入工作（在 HDD 上，这可能是一个值得妥协的方案）。
如果您正在测量扫描性能（读取整个表）而不是读取单个行，则其他问题变得相关：您可能听说过，Scylla 将每个节点细分为分片（每个分片是一个 CPU）。这对于 CPU 受限的工作来说非常棒，但对于扫描不是很大的表可能会更糟，因为现在每个 sstable 都更小了，并且在需要再次查找之前可以读取的连续数据量更少。
我不知道这些差异中的哪一个 - 或其他 - 导致您的用例在 Scylla 中的性能较低，但我请记住，无论您修复什么，您的性能总是会很差与硬盘驱动器。过去，我们使用 SDD 测量了单个节点上每秒超过一百万个随机访问读取请求。硬盘驱动器无法接近。如果您真的需要最佳性能或每美元的性能，SDD 确实是要走的路。
【讨论】：