Делать надгробия в Cassandra замедлять запросы, даже если не выбрано с предложением where - PullRequest
Новая
       78

Делать надгробия в Cassandra замедлять запросы, даже если не выбрано с предложением where

0 голосов
/ 24 апреля 2018

Если у меня есть один раздел с 100'000 удаленных строк в одном кластере, за которым следует второй кластер в том же разделе без удаленных строк, повлияет ли производительность выполнения SELECT * FROM example_table WHERE partition=that_partition AND cluster=the_second_cluster на надгробия, присутствующие в the_first_cluster?

Я ожидаю, что если поиск наборов строк с предложением where является постоянным, то Cassandra просто перепрыгнет все надгробия ко второму кластеру, но я не понимаю, как предложение where находитправильный ряд, поэтому я не знаю, так ли это, и мне не удалось найти в Интернете ничего, что могло бы просветить меня. 

// Example table
CREATE TABLE example_table (
  partition TEXT,
  cluster TEXT,
  value BLOB,

  PRIMARY KEY (partition, cluster);

// Example layout of rows in a table
partition      |cluster            |value
that_partition |the_first_cluster  |some_value1 // Deleted, a tombstone
that_partition |the_first_cluster  |some_value2 // Deleted, a tombstone
... 99'997 more similar tombstone rows
that_partition |the_first_cluster  |some_value  // Deleted, a tombstone
that_partition |the_second_cluster |some_valueA // Not a tombstone
that_partition |the_second_cluster |some_valueB // Not a tombstone
... no tombstones in the_second_cluster

1 Ответ

0 голосов
/ 24 апреля 2018

Большое количество надгробий в разделе значительно повлияет на производительность, если оно будет включено в результат. Хорошая рецензия https://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets говорит об этом. В зависимости от запроса, он может закончить чтение всех 100 000 надгробий, а также, возможно, исходных данных, если на другом sstable для удовлетворения запроса. Это генерирует много мусора в куче и будет влиять на GC JVM вместе со значительным количеством ЦП и ввода-вывода для одного запроса.

Однако, если надгробия являются точечными удалениями, а не диапазонами надгробий, и ваш запрос направляется непосредственно к разделу + кластеризация не удаленного ключа, вы будете в порядке. Хотя это тонкая грань, и я бы порекомендовал не пытаться делать это (что, если кто-то попытается прочитать его из приложения в качестве задачи ops / test? Это может вызвать длинные GC и негативно повлиять на кластер). Надгробия диапазона, хранящиеся в индексе раздела, десериализуются как часть чтения, к которому нужно перейти, чтобы попасть в размер индекса столбца строки, поэтому даже если они не читаются напрямую, это все равно может существенно повлиять на скорость выделения в зависимости от того, как был вставлен ваш надгробный камень.

В cassandra.yaml установлен порог предупреждения / сбоя надгробной плиты, так что он будет сообщать вам о том, попадает ли ваш запрос в них, но может быть трудно определить, пока вы не достигнете точки сбоя и запросы не прекратятся, поскольку только что сообщили в журналах .

Я бы порекомендовал вам установить временные рамки для ваших разделов, чтобы ограничить количество надгробий в каждом из них.

...