Выполнение запросов без первичного ключа на полностью реплицированном кластере Cassandra - PullRequest
Новая
       89

Выполнение запросов без первичного ключа на полностью реплицированном кластере Cassandra

0 голосов
/ 30 декабря 2018

Я установил полностью реплицированный кластер Cassandra с 3 узлами на одной машине с использованием контейнеров Docker со следующим статусом:

Datacenter: dc_n1
=================
Status Address Load Tokens Owns Host_ID Rack
UN 172.18.0.3 83.98 MiB 256 100.0% 5bf rack_n1

Datacenter: dc_n2
=================
Status Address Load Tokens Owns Host_ID Rack
UN 172.18.0.6 83.52 MiB 256 100.0% 0518 rack_n2

Datacenter: dc_n3
=================
Status Address Load Tokens Owns Host_ID Rack
UN 172.18.0.2 83.52 MiB 256 100.0% ca95 rack_n3

Теперь рассмотрим следующее пространство ключей:

create KEYSPACE stackoverflow WITH replication = {'class': 'NetworkTopologyStrategy', 'dc_n1':1,'dc_n2':1,'dc_n3':1};

и таблицу, определенную как (предположим, T_notIDуникален):

create TABLE stackoverflow.TABLE (T_ID int PRIMARY KEY, T_notID int, T_Data text);

Когда я отправляю число (скажем, сотню) параллельных потоков Java, отправляя следующие два запроса JDBC узлам Cassandra (несколько раз, в течение минуты)Я наблюдаю 100-кратное падение производительности для (B) запросов:

(A) ВЫБРАТЬ T_Data ИЗ ТАБЛИЦЫ ГДЕ T_ID =?

(B) ВЫБРАТЬ T_Data ИЗ ТАБЛИЦЫ ГДЕ T_notID =?Разрешить фильтрацию

(B) запросов также вызывает много ошибок Кассандры, которые: com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout during read query at consistency ONE (timeout while waiting for repair of inconsistent replica):

Я понимаю, что, как правило, использование 'ALLOW FILTERING' в запросах является антипаттерноми должен использоваться с особой осторожностью, но в приведенном выше упрощенном примере, поскольку данные полностью реплицированы и одна копия каждого элемента находится на каждом узле, я не понимаю, почему PK-запросы и неPK-запросывести себя по-другому.

Другими словами, учитывая тот факт, что read consistency в этом сценарии равно ONE, и каждый узел может отвечать на запросы, не связываясь с другими узлами в кластере (независимо от определения первичного ключа), ямог бы ожидать аналогичного поведения от Cassandra для централизованной базы данных SQL.

Может кто-нибудь объяснить мне, почему это происходит и / или как я могу это исправить?

1 Ответ

0 голосов
/ 30 декабря 2018

Если у вас есть условие для ключа раздела - Кассандра знает, где находятся данные на диске, и может перейти к началу раздела и последовательно прочитать данные.Но если у вас есть условие для неразделения, тогда ваш запрос должен будет пройти через все данные и отфильтровать только необходимые фрагменты - у вас нет индексов, которые позволили бы Cassandra выяснить, где находятся данные.

Если вам нужно очень часто запускать запрос к T_notID, вы можете создать материализованное представление или вторичный индекс (но вам нужно понять, какие у них ограничения).

DataStax имеет очень хороший пост в блоге о разрешении фильтрации и о том, где его можно использовать.

...