锡拉阅读路径和Cassandra阅读路径有什么区别？当我强调Cassandra和锡拉然后锡拉读取性能差5倍Cassandra使用16核和正常的硬盘驱动器。我希望与使用普通硬盘的cassandra相比，scylla的读取性能更好，因为我的公司不提供ssd。有没有人能确认一下，使用普通硬盘有没有可能获得更好的读取性能？如果是，锡拉需要什么样的配置？。请引导我！
vyu0f0g11#
这两个数据库都使用lsm树，但是scylla在上面有每个核心的线程架构，另外我们使用o\u direct，而c*使用页缓存。“锡拉”还有一个复杂的io调度程序，确保不会使磁盘过载，因此“锡拉”安装程序会自动运行一个基准来进行调整。在io.conf中检查它的输出。有更多的事情要审查，最好把你的数据发送到邮件列表。一般来说，在这种情况下，scylla的性能也会更好，但在这两种情况下，您的磁盘可能都是瓶颈。
jyztefdp2#
其他一些回答集中在写性能上，但这不是你要问的-你问的是读。在cassandra和scylla中，hdd上的未缓存读取性能肯定很差，因为从磁盘上读取每一次都需要在hdd上进行多次寻道，即使是最好的hdd每秒也不能完成200次以上的寻道。即使使用其中几个磁盘的raid，您也很少能够每秒执行超过1000个请求。由于现代的多核处理器每秒的cpu工作量可以超过1000个请求，在scylla和cassandra两种情况下，您可能会看到空闲的cpu。因此，scylla的主要优势，即每次请求使用更少的cpu，甚至在磁盘成为性能瓶颈时都无关紧要。在这种情况下，我希望scylla和cassandra的性能（我假设您在谈论性能时正在测量吞吐量？）应该大致相同。尽管如此，如果您看到cassandra的吞吐量比scylla更好，那么除了其他响应中提出的一般客户端错误配置问题外，还有几个细节可以解释原因：如果您的数据量很小，可以放在内存中，那么cassandra的缓存策略更适合您的工作负载。cassandra使用操作系统的页面缓存，它读取整个磁盘页面，可以在一次读取中缓存多个项目，以及多个索引项。而“锡拉”的工作方式则不同，它有一个只缓存特定数据的行缓存。scylla的缓存对于不适合内存的大量数据来说更好，但是当数据可以适合内存时就更糟糕了，直到整个数据集都被缓存了（缓存完之后，它又变得非常高效）。在HDD上，压缩的细节对于读取性能非常重要—如果在一个设置中有更多的SSD表要读取，则会增加读取次数并降低性能。这可能会根据压缩配置而改变，甚至是随机的（取决于上次运行压缩的时间）。您可以通过在两个系统上执行主要压缩（“nodetool compact”），然后检查读取性能，来检查这是否解释了性能问题。您可以将压缩策略切换到lcs，以确保随机存取读取性能更好，但要付出更多写入工作的代价（在hdd上，这可能是一个值得的折衷方案）。如果您是在测量扫描性能（读取整个表）而不是读取单个行，那么其他问题就会变得相关：正如您可能听说的，scylla将每个节点细分为多个碎片（每个碎片都是一个cpu）。这对于cpu受限的工作来说是非常好的，但是对于扫描不是很大的表来说可能更糟，因为每个sstable现在都变小了，在需要再次查找之前可以读取的连续数据量也变少了。我不知道这些差异中的哪一个——或者其他什么——导致您的用例在scylla中的性能较低，但请记住，无论您修复什么，您的性能在HDD中总是会很差。使用SDD，我们在过去测量了单个节点上每秒超过一百万个随机访问读取请求。硬盘无法接近。如果您真的需要最佳的性能或每一美元的性能，SDD确实是一个不错的选择。
cygmwpex3#
有各种各样的原因为什么你没有从你的锡拉星团中得到最大的利益。来自客户端/加载程序的并发连接数不够高，或者您没有使用足够的加载程序。在这种情况下，一些shard将完成所有的工作，而另一些shard则大部分处于空闲状态。你想保持你的平行度高。“锡拉”类的每个碎片至少有2个连接（你可以在中看到碎片的数量） /etc/scylla.d/cpuset.conf )你的数据集有多大？你是在读大量的分区还是仅仅读几个分区？您可能遇到了热分区情况我强烈建议您阅读以下文件，以提供更多见解：https://www.scylladb.com/2019/03/27/best-practices-for-scylla-applications/https://docs.scylladb.com/operating-scylla/benchmarking-scylla/
/etc/scylla.d/cpuset.conf
brqmpdu14#
@sateesh，我想对@tomersan的回答补充一点，即cassandra和scylladb都使用相同的磁盘存储体系结构（lsm）。这意味着它们具有相对相同的磁盘访问模式，因为算法基本相同。lsm树的构建是基于这样一个思想的，即不需要进行即时就地更新。它由不可变的数据桶组成，这些数据桶是磁盘上连续的大数据块。这意味着更少的随机io，更多的顺序io，而hdd在这些io中工作得很好（不包括现代数据库实现所利用的并行性）。以上所有这些都意味着，您看到的差异并不是由这些数据库使用磁盘的方式的差异引起的。它必须与配置差异和下面发生的事情有关。也许锡拉达试图利用更多的平行性或更积极地进行压缩。视情况而定。为了能够说具体的事情，请分享你的测试，环境和配置。
sqxo8psd5#
总而言之，我想说的是，scylladb和cassandra具有相同的读/写路径memtable、commitlog和sstable。然而，实现方式却大不相同：-cassandra依赖操作系统实现低层io和网络（大多数dbms都是这样做的）-scylladb依赖自己的库（seastar）在低层独立于操作系统页面缓存等处理io和网络。这就是为什么它们可以提供诸如在同一集群内进行工作负载调度这样的功能，这将非常难以实现在Cassandra实施。
5条答案
按热度按时间vyu0f0g11#
这两个数据库都使用lsm树，但是scylla在上面有每个核心的线程架构，另外我们使用o\u direct，而c*使用页缓存。“锡拉”还有一个复杂的io调度程序，确保不会使磁盘过载，因此“锡拉”安装程序会自动运行一个基准来进行调整。在io.conf中检查它的输出。
有更多的事情要审查，最好把你的数据发送到邮件列表。一般来说，在这种情况下，scylla的性能也会更好，但在这两种情况下，您的磁盘可能都是瓶颈。
jyztefdp2#
其他一些回答集中在写性能上，但这不是你要问的-你问的是读。
在cassandra和scylla中，hdd上的未缓存读取性能肯定很差，因为从磁盘上读取每一次都需要在hdd上进行多次寻道，即使是最好的hdd每秒也不能完成200次以上的寻道。即使使用其中几个磁盘的raid，您也很少能够每秒执行超过1000个请求。由于现代的多核处理器每秒的cpu工作量可以超过1000个请求，在scylla和cassandra两种情况下，您可能会看到空闲的cpu。因此，scylla的主要优势，即每次请求使用更少的cpu，甚至在磁盘成为性能瓶颈时都无关紧要。在这种情况下，我希望scylla和cassandra的性能（我假设您在谈论性能时正在测量吞吐量？）应该大致相同。
尽管如此，如果您看到cassandra的吞吐量比scylla更好，那么除了其他响应中提出的一般客户端错误配置问题外，还有几个细节可以解释原因：
如果您的数据量很小，可以放在内存中，那么cassandra的缓存策略更适合您的工作负载。cassandra使用操作系统的页面缓存，它读取整个磁盘页面，可以在一次读取中缓存多个项目，以及多个索引项。而“锡拉”的工作方式则不同，它有一个只缓存特定数据的行缓存。scylla的缓存对于不适合内存的大量数据来说更好，但是当数据可以适合内存时就更糟糕了，直到整个数据集都被缓存了（缓存完之后，它又变得非常高效）。
在HDD上，压缩的细节对于读取性能非常重要—如果在一个设置中有更多的SSD表要读取，则会增加读取次数并降低性能。这可能会根据压缩配置而改变，甚至是随机的（取决于上次运行压缩的时间）。您可以通过在两个系统上执行主要压缩（“nodetool compact”），然后检查读取性能，来检查这是否解释了性能问题。您可以将压缩策略切换到lcs，以确保随机存取读取性能更好，但要付出更多写入工作的代价（在hdd上，这可能是一个值得的折衷方案）。
如果您是在测量扫描性能（读取整个表）而不是读取单个行，那么其他问题就会变得相关：正如您可能听说的，scylla将每个节点细分为多个碎片（每个碎片都是一个cpu）。这对于cpu受限的工作来说是非常好的，但是对于扫描不是很大的表来说可能更糟，因为每个sstable现在都变小了，在需要再次查找之前可以读取的连续数据量也变少了。
我不知道这些差异中的哪一个——或者其他什么——导致您的用例在scylla中的性能较低，但请记住，无论您修复什么，您的性能在HDD中总是会很差。使用SDD，我们在过去测量了单个节点上每秒超过一百万个随机访问读取请求。硬盘无法接近。如果您真的需要最佳的性能或每一美元的性能，SDD确实是一个不错的选择。
cygmwpex3#
有各种各样的原因为什么你没有从你的锡拉星团中得到最大的利益。
来自客户端/加载程序的并发连接数不够高，或者您没有使用足够的加载程序。在这种情况下，一些shard将完成所有的工作，而另一些shard则大部分处于空闲状态。你想保持你的平行度高。
“锡拉”类的每个碎片至少有2个连接（你可以在中看到碎片的数量）
/etc/scylla.d/cpuset.conf)你的数据集有多大？你是在读大量的分区还是仅仅读几个分区？您可能遇到了热分区情况
我强烈建议您阅读以下文件，以提供更多见解：
https://www.scylladb.com/2019/03/27/best-practices-for-scylla-applications/
https://docs.scylladb.com/operating-scylla/benchmarking-scylla/
brqmpdu14#
@sateesh，我想对@tomersan的回答补充一点，即cassandra和scylladb都使用相同的磁盘存储体系结构（lsm）。这意味着它们具有相对相同的磁盘访问模式，因为算法基本相同。lsm树的构建是基于这样一个思想的，即不需要进行即时就地更新。它由不可变的数据桶组成，这些数据桶是磁盘上连续的大数据块。这意味着更少的随机io，更多的顺序io，而hdd在这些io中工作得很好（不包括现代数据库实现所利用的并行性）。
以上所有这些都意味着，您看到的差异并不是由这些数据库使用磁盘的方式的差异引起的。它必须与配置差异和下面发生的事情有关。也许锡拉达试图利用更多的平行性或更积极地进行压缩。视情况而定。
为了能够说具体的事情，请分享你的测试，环境和配置。
sqxo8psd5#
总而言之，我想说的是，scylladb和cassandra具有相同的读/写路径memtable、commitlog和sstable。
然而，实现方式却大不相同：-cassandra依赖操作系统实现低层io和网络（大多数dbms都是这样做的）-scylladb依赖自己的库（seastar）在低层独立于操作系统页面缓存等处理io和网络。这就是为什么它们可以提供诸如在同一集群内进行工作负载调度这样的功能，这将非常难以实现在Cassandra实施。