BigQuery中的事务隔离级别是多少 [英] What is the transaction isolation level in BigQuery

问题描述

有人可以帮助解释什么是Google Cloud BigQuery中的事务隔离级别吗?似乎没有关于此的任何文件.我们知道在其他数据库中，例如sql server数据库中，有事务隔离级别:未提交读，已提交读，可重复读，快照，可序列化.

Can anyone help explain what is the transaction isolation level in google cloud BigQuery? It does not appear to be any documents on this. We know that in other databases, e.g. sql server database, there are transaction isolation levels : read uncommitted, read committed, repeatable read, snapshot, serialisable.

谢谢.

推荐答案

关于它的信息并不多，但是在此迁移指南中，我们可以找到BigQuery和Teradata之间的一些比较，这可以为我们提供线索.

There is not much information about it, but in this migration guide we can find some comparisons between BigQuery and Teradata which can give us a clue.

如指南中所述，BigQuery使用乐观并发控制，它假定多个事务可以频繁完成而不会互相干扰，因此不使用锁定操作.当在同一表中同时执行多个DML事务时，BigQuery使用悲观并发控制，该控制使用锁定操作.为确保隔离，BigQuery使用快照隔离方法.

As its said in the guide, BigQuery uses optimistic concurrency control which uses no lock operations by assuming that multiple transactions can frequently complete without interfering with each other. When multiple DML transactions are performed in the same table at the same time, BigQuery uses pessimistic concurrency control which uses lock operations. To ensure isolation, BigQuery uses a snapshot isolation method.

BigQuery有助于确保乐观的并发控制(首先提交) 胜)与快照隔离，其中查询读取了最后一个 查询开始之前提交的数据.这种方法保证了 按行，按变异和跨行具有相同级别的一致性 同一DML语句中的所有行，但避免了死锁.在这种情况下 同一张表的多个DML更新中，BigQuery切换到 悲观的并发控制.加载作业可以完全运行 独立地并附加到表中.但是，BigQuery尚未 提供明确的交易边界或会话.

BigQuery helps ensure optimistic concurrency control (first to commit wins) with snapshot isolation, in which a query reads the last committed data before the query starts. This approach guarantees the same level of consistency on a per-row, per-mutation basis and across rows within the same DML statement, yet avoids deadlocks. In the case of multiple DML updates against the same table, BigQuery switches to pessimistic concurrency control. Load jobs can run completely independently and append to tables. However, BigQuery does not yet provide an explicit transaction boundary or session.

它在指南中还说，

由于BigQuery尚无明确的交易边界， BigQuery也没有明确回滚的概念.这 解决方法是表修饰符或使用

Because there is no explicit transaction boundary in BigQuery yet, there is also no concept of an explicit rollback in BigQuery. The workarounds are table decorators or using FOR SYSTEM_TIME AS OF.

鉴于我们可以假设BigQuery具有optimistic concurrency control和pessimistic concurrency control的特定实现，这使我们很难获得更深入的信息.

Given that we can assume that BigQuery has its particular implementation of optimistic concurrency control and pessimistic concurrency control which makes it difficult for us to get more deep information.

我希望对您有帮助

这篇关于BigQuery中的事务隔离级别是多少的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！