IN Query in Cassandra Где оговорка - PullRequest
Новая
       157

IN Query in Cassandra Где оговорка

3 голосов
/ 04 мая 2020

У меня есть кластер Scylla с 3 узлами и 1 таблицей, созданный с помощью приведенного ниже запроса 

CREATE TABLE id_features (
    id int PRIMARY KEY,
    id_feature_1 int,
    id_feature_2 int,

)

Я выполняю запрос ниже из приложения SELECT * FROM id_features where id in (1,2,3,4...120); Запрос может иметь максимум 120 идентификаторов.

Будет ли этот запрос связываться со всеми 3 узлами на основе значения идентификатора токенов для получения данных для 120 идентификаторов в худшем случае? Или же только один узел свяжется для извлечения данных для всех идентификаторов, а несколько узлов используются только для высокой доступности

. В определении узла будут играть роль фактор репликации, уровень согласованности и балансировки нагрузки

1 Ответ

4 голосов
/ 04 мая 2020

Будет ли этот запрос связываться со всеми 3 узлами на основе значения токена id s для извлечения данных

Будет ли фактор репликации, уровень согласованности и политика балансировки нагрузки играть какую-либо роль в принятии решения узел?

Это очень сильно зависит от таких факторов, как коэффициент репликации (RF), согласованность запросов и политика балансировки нагрузки. В частности, если RF <число узлов, то будут связываться с несколькими узлами, основываясь на хешированном значении токена <code>id и узлах, в первую очередь назначенных этим диапазонам токенов.

Но, учитывая этот оператор:

Или только 1 узел свяжется для извлечения данных для всех идентификаторов, а несколько узлов используются только для высокой доступности

... Я понимаю, что RF = В этом случае 3.

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

Но в этом случае в запросе используется оператор IN. Исходя из 120 потенциальных записей, запрос не может определить один узел для отправки запроса. В этом случае TokenAwarePolicy просто действует как проход для своей дочерней политики (DCAwareRoundRobinPolicy), и он выберет узел на расстоянии LOCAL, чтобы стать «координатором». Затем узел-координатор возьмет на себя дополнительные задачи по маршрутизации запросов на реплики и компиляции результирующего набора.

Относительно того, используются ли неосновные реплики в планах запросов, ответ снова «зависит». Хотя политики балансировки нагрузки различаются по реализации, в целом все они вычисляют планов запросов , которые:

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

Взято из: https://docs.datastax.com/en/developer/java-driver/3.6/manual/load_balancing/#query -plan

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

Pro-tip :

Старайтесь не использовать оператор IN со списком из 120 записей ключа раздела. Это заставляет Кассандру выполнять случайное чтение, где оно действительно превосходно при последовательном чтении . Если это запрос, который действительно нужно приложению, попробуйте:

  • Создание новой таблицы для лучшей поддержки этого шаблона запроса.
  • Не должно превышать двузначных чисел записей для IN .
...