Question

我正在尝试从表中提取数据，作为迁移作业的一部分。

架构如下：

CREATE TABLE IF NOT EXISTS ${keyspace}.entries (
    username text,

    entry_type int,

    entry_id text,

    PRIMARY KEY ((username, entry_type), entry_id)
);

为了查询表，我们需要分区键，即主键的第一部分。因此，如果我们知道username和entry_type，就可以查询该表。

在这种情况下，username可以是任何数字，但是entry_type是0到9范围内的整数。

进行提取时，我们为每个用户名对表进行10次迭代，以确保我们尝试使用entry_type的所有版本。

我们已经找不到用户名列表，因此无法再找到任何条目。但是我们的nodetool tablestats报告说，表中仍然有数据，甚至是千兆字节。因此，我们假设表不为空。

但是我找不到一种检查表的方法来弄清楚表中还剩下什么用户名。如果可以检查它，可以将表中剩余的用户名添加到提取作业中，最终可以耗尽表。但是我不能简单地这样查询表：

SELECT * FROM ${keyspace}.entries LIMIT 1

因为cassandra需要分区键才能进行有意义的查询。

我该怎么办才能找出桌子上剩下的东西？

Answer 1

根据评论，迁移过程包括从Cassandra表中执行DELETE操作，但是在实际从磁盘中删除受影响的记录之前，引擎将有一个延迟；此过程由内部的逻辑删除和表的gc_grace_seconds属性控制。 blog entry中对此延迟的原因进行了详细说明，对于tl dr，如果仍使用默认值，则Cassandra在执行删除操作之前至少需要经过10天（864,000秒）的时间实际删除数据。

对于您的情况，一种处理方法是：

确保您的所有节点都处于“正常”运行状态（“ UN）
减小表的gc_grace_seconds属性，在该示例中，它将设置为1分钟，而默认值为

ALTER TABLE条目，GC_GRACE_SECONDS = 60;
手动压缩表格：

nodetool紧凑条目
该过程完成后，nodetool tablestats应该是最新的

Answer 2

为回答您的第一个问题，我想进一步介绍 gc_grace_seconds 属性。

在Cassandra中，删除数据的方式与在RDBMS中不同。 Cassandra专为实现高写入吞吐量而设计，避免了写入前读取。因此，在Cassandra中，删除实际上是更新，而更新实际上是插入。写入“墓碑” 标记以指示现在（逻辑上）删除了数据（也称为软删除）。必须删除标记为逻辑删除的记录才能收回存储空间。这由称为 Compaction 的过程完成。但是请记住，只有在特定的秒数gc_grace_seconds之后，逻辑删除才有资格进行物理删除/垃圾回收。这是一个非常好的博客，需要更多详细信息：https://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html

现在，您可能正在gc_grace_seconds之前查看表大小，并且数据仍然存在。

关于第二个问题，您想从表中获取一些样本而不提供分区键。您可以使用Spark分析表内容。 Spark Cassandra Connector允许您创建使用Spark分析数据库数据的Java应用程序。您可以按照文章/文档编写一个方便的spark应用程序来分析Cassandra数据。

https://www.instaclustr.com/support/documentation/cassandra-add-ons/apache-spark/using-spark-to-sample-data-from-one-cassandra-cluster-and-write-to-another/

https://docs.datastax.com/en/dse/6.0/dse-dev/datastax_enterprise/spark/sparkJavaApi.html

我建议您在迁移时不要删除记录。而是先完成迁移并发布，然后进行快速验证/验证以确保所有记录都已成功迁移（使用Spark Buy可以比较旧表和新表的数据框，从而轻松完成此操作）。成功验证后，请截断旧表，因为截断不会创建逻辑删除，因此效率更高。请注意，大量的逻辑删除不利于集群健康。

没有分区键的Cassandra查询表

2 个答案: