cassandra - 高价值行缓存有什么影响？

Question

最近我浏览了一个关于键缓存和行缓存的教程。谁能帮我提供一些这些缓存会影响的实时示例？如果我们在配置文件中增加这些值会有什么影响？

在使用 desc 表时，我发现了这个

AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'

Answer 1

您主要关心的是应用程序的内存配置文件。

这张图展示了 key cache 是如何优化 readpath 的，它允许我们跳过分区摘要和分区索引，直接进入压缩偏移。至于行缓存，如果你得到了命中，你就有了答案，根本不需要沿着读取路径走。

键缓存- 默认情况下，键缓存是打开的，因为它只保留行的键。键通常相对于行的其余部分更小，因此此缓存可以在耗尽之前保存许多条目。

行缓存- 行缓存保存一整行，当您有一个相当静态的查询模式时很有用。行缓存的论点是，如果您一遍又一遍地读取相同的行，您可以将它们保存在内存中，而不是进入 SSTable（存储介质）级别，从而绕过读取路径上的昂贵查找。在实践中，由于在非最佳用例中使用行缓存而导致内存变慢，这使其成为一个不受欢迎的功能。

那么如果你填满缓存会发生什么？好吧，有一个驱逐策略，但如果你不断地从任一缓存中踢出东西来为新项目腾出空间，那么缓存将不会完全有用，因为与 gc 相关的性能下降会损害整体性能。

拥有非常高的缓存值会怎样？这是有更好选择的地方，稍后会详细介绍。使行缓存变大只会导致 GC 问题，这取决于您正在做什么，通常会导致性能的整体净损失。

我看到使用得比较好的一个想法是在 Cassandra 之上有一个缓存层，例如 Apache Ignite 或 Memcached。您在缓存层中加载热数据以获得快速读取，并使用写入缓存层的应用程序进行写入，然后写入 C* 以实现持久性。这些架构有许多自己的问题，但如果您想缓存数据以降低查询延迟，C* 行缓存并不是完成这项工作的最佳工具。