這篇文章主要為大家展示了“PostgreSQL MVCC源碼的示例分析”，內(nèi)容簡(jiǎn)而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“PostgreSQL MVCC源碼的示例分析”這篇文章吧。

創(chuàng)新互聯(lián)公司專注于利通企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,成都做商城網(wǎng)站。利通網(wǎng)站建設(shè)公司,為利通等地區(qū)提供建站服務(wù)。全流程按需網(wǎng)站設(shè)計(jì)，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)

      MVCC對(duì)每一個(gè)DBA來(lái)講，都不陌生，即多版本控制（Multi-Version-Control）。正因?yàn)閿?shù)據(jù)有了多個(gè)版本，才實(shí)現(xiàn)了讀和寫在一定程度上的分離，提高數(shù)據(jù)庫(kù)每秒處理查詢的能力（QPS）。

用戶發(fā)起的普通查詢請(qǐng)求（不包含select … for update語(yǔ)句），并不堵塞DML事務(wù)。在Read Commit事務(wù)隔離級(jí)別時(shí)，查詢請(qǐng)求只讀取查詢請(qǐng)求之前已經(jīng)提交的事務(wù)的數(shù)據(jù)更改，對(duì)當(dāng)前版本的數(shù)據(jù)并不影響；

而DML語(yǔ)句，會(huì)操作當(dāng)前版本。因此做到了讀寫分離的目的，提高數(shù)據(jù)庫(kù)并發(fā)能力。

      不同的數(shù)據(jù)庫(kù)，實(shí)現(xiàn)MVCC的方法不同。Oracle和MySQL Innodb 存儲(chǔ)引擎類似的使用undo來(lái)實(shí)現(xiàn)。

      對(duì)于PostgreSQL數(shù)據(jù)庫(kù)來(lái)講，他沒有undo，那么，PG又是怎么來(lái)實(shí)現(xiàn)他自己的MVCC呢？又有那些優(yōu)缺點(diǎn)呢？

     PG用copy tuple和tuple的xmin,xmax,cmin,cmax等標(biāo)記來(lái)實(shí)現(xiàn)多版本。

     xmin：在創(chuàng)建記錄(tuple)時(shí)，記錄此時(shí)，后面每次update也會(huì)更新。

     xmax: 在刪除tuple或者lock時(shí)，記錄此時(shí)；如果記錄沒有被刪除，那么此時(shí)為0。

     cmin和cmax：主要為標(biāo)識(shí)在同一個(gè)事務(wù)中多個(gè)語(yǔ)句命令的序列值。用于同一個(gè)事務(wù)中實(shí)現(xiàn)版本可見性判斷。

1.下面我們先來(lái)看一下xmin和xmax的變化：

從上圖可以看出，4條記錄的xmin是一樣的，都是“390689”，這說(shuō)明是在同一個(gè)事務(wù)中創(chuàng)建的。另外xmax都為“0”，說(shuō)明都沒有被刪除。cmin和cmax都是1，說(shuō)明是同一個(gè)命令創(chuàng)建的。

接下來(lái)，我們update一下id為1的記錄，看發(fā)生什么情況：

update之后，并沒有提交，重新開起另外一個(gè)窗口，查詢：

我們看到，ID為1的記錄，只有xmin沒有變化，其它三個(gè)值都發(fā)生了變化，其中xmax變成了”390691”。

然后我把事務(wù)提交掉，再在新窗口中查詢：

我們看到，提交后，ID 為1的記錄，xmin變?yōu)椤?90691”，xmin增加了1；而xmax變成了0。

從上面的案例中，我們從表面上可以看出,xmin增加了。但是事實(shí)上，PostgreSQL在底層所做的事情，遠(yuǎn)比這個(gè)要多。底層已經(jīng)生成了一個(gè)新版本的tuple，新版本tuple的xmin等于老版本的xmax。

詳細(xì)的internal，我后面再展開講。

2.我們?cè)賮?lái)看一下cmin和cmax的變化：

我起一個(gè)事務(wù)，包含兩條update，一條update ID值為2的記錄，一條insert ID值為3的記錄：

事務(wù)“390694”中，cmin和cmax的值，依次遞增。從目前來(lái)看cmin和cmax實(shí)際上是同一個(gè)field。

源碼定義如下，用union實(shí)現(xiàn)了CommandId，是一個(gè)combo command id。

因此，從上面的例子來(lái)看，PostgreSQL的mvcc實(shí)現(xiàn)是比較簡(jiǎn)單的。只需要通過對(duì)比tuple header中xmin,xmax,cmin,cmax與當(dāng)前的xid，就可以得到在scan tuple時(shí)，此tuple對(duì)于當(dāng)前查詢的可視性。

可見性判斷邏輯：

但是也帶來(lái)了另外一個(gè)問題：就是在沒有undo的情況下，會(huì)導(dǎo)致空間的增長(zhǎng)。因此PostgreSQL引入了vacumm后臺(tái)進(jìn)程，來(lái)定期清理這些 DEAD tuple。

以上是“PostgreSQL MVCC源碼的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

分享名稱：PostgreSQLMVCC源碼的示例分析
網(wǎng)站URL：http://chinadenli.net/article42/jggghc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、面包屑導(dǎo)航、微信公眾號(hào)、虛擬主機(jī)、云服務(wù)器、自適應(yīng)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)