使用datastax enterprise，您应该能够启用数据库审核功能。实际上，通过配置 CassandraAuditWriter ，所有活动都会写入 audit_log 中的表 dse_audit 键空间。
数据由这个主键组织：（（日期、节点、日分区）、事件\时间）；有这样的列 username , table_name , keyspace_name , operation 和其他人。
查看datastax文档中的配置和查询选项。
至于（开源）apachecassandra，我们使用ericsson的cassandra审计插件来实现这个功能。通过添加到项目的jar中，并对 cassandra.yaml 文件，您可以查看 audit.log 对于以下记录：

15:42:41.655 - client:'10.0.110.1'|user:'flynn'|status:'ATTEMPT'|operation:'DELETE FROM ecks.ectbl WHERE partk = ?'

我想我应该怎么做是使用“nodetool tablehistograms”来证明表有很大的分区。然后我会转到表目录，对一些数据文件运行“sstablemetadata”，找到那些显示一些大分区大小的文件。
一旦找到分区更大的sstable，可以使用的一个技巧是：

sstabledump <sstable> | grep  -n "\"key\" :"

这样做就是每次按键切换时显示行号，行间的间距越大，行数越多。
举个例子：

sstabledump aa-483-bti-Data.db | grep  -n "\"key\" :"
4:      "key" : [ "PROCESSING" ],
65605:      "key" : [ "PENDING" ],
8552007:      "key" : [ "COMPLETED" ],

如您所见，挂起和完成之间的差距远远大于处理和挂起（65k行vs.8m行）。所以这告诉我，与挂起分区相比，处理分区相对较小。唯一的谜团是完成的有多大，因为没有“结束”线。要获取总行数，请运行：

sstabledump aa-483-bti-Data.db | wc -l
16316029

总行数为16m。所以完成的长度从8米到16米，或者说大约8米的线路。所以完成的分区也很大，大约和挂起的分区一样大。
查看sstablemetadata以查看它是否与输出匹配，我发现它确实匹配：

sstablemetadata aa-483-bti-Data.db
Partition Size:
   Size (bytes)         | Count  (%)  Histogram
   943127 (921.0 kB)    |     1 ( 33) OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
   129557750 (123.6 MB) |     1 ( 33) OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
   155469300 (148.3 MB) |     1 ( 33) OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

我看到两个相对较大的分区和一个较小的分区。答对 了。
也许其中一些可以帮助你找到大分区的底部。