作为迁移作业的一部分，我正在尝试从表中提取数据。
方案如下：
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需要分区键来进行有意义的查询。
我能做些什么来弄清楚我们table上还剩下什么？
2条答案
按热度按时间igsr9ssn1#
根据注解，迁移过程包括从cassandra表中删除操作，但是引擎在实际从磁盘中删除受影响的记录之前会有一个延迟；这个过程由墓碑和
gc_grace_seconds表的属性。这个延迟的原因在这篇博客文章中有充分的解释，对于tl dr，如果默认值仍然存在，cassandra需要在实际删除数据之前至少经过10天（864000秒）的删除执行。对于您的情况，一种方法是：
确保所有节点都处于“正常”状态(
UN)减少表的gc\u grace\u seconds属性，在本例中，它会将其设置为1分钟，而默认值为
alter table.entries的gc\u grace\u seconds=60；
手动压缩表格：
nodetool压缩条目
一旦过程完成，
nodetool tablestats应该是最新的kiz8lqtg2#
为了回答您的第一个问题，我想对gc\u grace\u seconds属性进行更多的说明。
在cassandra中，数据的删除方式与rdbms中不同。cassandra是为高写吞吐量而设计的，它避免了先读后写。所以在cassandra中，删除实际上是一个更新，而更新实际上是插入。写入一个“逻辑删除”标记，表示数据现在（逻辑上）被删除（也称为软删除）。标记为tombstoned的记录必须删除才能收回存储空间。这是通过一个叫做压实的过程来完成的。但请记住，只有在特定的秒数（称为gc\u grace\u seconds）之后，tombstone才有资格进行物理删除/垃圾收集。这是一个非常好的博客，可以详细阅读：https://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html
现在您可能在gc\u grace\u秒之前查看表大小，并且数据仍然存在。
第二个问题是，您希望从表中获取一些示例，而不提供分区键。您可以使用spark分析表内容。spark cassandra连接器允许您创建使用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
我建议您在迁移时不要删除记录。而是先完成迁移和post，然后执行快速验证/验证，以确保所有记录都成功迁移（使用spark buy比较新旧表中的Dataframe可以很容易地完成此使用）。成功验证后截断旧表，因为截断不会创建逻辑删除，因此效率更高。请注意，tombstone的大量no不利于集群健康。