Производительность UNION против IN для ключа разделения в Кассандре - PullRequest
Новая
       40

Производительность UNION против IN для ключа разделения в Кассандре

0 голосов
/ 24 февраля 2019

Допустим, у нас есть следующая таблица Кассандры: 

create table news(
    date text,
    source text,
    category int,
    id text,
    title text,
    tags text,
    primary key ((date, source, category), id)
)

Теперь нам нужно поддерживать поиск по дате, категории и источнику: 

select * from news where date in ('2019-01-23', '2019-01-24') and 
category in (1, 4, 6) and source in ('Bloomberg', 'CNN');

Мне сказали, что этот запросбудет выполнять неоптимальное сравнение с тем же, где мы разбиваем все группы IN на отдельные запросы и объединяем результаты, используя UNION (12 подзапросов в случае выше).Причина заключается в том, что UNION будет разделен на 12 независимых запросов, и каждый из них может быть обработан одним из узлов в кластере (более 20 узлов), и мы начнем получать результаты быстрее.Предполагалось, что это будет быстрее и в том случае, если мы просто хотим убедиться, что количество возвращаемых строк ниже некоторого порога: 

select count(*) (
    select * from news where date in ('2019-01-23', '2019-01-24') and 
       category in (1, 4, 6) and source in ('Bloomberg', 'CNN') LIMIT 10001
);

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

Я использую Spark SQL (Hive 2) и драйвер Java CQL для доступа к данным в Cassandra.

Буду признателен за любую полезную информацию.

Спасибо

Ответы [ 2 ]

0 голосов
/ 14 марта 2019

Когда вы отправляете 12 запросов в кластер из 12 узлов, существует вероятность, что 12 узлов будут независимо получать данные и возвращать их обратно через координатора.Это правильное распределение работы через параллельные запросы.Вот почему разбивать запросы быстрее.Если у вас недостаточно данных или узлов, вы, возможно, никогда не увидите эту разницу.

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

0 голосов
/ 26 февраля 2019

пара точек,

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

  2. Производительность зависит не только от количества записей, которые вы пытаетесь, а больше от количества ключей разделения, используемых в вызове - пример вышекажется слишком мало, чтобы доказать разницу в производительности.Если вы можете попробовать тот же сценарий с гораздо большим количеством разделов (например, вы хотите отфильтровать 50 дат вместо 2), то вы увидите, что IN становится хуже.

...