Zty*_*tyx 4 cassandra tombstone cassandra-2.0
Cassandra(版本2)支持哪些类型的墓碑?根据这篇文章它支持(用CQL术语):
我错过了其他类型的墓碑吗?删除特定(CQL)行?是否有任何特殊的墓碑支持删除群集密钥或类似的范围?此信息有助于了解何时规划模式以避免使用过多的逻辑删除.
墓碑是放置在一行中的标记,表示删除.它们可以存在于不同的位置,列或列范围内,也可以存在于整行中.下面的示例显示了正常类型的逻辑删除(此处未涵盖范围类型).
在规划模式时,您可以根据正在执行的查询类型对表进行建模,而不是使用一个表,您可能会发现在多个表中存在重复的数据.这些表经过优化,可以为传入的读写提供服务.下面的链接应该为您提供Cassandra数据建模的一些好背景:
http://www.datastax.com/resources/data-modeling
我的例子:我创建了一个表并插入了一些数据,然后用于nodetool flush生成一些sstables.使用该sstable2json工具可以看到已删除的行,如果它的整行与单列略有不同,但基本上它仍然只是一个标记:
下面是表格及其所有数据:
$ ~/dse-4.5.1/resources/cassandra/bin/sstable2json ./dse-data/results/ts1/results-ts1-jb-1-Data.db
[
{"key": "3136","columns": [["","",1417814256390000], ["col2","26",1417814256390000], ["col3","36",1417814256390000], ["id","id16",1417814256390000]]},
{"key": "3133","columns": [["","",1417814218246000], ["col2","23",1417814218246000], ["col3","33",1417814218246000], ["id","id13",1417814218246000]]},
{"key": "3135","columns": [["","",1417814244766000], ["col2","25",1417814244766000], ["col3","35",1417814244766000], ["id","id15",1417814244766000]]},
{"key": "3134","columns": [["","",1417814230711000], ["col2","24",1417814230711000], ["col3","34",1417814230711000], ["id","id14",1417814230711000]]},
{"key": "3132","columns": [["","",1417814207910000], ["col2","22",1417814207910000], ["col3","32",1417814207910000], ["id","id12",1417814207910000]]},
{"key": "3131","columns": [["","",1417814197094000], ["col2","21",1417814197094000], ["col3","31",1417814197094000], ["id","id11",1417814197094000]]},
{"key": "31","columns": [["","",1417814185270000], ["col2","2",1417814185270000], ["col3","3",1417814185270000], ["id","id1",1417814185270000]]}
]
Run Code Online (Sandbox Code Playgroud)
继承人cqlsh中的第一个删除:
cqlsh:results> delete from ts1 WHERE col1 = '1';
cqlsh:results> delete id from ts1 WHERE col1 = '11';
Run Code Online (Sandbox Code Playgroud)
继冲洗之后产生的sstable:
[datastax@DSE3 ~]$ ~/dse-4.5.1/resources/cassandra/bin/sstable2json ./dse-data/results/ts1/results-ts1-jb-2-Data.db
[
{"key": "3131","columns": [["id","54822130",1417814320400000,"d"]]},
{"key": "31","metadata": {"deletionInfo": {"markedForDeleteAt":1417814302304000,"localDeletionTime":1417814302}},"columns": []}
]
Run Code Online (Sandbox Code Playgroud)
下面是cqlsh中的下一个删除:
cqlsh:results> delete col2 from ts1 WHERE col1 = '12';
Run Code Online (Sandbox Code Playgroud)
继冲洗之后产生的sstable:
[datastax@DSE3 ~]$ ~/dse-4.5.1/resources/cassandra/bin/sstable2json ./dse-data/results/ts1/results-ts1-jb-3-Data.db
[
{"key": "3132","columns": [["col2","5482220b",1417814539434000,"d"]]}
]
Run Code Online (Sandbox Code Playgroud)
当压缩发生时,所有这些sstables组合成一个单独的sstable,然后删除的行仍然存在,但标记为删除,我们可以在运行压缩后再次看到这个(查找d带有时间戳的标志):
[datastax@DSE3 ~]$ ./dse-4.5.1/bin/nodetool compact
[datastax@DSE3 ~]$ ~/dse-4.5.1/resources/cassandra/bin/sstable2json ./dse-data/results/ts1/results-ts1-jb-4-Data.db
[
{"key": "3136","columns": [["","",1417814256390000], ["col2","26",1417814256390000], ["col3","36",1417814256390000], ["id","id16",1417814256390000]]},
{"key": "3133","columns": [["","",1417814218246000], ["col2","23",1417814218246000], ["col3","33",1417814218246000], ["id","id13",1417814218246000]]},
{"key": "3135","columns": [["","",1417814244766000], ["col2","25",1417814244766000], ["col3","35",1417814244766000], ["id","id15",1417814244766000]]},
{"key": "3134","columns": [["","",1417814230711000], ["col2","24",1417814230711000], ["col3","34",1417814230711000], ["id","id14",1417814230711000]]},
{"key": "3132","columns": [["","",1417814207910000], ["col2","5482220b",1417814539434000,"d"], ["col3","32",1417814207910000], ["id","id12",1417814207910000]]},
{"key": "3131","columns": [["","",1417814197094000], ["col2","21",1417814197094000], ["col3","31",1417814197094000], ["id","54822130",1417814320400000,"d"]]},
{"key": "31","metadata": {"deletionInfo": {"markedForDeleteAt":1417814302304000,"localDeletionTime":1417814302}},"columns": []}
]
Run Code Online (Sandbox Code Playgroud)
现在这个表将保持这样,直到我们到达我们gc_grace_seconds然后在下一次压缩时,行实际上会消失,看着我们放下gc_grace_seconds然后运行压缩:
cqlsh> ALTER TABLE results.ts1 WITH gc_grace_seconds=500;
cqlsh> exit
[datastax@DSE3 ~]$ ./dse-4.5.1/bin/nodetool compact results;
[datastax@DSE3 ~]$ ./dse-4.5.1/resources/cassandra/bin/sstable2json ./dse-data/results/ts1/results-ts1-jb-5-Data.db
[
{"key": "3136","columns": [["","",1417814256390000], ["col2","26",1417814256390000], ["col3","36",1417814256390000], ["id","id16",1417814256390000]]},
{"key": "3133","columns": [["","",1417814218246000], ["col2","23",1417814218246000], ["col3","33",1417814218246000], ["id","id13",1417814218246000]]},
{"key": "3135","columns": [["","",1417814244766000], ["col2","25",1417814244766000], ["col3","35",1417814244766000], ["id","id15",1417814244766000]]},
{"key": "3134","columns": [["","",1417814230711000], ["col2","24",1417814230711000], ["col3","34",1417814230711000], ["id","id14",1417814230711000]]},
{"key": "3132","columns": [["","",1417814207910000], ["col3","32",1417814207910000], ["id","id12",1417814207910000]]},
{"key": "3131","columns": [["","",1417814197094000], ["col2","21",1417814197094000], ["col3","31",1417814197094000]]}
]
Run Code Online (Sandbox Code Playgroud)
请注意如何为关键行31已消失,也col1在行与关键3132,并id与关键的行3131
我的表架构为清晰起见:
cqlsh:results> DESCRIBE TABLE ts1 ;
CREATE TABLE ts1 (
col1 text,
col2 text,
col3 text,
id text,
PRIMARY KEY ((col1))
) WITH
bloom_filter_fp_chance=0.010000 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.100000 AND
gc_grace_seconds=864000 AND
index_interval=128 AND
read_repair_chance=0.000000 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
default_time_to_live=0 AND
speculative_retry='99.0PERCENTILE' AND
memtable_flush_period_in_ms=0 AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'LZ4Compressor'};
Run Code Online (Sandbox Code Playgroud)
作为脚注,sstable2json输出中的墓碑标记如下:
e - 过期的TTL
d - 删除值(墓碑)
t - 删除的值范围(范围墓碑)
| 归档时间: |
|
| 查看次数: |
1283 次 |
| 最近记录: |