Какие типы надгробий поддерживает Кассандра?

Какие типы надгробий поддерживает Cassandra (версия 2)? Согласно этой статье он поддерживает (в терминах CQL):

  • определенный столбец для строки.
  • статические столбцы.
  • все строки для ключа раздела.

Я пропустил другие типы надгробий? Удаление определенной (CQL) строки? Существуют ли специальные надгробия для поддержки удаления диапазонов ключей кластера или аналогичных? Эту информацию полезно знать при планировании схем, чтобы избежать слишком большого количества надгробий.

2 ответа

Надгробная плита - это маркер, помещенный в строку, которая указывает на удаление. Они могут существовать в разных местах, в столбце или диапазоне столбцов или в целом ряду. В приведенном ниже примере показан нормальный тип надгробной плиты (тип диапазона здесь не рассматривается).

При планировании вашей схемы вы моделируете свои таблицы по типам запросов, которые вы делаете, вместо того, чтобы иметь одну таблицу, вы можете обнаружить, что у вас есть данные, дублированные во многих таблицах. Таблицы оптимизированы для обслуживания входящих операций чтения и записи. Ссылка ниже должна дать вам хороший опыт моделирования данных с помощью 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]]}
]

Вот первое удаление в cqlsh:

cqlsh:results> delete from ts1 WHERE col1 = '1';
cqlsh:results> delete id from ts1 WHERE col1 = '11';

Вот получающийся 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": []}
]

Вот следующее удаление в cqlsh:

cqlsh:results> delete col2 from ts1 WHERE col1 = '12';

Вот получающийся 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"]]}
]

Когда происходит сжатие, все эти 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": []}
]

Теперь эта таблица будет оставаться такой, пока мы не достигнем 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]]}
]

Обратите внимание, как строка для ключа 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'};

В качестве сноски маркеры надгробий в sstable2json Вывод следующие:

e - истек TTL

d - удаленное значение (надгробие)

t - удален диапазон значений (диапазон захоронения)

В добавление к ответу @markc, есть также надгробная плита в диапазоне столбцов, которая появляется всякий раз, когда вы используете коллекции. У нас есть set<text> столбец с именем "теги", и всякий раз, когда мы вставляем строку, мы получаем один из них (даже если мы просто устанавливаем его в null, как в этом случае):

["1381316637599609:45787829:tags:_","1381316637599609:45787829:tags:!",1438264650252000,"t",1438264650],

Мы думаем, что "т" означает надгробие. В этом блоге подробно описан еще один пример такого надгробия.

Другие вопросы по тегам