Почему стоимость запроса на сегодняшний кластер / раздел намного выше, чем в предыдущие даты? - PullRequest
3 голосов
/ 17 марта 2019

У меня есть таблица разделов / кластеров, как указано ниже:

enter image description here

Когда я запускаю этот запрос:

SELECT
  projectId
FROM
  `projectId.dataset.tables`
WHERE _PARTITIONTIME >= "2019-03-16 00:00:00" AND _PARTITIONTIME <= "2019-03-17 00:00:00" 
  AND projectId='myproject' 
GROUP BY
  projectId
limit 1

Я вижу фактическое сканирование 597 МБ

enter image description here

Однако, когда я выполняю тот же запрос в предыдущий день, как показано ниже:

SELECT
  projectId
FROM
  `projectId.dataset.tables`
WHERE _PARTITIONTIME >= "2019-03-15 00:00:00" AND _PARTITIONTIME <= "2019-03-16 00:00:00" 
  AND projectId='myproject' 
GROUP BY
  projectId
limit 1

Я вижу фактическое сканирование 122 МБ

enter image description here

Примечание: результаты будут еще хуже, если я добавлю больше столбцов.

Чтобы убедиться, что мой раздел имеет одинаковый размер, я посчитал количество projectId в каждом разделе

SELECT _partitionTime as date, count(projectId) as count
FROM
  `projectId.dataset.tables`
WHERE _PARTITIONTIME >= "2019-03-15 00:00:00" AND _PARTITIONTIME <= "2019-03-17 00:00:00" 
GROUP BY
  date

И, как вы можете видеть, сегодня раздел содержит еще меньше строк, чем предыдущие 2 дня

enter image description here

В дополнении я попытался запросить буфер потоковой передачи, используя этот запрос, который не дал результата

SELECT projectId FROM `projectId.dataset.tables`
WHERE _PARTITIONTIME IS NULL

Мой вывод таков: потоковый буфер влияет на стоимость запроса к таблице кластера , но я не уверен, как это может быть и почему.

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

1 Ответ

2 голосов
/ 17 марта 2019

Когда вы кластеризуете таблицу, вы в основном выбираете, как физически сортировать ее при сохранении.

Когда вы создаете поток в таблицу, новые строки сохраняются примерно в полученном порядке, следовательно, разбивая физическиотсортировано "обещание кластеризации.

BigQuery должен быть достаточно умным, чтобы время от времени переупорядочивать ваши кластеризованные таблицы, но если этот процесс не запустится, вы не увидите преимуществ кластеризации.

Согласно опубликованной в настоящее время документации, вы можете принудительно выполнить повторную кластеризацию несортированных данных с помощью MERGE:

Со временем, по мере того, как все больше и больше операций изменяют таблицу, степенькоторый сортирует данные, начинает ослабевать, и таблица становится частично отсортированной.В частично отсортированной таблице запросам, использующим столбцы кластеризации, может потребоваться сканирование большего количества блоков по сравнению с таблицей, которая полностью отсортирована.Вы можете повторно кластеризовать данные во всей таблице, выполнив запрос SELECT *, который выбирает и перезаписывает таблицу (или любой конкретный раздел в ней).Кроме того, любая произвольная часть таблицы может быть повторно кластеризована с помощью оператора DML MERGE.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...