Google BigQuery DML - низкая производительность при выполнении обновлений и удалений

Question

Я провел несколько тестов BigQuery DML, чтобы получить лучшее представление о производительности возможностей BigQuery DML. Итак, вот некоторые начальные наблюдения: 1) Низкая производительность при обновлении только нескольких записей в очень маленькой таблице (30K+ записей)

UPDATE babynames.names_2014
SET name = 'Emma B' 
WHERE name = 'Emma';

Вывод: - затронуто 2 строки (количество записей в таблице: 33176) - запрос завершен (прошло 4,5 с, обработано 621 КБ)

---

2) Очень низкая производительность при удалении только нескольких записей из небольшой таблицы

SQL:

DELETE from babynames.names_2014_copy
where gender<>'U'

Вывод: затронуты - 2 строки. - Запрос завершен (прошло 162,6 с, обработано 1,21 МБ) - ~3 минуты

ВОПРОСЫ:1) Это известное поведение? 2) Есть предложения по улучшению производительности?

Answer 1

(1) приблизительно ожидаемый - первичные сценарии DML - это большие обновления / удаления, затрагивающие много строк (миллионы / миллиарды строк). Поэтому задержка менее важна, чем пропускная способность.

(2) не выглядит нормально - не могли бы вы попробовать еще раз? Что-нибудь необычное в таблице, которую вы пытаетесь обновить?

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

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

Answer 2

«Интересно, что перезапись таблицы оператором «создать или заменить таблицу» обычно дает значительно лучшую производительность». - Мне интересно, сколько квоты на обработку данных используется с этим методом:/

Я подозреваю, что Google намеренно пытается ограничить и замедлить эти операции, поскольку большой запрос является строго непроизводственной базой данных для хранения данных в аналитических целях. Я также обнаружил, что утром, когда я запускаю какую-то операцию, он какое-то время работает нормально, а затем сбрасывает обороты. Это действительно заставляет меня задуматься, может быть, postgreSQL — это то, что нужно, поскольку bigquery считается более простым и прямолинейным, но, по-видимому, это не всегда так.

Answer 3

Я тоже это заметил и Deleteоперации могут быть очень медленными в BigQuery.

Интересно, что перезапись таблицы оператором «создать или заменить таблицу» обычно имеет значительно лучшую производительность.

Итак, вместо:

      DELETE from babynames.names_2014_copy
where gender<>'U'

рассмотрите возможность использования:

      create or replace table babynames.names_2014_copy
AS
select *
from babynames.names_2014_copy
where not  gender<>'U'

Аналогичная методика работает и для Update; вам просто нужно написать caseоператор для изменения ваших значений.