Фильтрация по несуществующим / нетипичным значениям столбца приводит к снижению производительности - PullRequest
Новая
       26

Фильтрация по несуществующим / нетипичным значениям столбца приводит к снижению производительности

0 голосов
/ 18 октября 2019

FAST (<0,1 с) </p> 

SELECT 1
FROM   sample
JOIN   unit ON sample.unit_key = unit.key
WHERE  sample.sample_id = 'http://example.com/foo';

+-JOIN HASH [Cost: 2K, Rows: 37] (PATH ID: 1)
|  Join Cond: (sample.UNIT_KEY = unit.KEY)
| +-- Outer -> STORAGE ACCESS for unit [Cost: 987, Rows: 3M] (PATH ID: 2)
| |      Projection: OLAPTEST_PRIVATE.UNIT_super
| |      Materialize: unit.KEY
| |      Runtime Filter: (SIP1(HashJoin): unit.KEY)
| +-- Inner -> STORAGE ACCESS for sample [Cost: 92, Rows: 37] (PATH ID: 3)
| |      Projection: OLAPTEST_PRIVATE.SAMPLE_super
| |      Materialize: sample.UNIT_KEY
| |      Filter: (sample.SAMPLE_ID = 'http://example.com/foo')

SLOW (> 2 с) 

SELECT 1
FROM   sample
JOIN   unit ON sample.unit_key = unit.key
WHERE  sample.sample_id = 'foo';

+-JOIN HASH [Cost: 5K, Rows: 1 (PREDICATE VALUE OUT-OF-RANGE)] (PATH ID: 1)
|  Join Cond: (sample.UNIT_KEY = unit.KEY)
| +-- Outer -> STORAGE ACCESS for sample [Cost: 90, Rows: 1 (PREDICATE VALUE OUT-OF-RANGE)] (PATH ID: 2)
| |      Projection: OLAPTEST_PRIVATE.SAMPLE_super
| |      Materialize: sample.UNIT_KEY
| |      Filter: (sample.SAMPLE_ID = 'foo')
| |      Runtime Filter: (SIP1(HashJoin): sample.UNIT_KEY)
| +-- Inner -> STORAGE ACCESS for unit [Cost: 987, Rows: 3M] (PATH ID: 3)
| |      Projection: OLAPTEST_PRIVATE.UNIT_super
| |      Materialize: unit.KEY
  • Фильтровать по 'foo '(несуществующее значение в столбце) -> медленно
  • Фильтр по' x http://example.com/...' (несуществующее значение в столбце) -> медленно
  • Фильтровать по 'http://example.com/foo'(несуществующее значение в столбце) -> fast
  • Фильтр по 'http://example.com/123' (существующее значение в столбце) -> fast

Без объединения запросfast.

Все значения в столбце sample_id начинаются с 'http://example.com/..'

Я проанализировал статистику для всех таблиц.

  • SAMPLE_ID VARCHAR(1000) NOT NULL (AUTO encoding). Никаких УНИКАЛЬНЫХ ограничений, внешних ключей и т. Д.
  • SAMPLE = 10 тыс. Строк
  • UNIT = 30M + строк

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

Выполнение запроса, аналогичного другой таблице (например, единице измерения), в которой также есть столбцы, значения которых являются http-Урис, не имеет подобного эффекта производительности.

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

Мы все еще находимся на Vertica 7, надеясь в скором времени перейти на новый кластер с более новой версией (в этот момент мы можемтакже создайте лучшие прогнозы для таблиц).

1 Ответ

0 голосов
/ 28 октября 2019

Поскольку таблица SAMPLE настолько мала, она должна быть UNSEGMENTED. Замените сегментированный суперпроецирование несегментированным - в любом случае, это лучший способ для такого маленького стола. Кроме того, наличие таблицы SAMPLE в качестве UNSEGMENTED устранит глобальную повторную сегментацию во время объединения.

Также попробуйте поставить sample_id в качестве первого столбца в предложении ORDER BY проекции. Это не создаст объединение, но оптимизирует фильтр предложений WHERE.

Дайте мне знать, если это поможет. Если это не так, пожалуйста, включите весь план объяснения в новый прогноз (включая Graphvis).

...