Надгробия влияют на Кассандру читает - PullRequest
Новая
       32

Надгробия влияют на Кассандру читает

0 голосов
/ 11 июня 2018

Я немного запутался с надписями на Кассандре.Вот первая ситуация:

Существует таблица Кассандры: 

CREATE TABLE IF NOT EXISTS URL_MAPPINGS (
  pagehash          text,
  url               text,
  address           text,
  PRIMARY KEY ((pagehash), url)
)

Я вставляю две записи в эту таблицу: 

INSERT INTO url_mappings (pagehash1, url1, address1)
INSERT INTO url_mappings (pagehash2, url2, address1)

Затем я использую команду nodetool flush нав этой таблице и ясно видно два сохраненных значения (с использованием sstabledump).

Затем я обновляю значение адреса в первой записи: 

UPDATE url_mappings SET address='updated' WHERE pagehash='pagehash2' AND url='url2';

Еще раз я использую команду nodetool flush для этой таблицы и вижуДобавлена ​​надгробная плита для первого столбца адреса записи.

Хорошо, теперь я читаю эти значения через 

SELECT * FROM url_mappings;

с TRACING ON, установленным в sqlsh.Я вижу, что были возвращены 2 последние записи со следующими результатами отладки:

Чтение 2 живых строк и 0 ячеек-надгробий

Обновление AFAIK не является надгробной плитой,однако я вижу, что несколько SSTable были прочитаны для того, чтобы вернуть результат.

Как только я удаляю первую запись - я вижу следующее в выводе при повторном чтении всех табличных значений:

Прочитайте 1 живой ряд и 1 надгробную клетку

Это то, что я ожидаю увидеть.Однако когда я выполняю этот запрос для оставшейся записи: 

SELECT pagehash, url, address, ttl(address) FROM url_mappings WHERE pagehash='somethin2';

я вижу следующую информацию трассировки:

Чтение 1 живых строк и 0 ячеек-надгробий

Вопрос заключается в том, почему надгробия выбираются только в том случае, если в предложении WHERE нет столбцов?

1 Ответ

0 голосов
/ 18 июня 2018

Похоже, что надгробия влияют только на чтение для запросов срезов , поэтому Кассандра не знает заранее, какие Memtable / SSTable (s) содержат запрошенные записи, и ей нужно пройти через все из них, пока один изсоблюдены следующие условия:

  • указанный предел активных столбцов был прочитан
  • столбец за конечным столбцом был прочитан (если указан)
  • все столбцы встрока была прочитана

Один хороший пример описан [здесь] [https://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets].

Это не тот случай чтения, когда поиск выполняется на основе точного равенства сзначение столбца (индексированное).В этом случае Cassandra просто использует Bloom-фильтры и индексы для проверки Memtable / SSTables - это никак не влияет на скорость чтения.

...