Кассандра надгробия пересечения порога
В логах я вижу порог предупреждения о надгробии.
Read 411 live rows and 1644 tombstone cells for query SELECT * FROM ks.tbl WHERE key = XYZ LIMIT 5000 (see tombstone_warn_threshold)
Это Cassandra 3.11.3, я вижу, что есть 2 sstables для этой таблицы, и раздел XYZ существует только в одном файле. Теперь я сбросил этот sstable в json, используя sstabledump. Я извлек данные только этого раздела и вижу, что в нем всего 411 строк. И все они являются активными / живыми записями, так что я не понимаю, откуда эти надгробия?
В этой таблице есть столбцы коллекции, и есть надгробия для ячеек для столбцов коллекции, когда они были вставлены. Считаются ли надгробные камни в виде ячеек надгробий в отображаемом предупреждении?
Сделал небольшой тест, чтобы увидеть, считаются ли надгробные камни как надгробия, и это не так. Интересно, откуда взялись эти надгробия в моем запросе?
CREATE TABLE tbl (
col1 text,
col2 text,
c1 int,
col3 map<text, text>,
PRIMARY KEY (col1, col2)
) WITH CLUSTERING ORDER BY (col2 ASC)
cassandra@cqlsh:dev_test> insert into tbl (col1 , col2 , c1, col3 ) values('3','3',3,{'key':'value'});
cassandra@cqlsh:dev_test> select * from tbl where col1 = '3';
col1 | col2 | c1 | col3
----------------+----------+----+------------------
3 | 3 | 3 | {'key': 'value'}
(1 rows)
Tracing session: 4c2a1894-3151-11e9-838d-29ed5fcf59ee
activity | timestamp | source | source_elapsed | client
------------------------------------------------------------------------------------------+----------------------------+---------------+----------------+-----------
Execute CQL3 query | 2019-02-15 18:41:25.145000 | 10.216.1.1 | 0 | 127.0.0.1
Parsing select * from tbl where col1 = '3'; [CoreThread-3] | 2019-02-15 18:41:25.145000 | 10.216.1.1 | 177 | 127.0.0.1
Preparing statement [CoreThread-3] | 2019-02-15 18:41:25.145001 | 10.216.1.1 | 295 | 127.0.0.1
Reading data from [/10.216.1.1] [CoreThread-3] | 2019-02-15 18:41:25.146000 | 10.216.1.1 | 491 | 127.0.0.1
Executing single-partition query on tbl [CoreThread-2] | 2019-02-15 18:41:25.146000 | 10.216.1.1 | 770 | 127.0.0.1
Acquiring sstable references [CoreThread-2] | 2019-02-15 18:41:25.146000 | 10.216.1.1 | 897 | 127.0.0.1
Skipped 0/1 non-slice-intersecting sstables, included 0 due to tombstones [CoreThread-2] | 2019-02-15 18:41:25.146000 | 10.216.1.1 | 1096 | 127.0.0.1
Merged data from memtables and 1 sstables [CoreThread-2] | 2019-02-15 18:41:25.146000 | 10.216.1.1 | 1235 | 127.0.0.1
Read 1 live rows and 0 tombstone cells [CoreThread-2] | 2019-02-15 18:41:25.146000 | 10.216.1.1 | 1317 | 127.0.0.1
Request complete | 2019-02-15 18:41:25.146529 | 10.216.1.1 | 1529 | 127.0.0.1
[root@localhost tbl-8aaa6bc1315011e991e523330936276b]# sstabledump aa-1-bti-Data.db
[
{
"partition" : {
"key" : [ "3" ],
"position" : 0
},
"rows" : [
{
"type" : "row",
"position" : 41,
"clustering" : [ "3" ],
"liveness_info" : { "tstamp" : "2019-02-15T18:36:16.838103Z" },
"cells" : [
{ "name" : "c1", "value" : 3 },
{ "name" : "col3", "deletion_info" : { "marked_deleted" : "2019-02-15T18:36:16.838102Z", "local_delete_time" : "2019-02-15T18:36:17Z" } },
{ "name" : "col3", "path" : [ "key" ], "value" : "value" }
]
}
]
}```
1 ответ
Если вы вставляете данные коллекции (карта / список / набор) с тем же первичным ключом, Cassandra не знает, существуют ли предыдущие данные или нет, и просто вставляет надгробную плиту, чтобы предотвратить случайное слияние с предыдущей версией. То же самое происходит, если вы обновляете полную коллекцию вместо операции обновления в коллекции. Более подробную информацию вы можете найти в следующих сообщениях в блоге ( 1, 2).
Если вам не нужно выполнять частичное обновление коллекций, то всегда лучше использовать замороженные коллекции:
- если вы обновите / замените их, надгробия не будут созданы для них
- они более эффективно сохраняются на диске и читаются с него.