|
Multiversion concurrency control (MCC or MVCC), is a concurrency control method commonly used by database management systems to provide concurrent access to the database and in programming languages to implement transactional memory.〔(refs ). Clojure. Retrieved on 2013-09-18.〕 If someone is reading from a database at the same time as someone else is writing to it, it is possible that the reader will see a half-written or inconsistent piece of data. There are several ways of solving this problem, known as concurrency control methods. The simplest way is to make all readers wait until the writer is done, which is known as a lock. This can be very slow, so MVCC takes a different approach: each user connected to the database sees a ''snapshot'' of the database at a particular instant in time. Any changes made by a writer will not be seen by other users of the database until the changes have been completed (or, in database terms: until the transaction has been committed.) When an MVCC database needs to update an item of data, it will not overwrite the old data with new data, but instead mark the old data as obsolete and add the newer version elsewhere. Thus there are multiple versions stored, but only one is the latest. This allows readers to access the data that was there when they began reading, even if it was modified or deleted part way through by someone else. It also allows the database to avoid the overhead of filling in holes in memory or disk structures but requires (generally) the system to periodically sweep through and delete the old, obsolete data objects. For a document-oriented database it also allows the system to optimize documents by writing entire documents onto contiguous sections of disk—when updated, the entire document can be re-written rather than bits and pieces cut out or maintained in a linked, non-contiguous database structure. MVCC provides ''point in time'' consistent views. Read transactions under MVCC typically use a timestamp or transaction ID to determine what state of the DB to read, and read these versions of the data. Read and write transactions are thus isolated from each other without any need for locking. Writes create a newer version, while concurrent reads access the older version. ==Implementation== MVCC uses timestamps (TS), and ''incrementing transaction IDs'' (T), to achieve ''transactional consistency''. MVCC ensures a transaction (T) never has to wait to ''Read'' a database object (P) by maintaining several versions of such object (P). Each version of the object (P) would have both a ''Read Timestamp'' (RTS) and a ''Write Timestamp'' (WTS) which lets a transaction (Ti) read the most recent version of an object (P) which precedes the transaction's (Ti) ''Read Timestamp'' (RTS(Ti)). If a transaction (Ti) wants to ''Write'' to an object (P), and if there is also another transaction (Tk) happening to the same object (P), the Read Timestamp (RTS) of (Ti) must precede the Read Timestamp (RTS) of (Tk), (i.e., RTS(Ti) < RTS(Tk)) for the object (P) ''Write Operation'' (WTS) to succeed. Basically, a ''Write'' cannot complete if there are other outstanding transactions with an earlier Read Timestamp (RTS) to the same object (P). Think of it like standing in line at the store, you cannot complete your checkout transaction until those in front of you have completed theirs. To restate; every object (P) has a ''Timestamp'' (TS), however if transaction Ti wants to ''Write'' to object (P), and there is a ''Timestamp'' (TS) of that transaction that is earlier than the object's current Read Timestamp, (TS(P) < RTS(Ti)), the transaction Ti is aborted and restarted. (If you try to cut in line, to check out early, go to the back of that line) Otherwise, Ti creates a new version of (P) and sets the read/write timestamp (TS) of the new version of (P) to the timestamp of the transaction TS=TS(Ti).〔Ramakrishnan, R., & Gehrke, J. (2000). Database management systems. Osborne/McGraw-Hill.〕 The obvious drawback to this system is the cost of storing multiple versions of objects in the database. On the other hand reads are never blocked, which can be important for workloads mostly involving reading values from the database. MVCC is particularly adept at implementing true snapshot isolation, something which other methods of concurrency control frequently do either incompletely or with high performance costs. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「Multiversion concurrency control」の詳細全文を読む スポンサード リンク
|