JOIN в Vertica не работает, внутренний раздел не помещается в памяти

У меня проблема с большим запросом из десяти объединенных таблиц. Я переношу данные из широкой таблицы фактов (f1) в звездообразную схему. Я начинаю с заполнения таблиц измерений из f1, а затем заполняю новую таблицу фактов (f2) присоединением к таблицам измерений, чтобы получить соответствующие идентификаторы.

К сожалению, выдает ошибку: «Внутренний раздел не поместился в памяти». Из журнала вижу:

2012-10-18 16:20:31.607 Init Session:0x2aac6c02b250 [EE] <INFO>   ENABLE_JOIN_SPILL may allow this query to run, with reduced performance 
2012-10-18 16:20:31.607 Init Session:0x2aac6c02b250 [EE] <INFO> Query Retry action: Setting add_vertica_options('EE','ENABLE_JOIN_SPILL');

но это тоже не работает, так как позже я получаю:

2012-10-18 16:23:31.138 Init Session:0x2aac6c02b250 [EE] <INFO>   Join ((public.owa_search_term_dim x public.page_impressions_with_session) using owa_search_term_dim_projection_node0001 and previous join (PATH ID: 7)) inner partition did not fit in memory; value 
2012-10-18 16:23:31.138 Init Session:0x2aac6c02b250 [EE] <INFO> Query Retry action: Swapping join order with override: 1|7|0

Это продолжается некоторое время, пока Vertica, по-видимому, пытается найти способ выполнить соединение, но в конце концов выдает ошибку, говоря, что соединение не помещается в памяти.

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


database join vertica
person user997904    schedule 18.10.2012    source источник

Ответы (2)


arrow_upward
7
arrow_downward

Что я сделал, чтобы обойти эту ошибку ...

  • Перепишите запрос
    Иногда первоначальный запрос не так оптимизирован, как мог бы. Один из подходов к этому - использование подзапросов.
  • Использовать временные таблицы
    Некоторые отчеты, которые мне приходилось создавать, очень хорошо работают с использованием временных таблиц. Это более «экстремальный» вариант использования подзапросов.
  • Дополнительные фильтры
    Иногда такие мелочи, как добавление дополнительных фильтров и их передача в объединенные таблицы, будут иметь значение между 5-минутным OOM-запросом и 30-секундным рабочим запросом.
  • Ограничение данных Создание нескольких подмножеств данных за несколько шагов. Подобно дополнительным фильтрам, создание подмножеств данных уменьшает количество ресурсов, которые Vertica будет использовать, что обеспечивает успешное выполнение. Я часто делаю это для агрегатов на основе даты; Делаю по дням-> месяцу-> году. Это подмножество никогда не подводило, и я получаю точное годовое агрегирование, когда простое агрегирование года никогда не сработает.
  • Прогнозы
    Использование специально разработанных для этого запросов прогнозов может позволить Vertica использовать меньше ресурсов.
  • План объяснения
    Есть два основных преимущества, которые я извлекаю из просмотра плана объяснения.
    А) Убедитесь, что Vertica использует ожидаемые прогнозы < / em>. Например, запросить конкретные прогнозы для оптимизации производительности. Если я обнаружу, что это не так, я могу просмотреть свои ожидания и предположения, касающиеся запроса.
    Б) Убедитесь, что ко всем таблицам применены максимальные фильтры. В некоторых из моих более сложных подзапросов я обнаружил, что столбец «Дата» неправильно помещается во все таблицы. Как только я исправил это, производительность стала на порядок выше (см. Выше, от 5 минут до 30 секунд).

Используя эти шаги, я не сталкивался ни с какими ситуациями, когда я не мог бы получить результат. Иногда на это требуется время. У меня есть набор запросов, перекачиваемых в серию из 14 временных таблиц, которые заканчиваются очень маленьким набором результатов; но запуск занимает более 15 минут из-за того, что необходимо выполнить грубое измельчение.

person QuinnG    schedule 18.10.2012
comment
Все это хорошие предложения. Я уже ограничиваю данные, делаю день за днем, и я много возился с разными прогнозами, но я не знаю, к чему стремлюсь. Explain дает мне оценку стоимости, но это только с точки зрения скорости, верно? Я не знаю, как судить об использовании памяти внутренними соединениями, что, на мой взгляд, является проблемой. - person user997904; 19.10.2012

arrow_upward
0
arrow_downward

Ответ Ниджи - лучший ответ, но вот предложение, которое следует принять во внимание: получите больше памяти. Иногда вы перерастаете свою систему.

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

person geoffrobinson    schedule 19.10.2012