Cassandra 截断性能答案

【问题标题】：Cassandra truncate performanceCassandra 截断性能
【发布时间】：2019-01-07 18:42:05
【问题描述】：

最近有人告诉我，cassandra truncate 性能不佳，而且是反模式。但是，我不知道为什么？

所以，我有两个问题：

所有记录的 upsert 是否比截断更高效？
截断操作会创建墓碑吗？

Cassandra 版本：3.x

【问题讨论】：

哪里提到执行截断是反模式？可以分享那个链接吗？
它，不是链接。我在我的应用程序中使用 truncate，我必须对我的设计进行审查，并且在审查 cmets 它已经到来。我不是评论的一部分，所以，无法提出后续问题，我也发布了同样的问题。

标签： cassandra truncate

【解决方案1】：

来自 cassandra 文档：

注意：TRUNCATE 向所有节点发送 JMX 命令，告诉它们删除保存指定表中数据的 SSTables。如果有任何一个这些节点已关闭或没有响应，命令失败并输出类似以下的消息

因此，运行 truncate 将删除属于您的 cassandra 表的所有 sstable，这将非常快，但必须得到所有节点的确认。根据您的 cassandra.yml，这将在之前对您的数据进行快照：

auto_snapshot（默认值：true）启用或禁用快照是否为在键空间截断或删除表之前获取数据。至防止数据丢失，强烈建议使用默认设置。如果如果设置为 false，则会在截断或丢弃时丢失数据。

创建或修改表时，启用或禁用键缓存（分区键缓存）或该表的行缓存，通过设置缓存参数。其他行和键缓存调整和配置选项在全局（节点）级别设置。 Cassandra 使用这些设置为节点上的每个表自动分配内存基于整体工作负载和特定表使用情况。你也可以全局配置这些缓存的保存期限。

你的问题：

更新插入会慢得多（当您的表中有大量数据时）
truncate 根本不写入 tombstones（相反，它会立即删除 所有节点 上的 all 用于您的 truncated table sstables）

【讨论】：

那些文档已经过时了，不再涉及 jmx 命令。
很高兴知道，当前文档所在的位置是否有新的官方位置？
谢谢，现在浏览作品时搜索似乎被破坏了duh。我错过了。如果有什么我可以做的，我应该检查是否可以花一些时间提供帮助:)
@ChrisLohfink 当您说“不再涉及 JMX 命令”时，这是否也适用于 cassandra 版本 3.x？
是的，它是通过 cql 和消息服务完成的。我想我应该提到它可以通过 jmx 启动（在 storageservicembean 中只是触发与 cql 相同的机制），但它并不对所有节点使用 jmx。也没有人这样做，因为它没有暴露在 nodetool 或任何方便的东西中。即使在 truncate 的0.7 with initial support 中，它也没有向所有节点发出 jmx（使用 msg 服务）并且可以用 thrift 发出，所以我不确定文档的 sn-p 来自哪里