Each statement in ByteHouse is encapsulated as a transaction implicitly and the transaction provides atomic, consistency, isolation, and durability (ACID) properties intended to guarantee data validity despite errors, network failures, machine failures, and other mishaps. All the data write in one statement are atomic and the other statements will not see partial data. For one write statement, all the write data becomes visible at the same time and is persistent after the write statement succeeds. Before that, nothing can be seen by any other statement. If write statement fails, ByteHouse will roll back the current transaction and the intermediate data write by this statement is cleaned automatically.
Currently, the explicit transaction starts by executing a BEGIN statement is not supported yet. This feature will be supported in future.
READ COMMITTED is the only isolation level currently supported for ByteHouse. With READ COMMITTED isolation, a statement sees only data that was committed before the statement begin and it never sees uncommitted data.
Concurrency control is used to guarantee the data correctness for concurrent updates. ByteHouse uses resource lock for concurrency control and the lock can be acquired at different resources such as DB, table, and partition. The lock blocks other statements from modifying the same resource until the lock is released. If one statement is blocked, the user running this statement can receive a message which shows the blocking transaction. The message is shown as "Current transaction is conflicted with other txn (txn_id: xxx)". If receiving this message, it is recommended to synchronize the statements need to acquire the same resource lock.
ByteHouse utilizes the multi-version concurrency control to improve the performance for concurrency read and write. The read will not be impacted or blocked by any other write on the same resource.
Updated about 1 year ago