數(shù)據(jù)庫的江湖情仇：事務篇

　　文章來源：杭州美創(chuàng)科技有限公司

2015年左右，因為工作需要用MongoDB、CouchBase這兩種文檔型數(shù)據(jù)庫，時不時到這兩個數(shù)據(jù)庫官網(wǎng)上查資料、報BUG。時?？梢栽贛ongoDB官網(wǎng)上看到這樣一些新聞，“某某企業(yè)成功將MySQL替換成MongoDB，性能大幅提升”，“某某公司將Oracle替換成MongoDB，節(jié)約成本若干”……

而在CouchBase官網(wǎng)上，又會時不時看到這樣的新聞：“A公司將MongoDB替換成CouchBase，性能提升顯著”、“B公司將MongoDB替換為CouchBase，性能大大提升。”……

這樣的廣告詞往往讓數(shù)據(jù)架構人員無所事從，看到了上面的新聞，如果你是數(shù)據(jù)架構人員，你要如何選擇數(shù)據(jù)庫呢?

是用關系型的MySQL/Oracle，還是“更好”的MongoDB，還是“更更好”的CouchBase?或者，還有“更更更好”數(shù)據(jù)庫可供選擇，要不要嘗個鮮?

我相信放在官網(wǎng)中的新聞，一定不會弄虛做假。但隱藏了很多關鍵信息后，這樣的新聞就略有點不負責了。

要知道2015年時，MongoDB才剛剛支持一個Document內的事務。簡單點說，還不支持跨行事務。如果你輕信了這樣的新聞，貿(mào)然將需要跨行的、復雜事務的應用，建立在了MongoDB之上，你可以去準備你的簡歷了。

CouchBase也一樣，它是CouchDB和Memcached的組合。CouchDB是文檔型數(shù)據(jù)庫，Memcached作為存儲引擎，合起來就是CouchBase。其實相當于把數(shù)據(jù)放在Memcached中的MongoDB。

它之所以比MongoDB更快，是因為它的數(shù)據(jù)都是在內存中。如果MongoDB的內存也很大，所有數(shù)據(jù)也都緩存在內存中，誰更快還不好說。

而且，一旦CouchBase數(shù)據(jù)量超過主機內存，發(fā)生真正的物理I/O，其性能下降是十分明顯的，往往要慢于MongoDB。

不明白這些數(shù)據(jù)庫的內在本質，貿(mào)然的選擇某個數(shù)據(jù)庫。個人準備簡歷這只是小事，對企業(yè)造成的損壞將難以估量。之前我寫過一篇《Digg啟示錄》，為大家總結美國知識分享類網(wǎng)站Digg，為追求橫向擴展，而盲目的替換底層數(shù)據(jù)庫，導致問題重重，應用頻繁出錯，網(wǎng)頁時常打不開，致使公司在重要的發(fā)展窗口期痛失契機，最后50萬美元被收購的下場(高峰時期，Digg曾估值5億美元)。

如果你面對繁多的數(shù)據(jù)庫，有點眼花撩亂，沒關系有美創(chuàng)專業(yè)的數(shù)據(jù)庫團隊在，美創(chuàng)可以為您的數(shù)據(jù)提供從架構選型、到運維、到安全……等全方位的服務。

廣告就到這里，今天為大家繼續(xù)梳理數(shù)據(jù)架構選型中的坑，這一期我們討論OLTP的“事務”。

很多人對這個詞已經(jīng)陌生，NoSQL大行其道之后，事務好像已經(jīng)是可有可無的東西了。實際上不然，NoSQL的領頭羊MongoDB一直在默默的發(fā)展事務功能，到4.0以上版本(現(xiàn)在最新版是4.3)，已經(jīng)基本上實現(xiàn)傳統(tǒng)關系型數(shù)據(jù)庫的事務功能了。

事務對OLAP型應用來說的確是可有可無，但對OLTP來說，絕對是必須的。

事務的概念是從哪里來的呢？這可以一直追溯到上世紀70年代，關系型數(shù)據(jù)庫剛剛誕生的時期。

1970前后，已經(jīng)功成名就的數(shù)據(jù)庫圈大佬——E.F.Codd，有感于層次、網(wǎng)狀數(shù)據(jù)庫的不便，提出了創(chuàng)世級的關系模型，從此開啟了關系數(shù)據(jù)庫時代。

但是在整個70年代，關系型的發(fā)展都不是太好，E.F.Codd老爺子忙于推廣他的關系模型。無暇他顧。

這時候比E.F.Codd小20歲的數(shù)據(jù)庫新秀：James Gray(昵稱Jim)登場了。

Jim是IBM SYSTEM R的開發(fā)人員。SYSTEM R是IBM的關系型數(shù)據(jù)庫的嘗試。Jim在開發(fā)SYSTEM R時，不斷在思考一個問題：

“如何能多、快、好、省的保證數(shù)據(jù)庫的一致性”。

Jim老爺子想出來的大招就是：

把數(shù)據(jù)庫中相關的操作看作一個統(tǒng)一的原子操作，這些相關的操作要么都成功、要么都失敗。這就是事務了，事務的概念，就從這里誕生了。

只要保證每個事務都是一致的，數(shù)據(jù)庫就是一致的。

這樣，問題“保證數(shù)據(jù)庫的一致性”，就變?yōu)?ldquo;保證事務一致性”。

你看，問題的范圍大大縮小了。這就是頂級架構師的思維。

說到如何“多、快、好、省”的保證事務一致性？

這個問題并不簡單，數(shù)據(jù)庫的操作是多重并發(fā)的，事務是互相重疊且相關的，在一段時間內，我可能更新了你要查詢的行，你要刪除他正在更新的行……在這種互相交織在一起的情況是十分普遍的。

Jim老爺子后來研究了一輩子事務這東西，終于在1994年獲得了圖靈獎。圖靈獎可以計算機界的諾貝爾獎，而有關數(shù)據(jù)庫的圖靈獎，一共有4次。其中，就有一次就是和事務相關的，足以說明事務很復雜、很重要。

Jim老爺子后來把他的研究成果還寫成了一本書，叫《事務處理：概念與技術》。如果你想開發(fā)一個能保證事務一致性的數(shù)據(jù)庫，建議你讀一讀。

簡要說一下老爺子的思想，當時已經(jīng)有了兩階段提交協(xié)議，但它是針對分布式的，因此比較松散，用它來實現(xiàn)事務的原子性太慢了。

Jim另辟捷徑，提出了一個DO-UNDO-REDO協(xié)議，來張老爺子的書《事務處理：概念與技術》中的圖說明一下吧：

圖片來源：《事務處理：概念與技術》

搞過Oracle、DB2、SQLServer的人一看這圖，一定就能心領神會。

我摘錄一下書中對此圖的解釋：

DO，就是操作，比如一些UPDATE、INSERT或DELETE的SQL。它讓數(shù)據(jù)庫從舊的狀態(tài)變?yōu)樾碌臓顟B(tài)。它同時會產(chǎn)生日志。

UNDO，利用日志，將新狀態(tài)變回舊的狀態(tài)。

REDO，利用日志，從舊狀態(tài)轉移到新狀態(tài)。

這個圖其實和DB2、SQLServer中的事務機制完全一樣，他們的UNDO日志和REDO日志就是合在一起的。比如：在SQLServer中就叫事務日志，回滾、恢復都靠事務日志。

之所以DB2、SQLServer中的事務機制，和Jim老爺子書中的圖一模一樣，因為這兩個數(shù)據(jù)庫都和Jim老爺子有直接的聯(lián)系：

DB2可以說是脫胎于IBM的關系型數(shù)據(jù)庫嘗試產(chǎn)品：SYSTEM R。Jim老爺子當年是SYSTEM R的主力開發(fā)。

SQLServer更不必說，Jim老爺不想離開生活慣了的洛杉磯去西雅圖，Bill.Gets專門在洛杉磯建了一個研究院，由老爺子做院長，領導開發(fā)了SQLSever數(shù)據(jù)庫。

額外說一下，我曾看到過一個問題：程序員為什么愛發(fā)博客。最高票的回答是：因為解決了一個牛B的問題，身邊卻沒有人懂。

在上世紀70年代，還沒有博客這玩意，郵件組還要再過幾年才流行。Jim在SYSTEM R中解決了一系列復雜的事務、一致性等問題，但是，無人能欣賞，這種寂寞高手的感覺，高處不勝寒。

怎么辦，Jim一邊開發(fā)著SYSTEM R，思考著復雜的事務問題，一邊抽空寫博客，對了，當時還沒有博客，那就寫論文吧。1976年時，Jim寫了篇重要的論文：《共享數(shù)據(jù)庫的一致性和鎖的粒度(Granularity of Locks and Degrees of Consistency in a Shared Data Base)》。就是在這篇論文中，Jim首次提出了“事務”和一致性的概念。

老爺子論文寫的不亦樂乎，沒想到旁邊有個“偷拳”的家伙——埃里森。小埃當時已經(jīng)看了E.F.Codd在IBM時的論文，搞了個關系型數(shù)據(jù)庫Oracle。IBM是當時當之無愧的大哥，跟著大哥走還會有錯?

小埃偷拳偷的不亦樂乎的時候，Jim又發(fā)表了他的關于事務的論文，所以，如你所見，Oracle中的事務也是DO-UNDO-REDO協(xié)議了。

只不過，Oracle把UNDO和REDO分開了，UNDO有專門的UNDO段。這后來又影響了MySQL、國產(chǎn)的達夢數(shù)據(jù)庫，他們的UNDO都是分離的，UNDO在UNDO段中。

雖然UNDO和REDO合在一起，才是正宗Jim老爺?shù)乃枷?。但分離式的設計也不差，很難說誰比誰更強。

從事務的角度上來說，Oracle、DB2、SQLServer、達夢，這些數(shù)據(jù)庫事務的設計各有千秋。

從成熟度上來說，當然是Oracle、DB2的成熟度更高、性能更好，但SQLServer、達夢數(shù)據(jù)庫也不錯，性能上、功能上，也完全可以滿足我們的需要。

但數(shù)據(jù)庫的江湖上，除了DO-UNDO-REDO派之外，還有另外一大流派。因為使用了完全不同的事務實現(xiàn)協(xié)議，有些操作的性能表現(xiàn)和DO-UNDO-REDO派有著明顯的差異。

這另外一大派，是由另一圖靈獎得主、開宗立派的宗師級大師，邁克爾.斯通布雷克（Michael Stonebraker）開創(chuàng)的多版本派。

在數(shù)據(jù)庫界風起云涌的70年代，Michael按耐不住寂寞，出手搞了一個關系型的數(shù)據(jù)庫：Ingres。Ingres衍生出很多數(shù)據(jù)庫，PostgreSQL就是其中之一。

Michael老爺子認可Jim的事務概念，但對于如何實現(xiàn)事務，他采用了和Jim不一樣的方法，他沒有完全采用DO-UNDO-REDO協(xié)議，REDO仍然是需要的。Redo中的后映像是為了恢復。UNDO呢，它是前映像數(shù)據(jù)，為了把數(shù)據(jù)恢復修改之前。

把數(shù)據(jù)恢復到修改之前，或者提供前映像讀，未必就一定需要UNDO日志(或UNDO 段)。也可以使用多版本的機制。

下面以Update為例，比較一下多版本派和UNDO派在事務流程中的不同，從中總結一下這兩種流派的優(yōu)、缺點。

(圖為Update前的表數(shù)據(jù)，左邊是多版本派，右邊是UNDO派)

對于多版本派的表來說，每一行數(shù)據(jù)都會增加些版本信息，事務號、提交標志就是這些版本信息的一部分。有些多版本派的數(shù)據(jù)庫，會用一個事務開始的時間戳代表事務號，而不是用特定的一個數(shù)字。這在NoSQL/NewSQL數(shù)據(jù)庫中很常見。

對于UNDO派的數(shù)據(jù)庫來說呢，會有一個UNDO日志。Oracle/MySQL是有一個專門的UNDO段。DB2/SQLServer的UNDO和REDO都是放一起的。

下面，用戶發(fā)出了更新操作，數(shù)據(jù)庫收到了一條Update命令：

Update test set col=’BBB’ where id=4

數(shù)據(jù)庫在執(zhí)行這條SQL時，相關事務和表數(shù)據(jù)的處理流程如下：

(如上圖所示，左邊為多版本，右邊為UNDO派)

多版本派，會首先將ID為4的行復制到新位置，然后設置新行的事務號為1899，提交標志為N，代表事務未提交，再修改要Update的列值為“BBB”。如果其他Session查詢到ID為4的行，直接根據(jù)提交標記，即可判斷出此事務未提交，那么，就再向前查尋ID值為4、事務號最大的、提交標記為是的行，就是滿足一致性要求的行了。

UNDO派則先將前映像寫入UNDO區(qū)域，再在原行中修改要修改的列。這一派系我就不詳細介紹了，相信讀者對這一派系了解會更多。

通過對比，我想讀者朋友就發(fā)現(xiàn)了，如果表有十列，那怕只更新一列，多版本派也要將整行復制到新位置處。而UNDO派呢，只需要將被修改列的原值復制到UNDO日志中即可。這么一比，在Update操作方面，UNDO派是有優(yōu)勢的。

當然，作為圖靈獎得主，Michael老爺開創(chuàng)的多版本派肯定是有自己特長的。

各位多版本派的粉絲，先放下40米大刀，不要急，下面我們來比一下插入操作：

多版本派的Insert操作十分簡單，直接在表中插入新行即可。

相對來說，UNDO派的Insert，就略為復雜了。要將新行的位置信息寫入UNDO日志，將來回滾的時候，好根據(jù)這個位置找到新行在哪兒。

雖然UNDO派只復雜了那么一點點，但對于追求短、平、快的OLTP應用來說，一次SQL調用可能也就幾毫秒、十幾毫秒。額外的操作UNDO，已經(jīng)是不小的操作了。

看到了吧，Michael老爺子的多版本派成功扳回一局。

對于刪除操作，我就不再放圖了。UNDO派，要把原行整行數(shù)據(jù)復制到UNDO日志中去。多版本派對于刪除操作的處理多有不同。最基本、最簡單的，就是刪除時也把整行復制到新位置，加上刪除標志。

這符合多版本派的一貫思想，就是不修改原行，每DML一次，只復制、修改新行。

很多NoSQL數(shù)據(jù)庫就是這樣做的，但成熟的關系型、多版本派數(shù)據(jù)庫，如PostgreSQL，并不會這樣簡單粗爆。它是在原行處設置一些事務標志，在刪除行的時候，只需標記行被刪除就可以了，避免了將被刪除行復制到新位置。具體細節(jié)，我們就不再這里展開討論了?？傊甈ostgreSQL的刪除和插入一樣，都是十分節(jié)省資源的。

UNDO派脫胎于閉源的、商業(yè)的SYSTEM R，因此它廣范應用于關系的、閉源的、商業(yè)的數(shù)據(jù)庫。這個我們前面提到了，如Oracle、DB2、達夢，還有開源的MySQL。

多版本派，源于Ingres，這個數(shù)據(jù)庫是開源的，而且，多版派的實現(xiàn)也相對更為簡單，不需維護一塊專門的UNDO空間。因此多版本派也廣泛應用于開源的、或NoSQL/NewSQL等非關系型的數(shù)據(jù)庫。

雖然在關系型中，有名的好像也只有PostgreSQL。但是幾乎所有支持事務的NoSQL/NewSQL數(shù)據(jù)庫，都屬于多版本派。

好了，現(xiàn)在我們可以總結一下了。這兩大派的數(shù)據(jù)庫誰更適用哪種場景呢？

簡單總結一下

1、多版本派的Insert/Delete不需要復制原行數(shù)據(jù)，因此簡單而快速，但Update負擔會重，特別是針對列較多但每次Update只更新少量列的情況。

(注：多版本派的Delete不需要復制原行數(shù)據(jù)，只是針對PostgreSQL，多數(shù)多版本派的NoSQL/NewSQL，Delete時還是要復制原行數(shù)據(jù)到新位置的。)

2、UNDO派，它的優(yōu)勢在于平衡，無論什么DML，都少不了操作UNDO的步驟，性能表現(xiàn)都差不多。

結合應用來說，比如你有一個日志型的OLTP應用。每秒有大量的并發(fā)Session，向數(shù)據(jù)庫中插入大量數(shù)據(jù)(這和OLAP中少量Session插入大量數(shù)據(jù)還不樣，OLAP的我們以后再說)，但這些數(shù)據(jù)從不Update，或者說很少Update。那么，多版本派的數(shù)據(jù)庫就十分適合了，比如PostgreSQL。

如果對事務的要求沒那么高，那么一些NoSQL/NewSQL的數(shù)據(jù)庫也可以考慮。比如，事務不多的事情下，可以考慮MongoDB。因為完全的支持ACID的、跨多個表(MongoDB中叫集合)的事務，MongoDB也是剛支持不久，以成熟度來論，相比PostgreSQL會差一些。

如果不需要跨表、跨行的事務，甚至不需要事務，選擇面就更多了，像HBase、Cassandra等的插入性能都是不錯的。

如果有一個OLTP交易型的應用，有大量的查詢，和A轉帳給B這樣的交易操作，也就是Update A的余額、再Update B的余額。UNDO派的數(shù)據(jù)庫就比較適合了。畢竟，Update操作時UNDO派更節(jié)省資源。

但是，有時候應用的界限并不是那么清楚。比如一套大型的應用中，即有日志型的功能，又有交易型的功能，而且數(shù)據(jù)還是混在一起的。這種情況下，總不能將數(shù)據(jù)寫兩份，分別放在不同數(shù)據(jù)庫中吧(極端情況下，也可以這樣做)。

這要如何選擇呢?就要看那種功能更重要了。日志型功能更重要，就選多版本派的數(shù)據(jù)庫。交易型功能更重要，就選UNDO派數(shù)據(jù)庫。如果都重要，我建議優(yōu)選UNDO派的、成熟的數(shù)據(jù)庫。因為UNDO派各種操作性能更加平衡，不會出現(xiàn)忽快忽慢的情況。

要說，不同宗派之間，還容易選擇。但是同一宗派內部呢？

同一宗派內部，我們也不好在公開場合說誰優(yōu)誰劣，TPCC的性能測試數(shù)據(jù)，每家都十分優(yōu)秀。

大家使用的基本思想是一樣的，好壞取決于開發(fā)者的編程能力，能去開發(fā)數(shù)據(jù)庫的，都是好程序員。

所以，同一宗派內部，在不考慮錢的情況下，選擇成熟度高的數(shù)據(jù)庫。要考慮錢的情況下，國產(chǎn)的數(shù)據(jù)庫，和開源數(shù)據(jù)庫的確是一個不錯的選擇。現(xiàn)在國產(chǎn)數(shù)據(jù)庫、和像MySQL/PostgreSQL這樣的歷史悠久的開源數(shù)據(jù)庫，成熟度也已經(jīng)十分好了。

除去事務的影響，不同的數(shù)據(jù)存儲、組織模式、鎖級別等，都會帶來一些性能差別。比如：Oracle的表是堆表，堆表是無序的。MySQL InnoDB的表是索引組織表，索引組織表是要按索引排序的。排序操作會額外帶來一些性能損耗，但會提升按主鍵查詢時的性能，等等。這些非事務性的，我們后面再總結。

好了，篇幅已經(jīng)不短了，這一期，我們只說事務。后續(xù)，留待下一期吧。

話說UNDO派、多版派，就像少林、武當兩大派一樣，統(tǒng)領江湖幾十載，江湖上一片風平浪靜。各個應用廠商按需選擇，一時江湖上倒也相安無事。

進入二十一世紀一零年代，UNDO派開山宗師Jim某一日正在洞府中打坐修行，忽然一陣心旗搖動，Jim掐指一算，自知大限將至，遂揚帆出海，小舟從此逝、江海寄余生。

(注：2007年年初，Jim架游艇出海，將老母親骨灰撒入大海，然后失蹤。海岸警衛(wèi)隊、志愿者、學術界朋友紛紛加入搜索，甚至動用衛(wèi)星和若干先進技術，搜索幾天后仍一無所獲。但很多人仍沒有放棄搜索，直到五年又四個月后(2012年5月16)，才宣布他的死亡。)

多版本派開山宗師Michael，也年壽已高，不問江湖世事。江湖中兩位大佬一死一老，對江湖的控制力大大減弱。正在這時，一本叫做NoSQL的武功秘籍，在江湖上又掀起血雨腥風。

至于NoSQL重出江湖之后，數(shù)據(jù)庫界又有什么樣的風云變幻，且聽下回分解。

生成海報

免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產(chǎn)權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。