Cassandra - 删除不起作用

Question

有时；当我执行删除时；它不起作用。

我的配置：[cqlsh 5.0.1 |卡桑德拉 3.0.3 | CQL 规范 3.4.0 |原生协议 v4]

cqlsh:my_db> SELECT * FROM conversations  WHERE user_id=120 AND conversation_id=2 AND peer_type=1;

user_id | conversation_id | peer_type | message_map
---------+-----------------+-----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 120 |               2 |         1 | {0: {real_id: 68438, date: 1455453523, sent: True}, 1: {real_id: 68437, date: 1455453520, sent: True}, 2: {real_id: 68436, date: 1455453517, sent: True}, 3: {real_id: 68435, date: 1455453501, sent: True}, 4: {real_id: 68434, date: 1455453500, sent: True}, 5: {real_id: 68433, date: 1455453499, sent: True}, 6: {real_id: 68432, date: 1455453498, sent: True}, 7: {real_id: 68431, date: 1455453494, sent: True}, 8: {real_id: 68430, date: 1455453480, sent: True}}

(1 rows)
cqlsh:my_db> DELETE message_map FROM conversations WHERE user_id=120 AND conversation_id=2 AND peer_type=1;
cqlsh:my_db> SELECT * FROM conversations  WHERE user_id=120 AND conversation_id=2 AND peer_type=1;

user_id | conversation_id | peer_type | message_map
---------+-----------------+-----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 120 |               2 |         1 | {0: {real_id: 68438, date: 1455453523, sent: True}, 1: {real_id: 68437, date: 1455453520, sent: True}, 2: {real_id: 68436, date: 1455453517, sent: True}, 3: {real_id: 68435, date: 1455453501, sent: True}, 4: {real_id: 68434, date: 1455453500, sent: True}, 5: {real_id: 68433, date: 1455453499, sent: True}, 6: {real_id: 68432, date: 1455453498, sent: True}, 7: {real_id: 68431, date: 1455453494, sent: True}, 8: {real_id: 68430, date: 1455453480, sent: True}}

(1 rows)

CQLSH 在 DELETE 指令上没有返回任何错误，但就像没有考虑到它一样。

你知道为什么吗？

注意：这是我的表定义：

CREATE TABLE be_telegram.conversations (
user_id bigint,
conversation_id int,
peer_type int,
message_map map<int, frozen<message>>,
PRIMARY KEY (user_id, conversation_id, peer_type)
) WITH CLUSTERING ORDER BY (conversation_id ASC, peer_type ASC)
AND 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', 'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
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 = '99PERCENTILE';

Answer 1

DELETE 语句从表中的一或多行中删除一或多列，如果未指定列，则删除整行。 Cassandra 在同一个 partition key 中以原子方式独立应用选择。

当一列被删除时，它不会立即从磁盘中删除。删除的列标有tombstone，然后在配置的宽限期到期后删除。可选的timestamp 定义了新的tombstone 记录。

关于 Cassandra 中的删除

Cassandra 删除数据的方式与关系数据库删除数据的方式不同。关系数据库可能会花时间扫描数据以查找过期数据并将其丢弃，或者管理员可能必须按月对过期数据进行分区，以便更快地清除它。 Cassandra 列中的数据可以有一个可选的过期日期，称为 TTL（生存时间）。

要记住的有关已删除数据的事实是：

1. Cassandra 不会立即删除标记为删除的数据 磁盘。删除发生在压缩期间。
2. 如果您使用sized-tiered 或date-tiered 压缩策略，您 可以通过manually starting the compaction process 立即删除数据。在这样做之前，请了解记录在案的缺点 过程。
3. 如果不运行node repair，删除的列可能会重新出现 例行公事。

为什么删除的数据会重新出现

用墓碑标记数据会通知 Cassandra 重试发送 对删除时已关闭的副本的删除请求。如果 副本在宽限期内恢复，它 最终收到删除请求。但是，如果一个节点关闭 长于宽限期，节点可能会错过删除，因为 墓碑在 gc_grace_seconds 后消失。卡桑德拉总是尝试 当节点再次恢复时重播错过的更新。之后 失败，最佳实践是在恢复节点时跨所有副本运行节点修复到repair inconsistencies 进入集群。如果节点没有回来 gc_grace,_seconds，删除节点，擦除它，然后再次引导它。

在您的情况下，compaction 是 sized-tiered。所以请尝试压缩过程。

压缩

定期压缩对于健康的 Cassandra 数据库至关重要 因为 Cassandra 没有就地插入/更新。作为插入/更新 发生，而不是覆盖行，Cassandra 写一个新的 在另一个中插入或更新数据的时间戳版本 SSTable。 Cassandra 使用以下方法管理磁盘上 SSTables 的累积 压实。

Cassandra 也不会就地删除，因为 SSTable 是 不可变的。相反，Cassandra 使用 墓碑。墓碑存在的配置时间段定义为 表上设置的gc_grace_seconds 值。在压实过程中，有 是磁盘空间使用和磁盘 I/O 的临时峰值，因为旧的 和新的 SSTables 并存。此图描述了压缩 进程：

Compaction通过分区键合并每个SSTable数据中的数据， 根据时间戳选择最新的数据进行存储。 Cassandra 可以高效地合并数据，无需随机 IO，因为 行按每个 SSTable 中的分区键排序。驱逐后 墓碑和删除已删除的数据、列和行， 压缩过程将 SSTables 合并到一个文件中。老人 任何挂起的读取完成后，SSTable 文件就会被删除 文件。旧 SSTables 占用的磁盘空间可用于 重复使用。

对 SSTables 的数据输入进行排序以防止 SSTable 期间的随机 I/O 合并。压缩后，Cassandra 使用新的合并 SSTable 而不是多个旧的 SSTable，满足读取请求 比压实之前更有效。旧的 SSTable 文件是 任何挂起的读取使用文件完成后立即删除。磁盘 旧 SSTables 占用的空间可供重用。

所以试试这个

nodetool <options> repair

options are:
( -h | --host ) <host name> | <ip address>
( -p | --port ) <port number>
( -pw | --password ) <password >
( -u | --username ) <user name>
-- Separates an option and argument that could be mistaken for a option.
keyspace is the name of a keyspace.
table is one or more table names, separated by a space.

此命令在使用 SizeTieredCompactionStrategy 或 DateTieredCompactionStrategy 的表上启动压缩过程。您可以指定用于压缩的键空间。如果不指定keyspace，nodetool 命令使用current keyspace。您可以为compaction 指定一个或多个表。如果您不指定表，则会压缩键空间中的所有表。这称为主要压缩。如果您确实指定了一个表，则会对指定的表进行压缩。这称为次要压缩。主要压缩将所有现有的 SSTable 合并到一个 SSTable 中。在压缩期间，由于新旧 SSTable 共存，磁盘空间使用和磁盘 I/O 会出现暂时的峰值。重大压缩可能会导致大量磁盘 I/O。