Я адаптирую инструмент веб-анализа, чтобы использовать Vertica
как БД. У меня настоящие проблемы optimizing joins
. Я попытался создать предварительные прогнозы для некоторых моих запросов, и, хотя это делало запросы быстрыми и быстрыми, это замедляло загрузку данных в таблицу фактов в обход.
Простой INSERT INTO ... SELECT * FROM
, который мы используем для загрузки данных в таблицу фактов из промежуточной таблицы, составляет от 5 секунд до 20+ минут.
В связи с этим я отбросил все предварительные прогнозы и попытался использовать конструктор баз данных для проектирования запросов, специфичных для конкретного запроса, но этого недостаточно. Даже с этими проекциями простое соединение занимает ~ 14 секунд, что занимает около 1 секунды с предварительным проецированием.
Мой вопрос заключается в следующем: нормальна ли предварительная проекция для медленной вставки данных, а если нет, что может быть виновником? Если это нормально, то это пробная пробка для нас и есть ли другие методы, которые мы могли бы использовать для ускорения соединений?
Мы запускаем Vertica в кластере 5 node, каждый node имеет 2 x четырехъядерный процессор и 32 ГБ памяти. Таблицы в моем примере запроса имеют 188 843 085 и 25 712 878 строк соответственно.
Выход EXPLAIN выглядит следующим образом:
EXPLAIN SELECT referer_via_.url as referralPageUrl, COUNT(DISTINCT sessio
n.id) as visits FROM owa_session as session JOIN owa_referer AS referer_vi
a_ ON session.referer_id = referer_via_.id WHERE session.yyyymmdd BETWEEN
'20121123' AND '20121123' AND session.site_id = '49' GROUP BY referer_via_
.url ORDER BY visits DESC LIMIT 250;
Access Path:
+-SELECT LIMIT 250 [Cost: 1M, Rows: 250 (STALE STATISTICS)] (PATH ID: 0)
| Output Only: 250 tuples
| Execute on: Query Initiator
| +---> SORT [Cost: 1M, Rows: 1 (STALE STATISTICS)] (PATH ID: 1)
| | Order: count(DISTINCT "session".id) DESC
| | Output Only: 250 tuples
| | Execute on: All Nodes
| | +---> GROUPBY PIPELINED (RESEGMENT GROUPS) [Cost: 1M, Rows: 1 (STALE
STATISTICS)] (PATH ID: 2)
| | | Aggregates: count(DISTINCT "session".id)
| | | Group By: referer_via_.url
| | | Execute on: All Nodes
| | | +---> GROUPBY HASH (SORT OUTPUT) (RESEGMENT GROUPS) [Cost: 1M, Rows
: 1 (STALE STATISTICS)] (PATH ID: 3)
| | | | Group By: referer_via_.url, "session".id
| | | | Execute on: All Nodes
| | | | +---> JOIN HASH [Cost: 1M, Rows: 1 (STALE STATISTICS)] (PATH ID:
4) Outer (RESEGMENT)
| | | | | Join Cond: ("session".referer_id = referer_via_.id)
| | | | | Execute on: All Nodes
| | | | | +-- Outer -> STORAGE ACCESS for session [Cost: 463, Rows: 1 (ST
ALE STATISTICS)] (PUSHED GROUPING) (PATH ID: 5)
| | | | | | Projection: public.owa_session_projection
| | | | | | Materialize: "session".id, "session".referer_id
| | | | | | Filter: ("session".site_id = '49')
| | | | | | Filter: (("session".yyyymmdd >= 20121123) AND ("session"
.yyyymmdd <= 20121123))
| | | | | | Execute on: All Nodes
| | | | | +-- Inner -> STORAGE ACCESS for referer_via_ [Cost: 293K, Rows:
26M] (PATH ID: 6)
| | | | | | Projection: public.owa_referer_DBD_1_seg_Potency_2012112
2_Potency_20121122
| | | | | | Materialize: referer_via_.id, referer_via_.url
| | | | | | Execute on: All Nodes