Существует не так много информации об этом, но в этом руководстве по миграции мы можем найти некоторые сравнения между BigQuery и Teradata, которые могут дать нам подсказку.
Как сказано в руководстве, BigQuery использует оптимистичное c управление параллелизмом, которое не использует операций блокировки, предполагая, что несколько транзакций могут часто завершаться, не мешая друг другу. Когда несколько транзакций DML выполняются в одной и той же таблице одновременно, BigQuery использует элемент управления параллелизмом pessimisti c, который использует операции блокировки. Чтобы обеспечить изоляцию , BigQuery использует метод изоляция моментальных снимков .
BigQuery помогает обеспечить оптимистичное c управление параллелизмом (первым для фиксации побед) с изоляция моментального снимка , в которой запрос считывает последние принятые данные перед началом запроса. Такой подход гарантирует одинаковый уровень согласованности для каждой строки, для каждой мутации и для всех строк в пределах одного и того же оператора DML, но избегает взаимоблокировок. В случае нескольких обновлений DML для одной и той же таблицы BigQuery переключается на управление параллелизмом c pessimisti. Загрузка заданий может выполняться полностью независимо и добавляться в таблицы. Однако BigQuery пока не предоставляет явной границы транзакции или сеанса.
В руководстве также сказано, что
Поскольку в BigQuery еще нет явной границы транзакции, в BigQuery также отсутствует концепция явного отката. Обходными решениями являются декораторы таблиц или использование FOR SYSTEM_TIME AS из .
Учитывая, что мы можем предположить, что BigQuery имеет конкретную реализацию optimistic concurrency control и pessimistic concurrency control, что затрудняет нам получение более глубокой информации.
Надеюсь, это поможет