Считает ли count() базовую таблицу, которую она должна учитывать?

Question

Мой босс хочет, чтобы я присоединился к трем столам, назовем их tableA, tableB, tableC, которые имеют соответственно 74M, 3M и 75M строк.

В случае, если это полезно, запрос выглядит следующим образом:

SELECT A.*, 
    C."needed_field" 
FROM "tableA" A 
INNER JOIN (SELECT "field_join_AB", "field_join_BC" FROM "tableB") B 
    ON A."field_join_AB" = B."field_join_AB" 
INNER JOIN (SELECT "field_join_BC", "needed_field" FROM "tableC") C 
    ON B."field_join_BC" = C."field_join_BC" 

При попытке запроса на Dataiku Data Science Studio + Vertica, это, кажется, создает временные данные для получения выходного сигнала, который заполняет вверх 1T пространства на сервер, раздувая его.

Мой босс мало знает о SQL, поэтому он не понимает, что в худшем случае он может создать таблицу с 74M * 3M * 75M = 1.6 * 10^19 строк, возможно, являющуюся проблемой здесь (и я совершенно новый, и я пока не знаю данных, поэтому не знаю, может ли запрос произвести столько строк или нет).

Поэтому я хотел бы знать, если у меня есть способ узнать заранее, сколько строк будет производиться: если я сделал COUNT(), такие как это, например:

SELECT COUNT(*) 
FROM "tableA" A 
INNER JOIN (SELECT "field_join_AB", "field_join_BC" FROM "tableB") B 
    ON A."field_join_AB" = B."field_join_AB" 
INNER JOIN (SELECT "field_join_BC", "needed_field" FROM "tableC") C 
    ON B."field_join_BC" = C."field_join_BC" 

производит ли базовый двигатель весь набор данных, а затем подсчитывает его? (что означало бы, что я не могу сосчитать это заранее, по крайней мере, не так).

Возможно ли, что результат COUNT() дает мне результат? (Потому что он не строит набор данных, но работает это какой-то другой путь)

(NB: Я в настоящее время тестирования, но граф был запущен на 35 млн сейчас)

Answer 1

Vertica является столбчатыми базами данных. Любые запросы, которые вы делаете, должны только смотреть на столбцы, необходимые для разрешения вывода, объединения, предикатов и т. Д.

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

В Vertica могут быть очень быстрые счета. Вам не нужно прыгать через обручи, Vertica будет включать только столбцы, которые фактически используются. Оптимизатор не будет пытаться воссоздать всю строку, только нужные ей столбцы.

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

Я бы рассмотрел запуск DBD с использованием этих запросов в качестве входных данных, особенно если это обычные шаблоны запросов. Если вы еще не запускали DBD и не используете пользовательские прогнозы, ваши прогнозы по умолчанию, скорее всего, не будут работать хорошо и вызовут ситуацию, о которой я упоминал выше.

Вы можете сделать объяснение, чтобы узнать, что происходит.