Introduction to Multiversion concurrency control

Multiversion concurrency control protocol (Multiversion concurrency control) is a concurrency control implementation, commonly used in databases to provide concurrent access, and to implement transactional memory access in programming.

 

In the concurrency world, if one operation is reading data from the database while another operation is updating the data to the database, the read operation may read half-written data or inconsistent data.

 

There are many methods called concurrency control to solve this problem. The easiest way is to use locks. All read operations wait for the write operation to complete before reading. But this way is slow.

 

A different approach to multiversion concurrency control, each user connected to the database sees only one copy at a given time . When the modification of the write operation is complete (in the database, the transaction is committed), any modification of the write operation will not be seen by other connected users.

 

When a data item needs to be updated, it does not overwrite the old data with the new data, but marks the old data as obsolete and adds a new version. Multiple versions exist at this time, but only one is the latest. It allows read operations to access the data when they started reading, even if it was partially modified or deleted by other operations (write operations). It also avoids the overhead of filling holes in memory or disk structures but requires (and generally does) the system to periodically scan and delete old, obsolete data objects.

 

Multiversion concurrency control provides a check -point view for temporal consistency .

 

Multiversion concurrency control uses timestamps ( TS ) and auto-incrementing transaction IDs to achieve transaction consistency. By maintaining multiple versions of data, multi-version concurrency control ensures that a transaction ( T ) does not have to wait while reading data ( P ). Each version of data P includes a read time stamp ( RTS ) and a write time stamp (WTS) , so that a specific transaction Ti reads the latest version of the data, that is, the version before the transaction reads - read time stamp RTS (Ti) .

 

 

If transaction Ti wants to write data P , and other transaction Tk is writing this data at the same time, for this write operation ( WTS ) to succeed, the read timestamp RTS ( T i )  must be the timestamp before RTS ( T k ) , for example, RTS ( T i ) < RTS ( T  k ) . If another transaction (a newer read timestamp RTS , converted to a number, which is larger) has updated the data, the write operation will fail.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326974857&siteId=291194637