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

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

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

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

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

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

要知道2015年時(shí)，MongoDB才剛剛支持一個(gè)Document內(nèi)的事務(wù)。簡單點(diǎn)說，還不支持跨行事務(wù)。如果你輕信了這樣的新聞，貿(mào)然將需要跨行的、復(fù)雜事務(wù)的應(yīng)用，建立在了MongoDB之上，你可以去準(zhǔn)備你的簡歷了。

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

它之所以比MongoDB更快，是因?yàn)樗臄?shù)據(jù)都是在內(nèi)存中。如果MongoDB的內(nèi)存也很大，所有數(shù)據(jù)也都緩存在內(nèi)存中，誰更快還不好說。

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

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

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

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

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

事務(wù)對(duì)OLAP型應(yīng)用來說的確是可有可無，但對(duì)OLTP來說，絕對(duì)是必須的。

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

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

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

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

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

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

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

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

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

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

你看，問題的范圍大大縮小了。這就是頂級(jí)架構(gòu)師的思維。

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

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

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

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

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

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

圖片來源：《事務(wù)處理：概念與技術(shù)》

搞過Oracle、DB2、SQLServer的人一看這圖，一定就能心領(lǐng)神會(huì)。

我摘錄一下書中對(duì)此圖的解釋：

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

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

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

這個(gè)圖其實(shí)和DB2、SQLServer中的事務(wù)機(jī)制完全一樣，他們的UNDO日志和REDO日志就是合在一起的。比如：在SQLServer中就叫事務(wù)日志，回滾、恢復(fù)都靠事務(wù)日志。

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

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

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

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

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

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

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

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

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

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

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

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

但數(shù)據(jù)庫的江湖上，除了DO-UNDO-REDO派之外，還有另外一大流派。因?yàn)槭褂昧送耆煌氖聞?wù)實(shí)現(xiàn)協(xié)議，有些操作的性能表現(xiàn)和DO-UNDO-REDO派有著明顯的差異。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

相對(duì)來說，UNDO派的Insert，就略為復(fù)雜了。要將新行的位置信息寫入U(xiǎn)NDO日志，將來回滾的時(shí)候，好根據(jù)這個(gè)位置找到新行在哪兒。

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

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

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

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

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

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

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

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

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

簡單總結(jié)一下

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

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

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

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

如果對(duì)事務(wù)的要求沒那么高，那么一些NoSQL/NewSQL的數(shù)據(jù)庫也可以考慮。比如，事務(wù)不多的事情下，可以考慮MongoDB。因?yàn)橥耆闹С諥CID的、跨多個(gè)表(MongoDB中叫集合)的事務(wù)，MongoDB也是剛支持不久，以成熟度來論，相比PostgreSQL會(huì)差一些。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

生成海報(bào)

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