Cassandra 表墓碑不是 0答案

【问题标题】：Cassandra table tombstones is not 0Cassandra 表墓碑不是 0
【发布时间】：2017-02-09 08:00:46
【问题描述】：

我对 cassandra 有疑问：

如果我执行 nodetool -h 10.169.20.8 cfstats name.name -H

我得到的结果和统计数据是这样的：

    Read Count: 0
    Read Latency: NaN ms.
    Write Count: 739812
    Write Latency: 0.038670616318740435 ms.
    Pending Flushes: 0
        Table: name
        SSTable count: 10
        Space used (live): 1.48 GB
        Space used (total): 1.48 GB
        Space used by snapshots (total): 0 bytes
        Off heap memory used (total): 3.04 MB
        SSTable Compression Ratio: 0.5047407001982581
        Number of keys (estimate): 701190
        Memtable cell count: 22562
        Memtable data size: 14.12 MB
        Memtable off heap memory used: 0 bytes
        Memtable switch count: 7
        Local read count: 0
        Local read latency: NaN ms
        Local write count: 739812
        Local write latency: 0.043 ms
        Pending flushes: 0
        Bloom filter false positives: 0
        Bloom filter false ratio: 0.00000
        Bloom filter space used: 2.39 MB
        Bloom filter off heap memory used: 2.39 MB
        Index summary off heap memory used: 302.03 KB
        Compression metadata off heap memory used: 366.3 KB
        Compacted partition minimum bytes: 87 bytes
        Compacted partition maximum bytes: 3.22 MB
        Compacted partition mean bytes: 2.99 KB
        Average live cells per slice (last five minutes): 1101.2357892212697
        Maximum live cells per slice (last five minutes): 1109
        Average tombstones per slice (last five minutes): 271.6848030693603
        Maximum tombstones per slice (last five minutes): 1109
        Dropped Mutations: 0 bytes

为什么墓碑统计不为 0？我们这里只写入Cassandra，没有人删除记录。我们不使用 TTL，它们设置为默认设置。

第二个问题（可能与问题有关）——表格的行数随机变化，我们不明白是怎么回事。

【问题讨论】：

如果没有您的代码或架构，这是一个非常难以弄清楚的问题。很多人最终会使用集合来做事，如果您进行覆盖，这些集合会隐式创建墓碑。这只是一个猜测

标签： cassandra datastax datastax-enterprise spark-cassandra-connector

【解决方案1】：

我不确定是否有办法解释墓碑 - 如果您不进行任何删除操作。

我可以为您提供两种方法来尝试和分析 - 也许这将有助于更好地了解正在发生的事情以及如何发生。

有一个名为 sstable2json 的工具 - 它允许获取 sstable 并将其转储到 json -

例如对于以下架构

cqlsh> describe schema;

CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}  AND durable_writes = true;

CREATE TABLE test.t1 (
    key text PRIMARY KEY,
    value text
) WITH bloom_filter_fp_chance = 0.01
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99.0PERCENTILE';

在具有完整分区的墓碑的 sstable 文件上运行 sstable2json 可提供以下内容

[
{"key": "key",
 "metadata": {"deletionInfo": {"markedForDeleteAt":1475270192779047,"localDeletionTime":1475270192}},
 "cells": []}
]

在这种情况下，markjer 用于使用“key”的分区

您可以使用的另一种方法（鉴于 tombstone 计数正在增加）是使用 tcpdump，然后使用wireshark 对其进行分析。来自 ScyllaDB 的 Benoit Canet 为 wireshark 贡献了一个支持 CQL 的解析器，该解析器现在处于最新的稳定版本 2.2.0 (https://www.wireshark.org/docs/relnotes/wireshark-2.2.0.html)

请注意，cql 删除实际上可以在两种类型 QUERY 和 PREPARED 中找到（如果删除是使用准备好的语句完成的）。

如果它们是通过准备好的语句完成的，您可能需要断开 CQL 连接以确保捕获具有准备好的语句的特定数据包。

这是一个来自 wireshark 的示例，从上面捕获删除语句

【讨论】：

【解决方案2】：

注意：有时可以在准备好的语句中使用空值绑定来创建墓碑 - http://thelastpickle.com/blog/2016/09/15/Null-bindings-on-prepared-statements-and-undesired-tombstone-creation.html

【讨论】：

【解决方案3】：

在列中写入值与删除相同，并导致墓碑。 Wait... Say What.

【讨论】：

【解决方案4】：

我知道这个问题可以追溯到几年前，但如果有人对新的 cassandra 3+ 版本有同样的问题并想删除已删除的数据，他/她可以运行nodetool garbagecollect

https://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/tools/nodetool/toolsGarbageCollect.html

【讨论】：

在压缩过程中会自动删除已删除的数据。垃圾收集应仅在特定情况下使用