馬鵬瑋，魏凱，姜春宇

中國信息通信研究院云計算與大數(shù)據(jù)研究所，北京　100191

1　分布式事務處理系統(tǒng)發(fā)展背景

中國互聯(lián)網(wǎng)持續(xù)快速發(fā)展，帶來了當前信息的快速消費以及數(shù)據(jù)的快速增長，這種優(yōu)勢為中國創(chuàng)造了巨大的信息紅利。與此同時，指數(shù)級增長的互聯(lián)網(wǎng)業(yè)務量也為背后的信息支撐系統(tǒng)帶來了巨大的壓力與挑戰(zhàn)。以阿里巴巴淘寶網(wǎng)為例，2009—2017年“雙十一”交易額如圖1所示。

圖1　淘寶網(wǎng)“雙十一”交易額

巨大交易增長量的背后，后臺信息支撐系統(tǒng)除了直接面向用戶的電商網(wǎng)站系統(tǒng)外，相關(guān)的物流系統(tǒng)、支付系統(tǒng)、倉儲系統(tǒng)、訂單系統(tǒng)等也都接受了巨大的考驗。而上述各類信息系統(tǒng)的核心數(shù)據(jù)處理能力，幾乎均與數(shù)據(jù)處理系統(tǒng)的性能息息相關(guān)。

各類數(shù)據(jù)處理場景可以分為事務場景和非事務場景兩大類。事務場景即數(shù)據(jù)處理過程需要滿足原子性、一致性、隔離性、持久性（atomicity、consistency、isolation、durability，ACID）4個特性。典型的場景如銀行賬戶間轉(zhuǎn)賬、物流倉庫的運輸?shù)?。非事務場景對?shù)據(jù)處理過程沒有對ACID特性的嚴格要求。典型的場景有搜索展現(xiàn)場景、報表分析場景等。

因為事務場景具有ACID特性，所以相比于非事務場景，事務場景對底層數(shù)據(jù)處理系統(tǒng)提出了更高的技術(shù)要求。以銀行支付系統(tǒng)為例，目前核心的支付系統(tǒng)經(jīng)過幾十年的發(fā)展，形成了采用所謂的IOE（即IBM公司的大中型服務器、Oracle公司的數(shù)據(jù)庫軟件、EMC公司的存儲設備）結(jié)構(gòu)作為事務場景的支撐系統(tǒng)。這套系統(tǒng)結(jié)構(gòu)用于支撐銀行傳統(tǒng)的柜臺業(yè)務沒有大問題，但是隨著國內(nèi)移動互聯(lián)網(wǎng)以及電商業(yè)務的快速發(fā)展，其中存在的問題逐漸暴露。

（1）性能上限

傳統(tǒng)的IOE結(jié)構(gòu)為集中式系統(tǒng)，即所有的軟件系統(tǒng)都運行在一個性能十分強大的服務器上，例如IBM公司的AS 400、AS 390等。當業(yè)務壓力變大時，一般采用縱向擴展（scale up）方案，即繼續(xù)增加單臺服務器的性能上限。但是隨著摩爾定律逐漸失效，靠增大壓縮器件尺寸提高單臺服務器性能上限的方案已經(jīng)逐漸失效，縱向擴展路線即將走到盡頭。

（2）成本巨大

當業(yè)務量上升時，不僅硬件系統(tǒng)的規(guī)模需要呈指數(shù)級增長，同時軟件系統(tǒng)相應的服務費用也會隨之增長，中國銀行、中國農(nóng)業(yè)銀行、中國建設銀行、中國工商銀行每年相應的支出達到數(shù)億元，且仍在持續(xù)增長。

（3）嚴重捆綁

采用IOE結(jié)構(gòu)的公司，因為各環(huán)節(jié)信息系統(tǒng)供應商的壟斷化及單一化，會造成嚴重的服務提供商捆綁問題。傳統(tǒng)的IOE服務提供商會對相應功能實施生態(tài)封閉策略，造成服務消費方對其服務的嚴重依賴，這為未來埋下了嚴重的隱患。例如IBM公司近年來市場份額逐漸下降，未來方向尚不明確，如果將來IBM公司不再提供服務器的供應或維護，那當前相應的IOE體系服務消費方將會遭受嚴重打擊。

（4）非自主化產(chǎn)品

IOE體系均為國外的技術(shù)與產(chǎn)品，這方面需要進行自主化改造，從而掌握核心技術(shù)主動性。

（5）適應新業(yè)務環(huán)境

隨著業(yè)務產(chǎn)品的逐漸豐富，底層數(shù)據(jù)系統(tǒng)架構(gòu)需要增加擴展能力，從而適應多種業(yè)務類型的靈活性要求，而集中式架構(gòu)在這方面具有先天缺陷。

為解決以上各類問題，各大技術(shù)公司逐漸開始研發(fā)分布式事務數(shù)據(jù)系統(tǒng)技術(shù)，從而逐漸在事務場景中替代傳統(tǒng)的IOE結(jié)構(gòu)。

2　分布式事務數(shù)據(jù)處理系統(tǒng)優(yōu)勢及面臨的挑戰(zhàn)

分布式事務數(shù)據(jù)處理系統(tǒng)是利用高速通信網(wǎng)絡以及多臺服務器的分布化方式，解決數(shù)據(jù)處理事務場景的數(shù)據(jù)處理系統(tǒng)，其具有以下特性。

● 以橫向擴展路線代替縱向擴展路線。通過集群模式，將任務和數(shù)據(jù)分發(fā)到多臺服務器上，多臺服務器共同協(xié)作，通過增加橫向擴展服務器的數(shù)量達到提高單臺服務器性能上限的目的，從而解決性能上限問題。

● 使用廉價服務器及開源產(chǎn)品解決成本問題。分布式事務處理系統(tǒng)在底層不再采用成本巨大的超級服務器以及專有商業(yè)事務數(shù)據(jù)庫，而是采用多臺廉價的x86服務器以及開源的數(shù)據(jù)庫產(chǎn)品達到相應效果，預計單一企業(yè)在該方面的成本將從千萬級下降到百萬級。

● 多元化、開源化解決服務商捆綁問題。分布式事務處理系統(tǒng)可從硬件、軟件等多個環(huán)節(jié)對接業(yè)內(nèi)多種企業(yè)或開源產(chǎn)品。例如硬件支撐系統(tǒng)可以采用華為、浪潮、戴爾等多種x86服務器提供商提供的相應產(chǎn)品，軟件支撐系統(tǒng)可以采用MySQL、MariDB、PostgreSQL等多款開源數(shù)據(jù)庫產(chǎn)品，從而解決嚴重捆綁的問題。

● 國內(nèi)企業(yè)研發(fā)解決非自主可控問題。當前國內(nèi)涌現(xiàn)出多款自主研發(fā)分布式事務處理系統(tǒng)產(chǎn)品，例如阿里巴巴的OceanBase數(shù)據(jù)庫、騰訊的TDSQL數(shù)據(jù)庫、中興通訊的GoldenDB數(shù)據(jù)庫、PingCAP的TiDB數(shù)據(jù)庫等。這樣，可以通過國內(nèi)企業(yè)的創(chuàng)新力量解決非自主可控的問題。

理論上分布式事務數(shù)據(jù)處理系統(tǒng)橫向擴展路線可以達到數(shù)據(jù)處理能力上限。但是為了保證事務場景ACID特性，分布式事務數(shù)據(jù)處理系統(tǒng)無法達到其理論上限。深層次的原因為分布式事務數(shù)據(jù)處理系統(tǒng)在數(shù)據(jù)處理過程增加了網(wǎng)絡傳輸環(huán)節(jié)，而根據(jù)統(tǒng)計分析，數(shù)據(jù)在網(wǎng)絡中傳輸處理的速度大概為單機系統(tǒng)內(nèi)傳輸處理的千分之一，所以傳統(tǒng)事務數(shù)據(jù)處理系統(tǒng)中成熟的保證事務場景ACID的技術(shù)方案無法直接應用到分布式事務數(shù)據(jù)處理系統(tǒng)中。

為了研究如何使分布式事務數(shù)據(jù)處理系統(tǒng)保障事務場景ACID特性的問題，學術(shù)界提出：一致性、可用性、分區(qū)容錯性（consistency、 availability、partition tolerance，CAP）無法同時全部滿足，只能同時滿足兩個特性。通俗解釋為：為了滿足分區(qū)容錯性，數(shù)據(jù)庫系統(tǒng)中的數(shù)據(jù)需要同時保證多副本分散分布，而多副本分散分布會帶來無法保證各副本間數(shù)據(jù)一致性的問題，而嚴格保證各副本間數(shù)據(jù)一致性，又會導致數(shù)據(jù)庫系統(tǒng)性能下降。所以，CAP 3個特性無法同時得到滿足。

在分布式體系結(jié)構(gòu)中，分區(qū)現(xiàn)象是默認存在的，所以分區(qū)容錯性默認必須得到滿足。而事務特性要求一致性必須得到滿足，所以相應的分布式事務數(shù)據(jù)處理系統(tǒng)必須保證分區(qū)容錯性和數(shù)據(jù)一致性，酌情降低了系統(tǒng)可用性。

同時，分布式體系結(jié)構(gòu)存儲數(shù)據(jù)的方式相對于集中式存儲系統(tǒng)存儲數(shù)據(jù)的方式來說，增加了兩種新型的擴展形式。

第一種數(shù)據(jù)擴展形式為數(shù)據(jù)分區(qū)處理，即“大表變小表”。當一張表的容量達到上限或者出現(xiàn)業(yè)務交叉時，常進行水平拆分處理，即將一張表的數(shù)據(jù)拆分成幾張表共同存儲，各表分別放在不同的服務器上，從而針對不同小表訪問的業(yè)務可以分散到不同的服務器上，減少單點問題，提高可用性。

第二種數(shù)據(jù)擴展形式為數(shù)據(jù)鏡像處理，即“一份變多份”。一張表進行數(shù)據(jù)鏡像，從而形成內(nèi)容為同一份數(shù)據(jù)的多張表，但是從物理位置上看，卻分散在不同的服務器上。針對某一份數(shù)據(jù)的業(yè)務可以分散到這份數(shù)據(jù)其余的鏡像數(shù)據(jù)服務器上，從而提升服務性能。同時，當其中某臺服務器發(fā)生故障、無法提供服務時，它的數(shù)據(jù)鏡像所在的服務器仍然能夠提供服務，提升了分區(qū)容錯性。

新增的數(shù)據(jù)擴展形式在帶來優(yōu)點的同時，也為分布式事務性的保障提出了新的挑戰(zhàn)。

● 首先，針對數(shù)據(jù)分區(qū)擴展形式產(chǎn)生了分布式事務中的多機協(xié)作問題。當某個事務處理過程涉及多個分區(qū)的數(shù)據(jù)，而這多個分區(qū)的數(shù)據(jù)分散在不同的服務器上時，通過服務器之間的網(wǎng)絡通信，保證事務的ACID屬性成為挑戰(zhàn)。

● 其次，針對數(shù)據(jù)鏡像擴展形式產(chǎn)生了分布式事務中的數(shù)據(jù)同步問題。當某個事務針對某份數(shù)據(jù)進行更改操作時，利用服務器間網(wǎng)絡通信使這份數(shù)據(jù)的鏡像數(shù)據(jù)與之保持同步，從而維護數(shù)據(jù)鏡像的特點，使對外提供服務的鏡像數(shù)據(jù)與源數(shù)據(jù)之間不會出現(xiàn)數(shù)據(jù)不一致的現(xiàn)象，這是另一個挑戰(zhàn)。

3　分布式事務數(shù)據(jù)處理系統(tǒng)各類技術(shù)方案

數(shù)據(jù)分區(qū)擴展形式帶來的挑戰(zhàn)通常稱為分區(qū)一致性（consistency）問題，數(shù)據(jù)鏡像擴展形式帶來的挑戰(zhàn)通常稱為副本一致性（consensus）問題。

針對分區(qū)一致性問題，核心解決方案依然是沿襲傳統(tǒng)集中式數(shù)據(jù)庫系統(tǒng)的事務問題解決方案，即處理好事務過程中鎖與并發(fā)的控制問題。傳統(tǒng)集中式數(shù)據(jù)庫系統(tǒng)解決此問題的方式為兩階段鎖（2 phase lock，2PL）方案，即通過兩階段鎖控制本次事務涉及的資源，從而達到事務屬性。在分布式系統(tǒng)中，原有的2PL方案轉(zhuǎn)化為兩階段提交（2 phase commit，2PC）類方案，即通過分別向同一事務涉及的多臺服務器發(fā)送兩階段的提交要求，完成同步提交的效果。2PC方案根據(jù)各類事務隔離級別要求，后續(xù)又被改進為3PC、2+XPC、異步消息隊列、TCC（try confirm cancel）方案等。目前各類應用都是針對不同的實際業(yè)務場景，抽象出業(yè)務的實際隔離級別需求，然后在上述各種方案中選擇合適的分區(qū)一致性解決方案。

副本一致性的核心問題為分布式系統(tǒng)中的數(shù)據(jù)復制問題。由于分布式系統(tǒng)增加了網(wǎng)絡傳輸?shù)难舆t性和不確定性，一致性方案主要分為服務器邏輯架構(gòu)設計解決方案和數(shù)據(jù)自組織解決方案。常見服務器邏輯架構(gòu)解決方案設定為主從模式或者主主模式，通過掐斷數(shù)據(jù)復制過程中從服務器的數(shù)據(jù)輸出能力，達到副本一致性的目的。常見的數(shù)據(jù)及組織解決方案為Paxos、Raft、Zab等一致性算法協(xié)議，通過自由選舉、過半投票確認、分區(qū)容錯的解決方式自組織解決副本一致性問題。

業(yè)內(nèi)為了綜合解決上述兩個問題，從各個方向逐漸發(fā)展出了3種相應的架構(gòu)方案。

第一種架構(gòu)方案為中間件方案，其架構(gòu)示意如圖2所示。

圖2　Cobar中間件方案架構(gòu)

整個分布式事務數(shù)據(jù)處理系統(tǒng)架構(gòu)分為3層，最上層為應用層，第二層為中間件層，第三層為數(shù)據(jù)庫實例層。其中，底層數(shù)據(jù)庫實例層常采用開源的集中式數(shù)據(jù)庫，負責本實例上的數(shù)據(jù)存儲與處理；中間件層負責手動數(shù)據(jù)分區(qū)之后的分區(qū)信息維護、上層應用下發(fā)的SQL語句分布式解析下發(fā)、分布式事務的統(tǒng)一執(zhí)行控制等，從而實現(xiàn)數(shù)據(jù)分區(qū)與分布式事務的實現(xiàn)。

第二種架構(gòu)方案為共享存儲方案，其架構(gòu)示意如圖3所示。

圖3　Oracle RAC共享存儲方案架構(gòu)

整個分布式事務數(shù)據(jù)處理系統(tǒng)架構(gòu)分為3層，最上層為應用層，第二層為數(shù)據(jù)庫計算實例層，第三層為共享存儲層。數(shù)據(jù)庫計算實例層通過分布式擴展，保證集群的計算性能，增強可用性。同時共享存儲層采用新型存儲硬件結(jié)構(gòu)，保證高速I/O性能的同時，避免了存儲層數(shù)據(jù)網(wǎng)絡通信的環(huán)節(jié)，通過改進一定量傳統(tǒng)的集中式數(shù)據(jù)庫系統(tǒng)的事務解決方案，保障了共享存儲架構(gòu)中的分布式事務能力。但是由于統(tǒng)一式存儲帶來的并發(fā)和I/O能力的理論極限，集群規(guī)模無法做到大規(guī)模擴展。業(yè)內(nèi)實踐案例表明，當此類解決方案集群數(shù)量達到百臺規(guī)模時，性能將會出現(xiàn)比較大的下滑。

第三種架構(gòu)方案為計算存儲均分布式擴展方案，其架構(gòu)示意如圖4所示。

整個分布式事務數(shù)據(jù)處理系統(tǒng)架構(gòu)分為3層，最上層為應用層，第二層為分布式計算層，第三層為分布式存儲層。分布式計算層與共享存儲方案的數(shù)據(jù)庫計算實例層相似，均通過分布式擴展能力保證集群的計算性能，增強可用性。而分布式存儲層采用零共享（shared nothing）架構(gòu)，同時大部分產(chǎn)品具備自動化分區(qū)功能，不需要人為定義分區(qū)模式，各個存儲節(jié)點之間通過高速互聯(lián)網(wǎng)絡進行通信，通過一致性算法即多版本并發(fā)控制（multi-version concurrency control，MVCC）保障數(shù)據(jù)執(zhí)行過程中的集群狀態(tài)正確性以及事務的ACID屬性。但是當存儲層分布式化之后，事務設計不同節(jié)點通信時，由于網(wǎng)絡時延問題，與統(tǒng)一存儲相比，事務整體執(zhí)行過程的時延勢必有一定比例的增加。

圖4　計算存儲均分布式擴展方案架構(gòu)

最后根據(jù)新數(shù)據(jù)時代下對數(shù)據(jù)庫的功能需求，本文簡單從幾個維度對上述3類數(shù)據(jù)庫方案進行粗略的對比和總結(jié)，對比結(jié)果見表1。

表1　3類數(shù)據(jù)庫方案對比

4　分布式事務數(shù)據(jù)處理系統(tǒng)應用注意事項

分布式事務數(shù)據(jù)處理系統(tǒng)相比于集中式數(shù)據(jù)處理系統(tǒng)具有一系列優(yōu)點，但是在成功應用之前，仍然需要注意幾點問題。

（1）正確認識自身業(yè)務需求

分布式系統(tǒng)中的CAP決定了強一致性、高可用性、分區(qū)容錯性三者不能同時實現(xiàn)。正確地認識自身業(yè)務需求，明確當前業(yè)務在上述3種特性中的重點，才能切合實際地對后續(xù)分布式事務數(shù)據(jù)處理系統(tǒng)功能做出取舍。而正確認識業(yè)務主要是服務規(guī)模和服務質(zhì)量兩方面。例如，對于金融行業(yè)中的核心業(yè)務，服務質(zhì)量是必須滿足的，所以必須要保證強一致性，從而弱化高可用性。而對于互聯(lián)網(wǎng)系統(tǒng)中的查詢業(yè)務，服務規(guī)模是主要需求，所以高可用性必須保障，而一致性可以相應地進行弱化。

（2）明確分布式事務數(shù)據(jù)處理系統(tǒng)各產(chǎn)品特點及適用場景

分布式事務數(shù)據(jù)處理系統(tǒng)因為底層技術(shù)路線不同，所以上層適用場景也不盡相同。例如，部分分布式事務數(shù)據(jù)處理系統(tǒng)需要在管理節(jié)點數(shù)量大于某個數(shù)量時，才能發(fā)揮較優(yōu)性能，這就對應用方集群規(guī)模做出了限制；部分分布式事務數(shù)據(jù)處理系統(tǒng)需要使用特殊的硬件作為存儲或計算介質(zhì)，從而達到較優(yōu)性能，這就對應用方硬件環(huán)境做出了限制。其他的類似區(qū)別指標有是否需要人工參與數(shù)據(jù)分區(qū)、適用的服務規(guī)模范圍、是否具備多中心容災能力、是否能夠提供多種事務隔離級別等。

（3）正確規(guī)劃已有IT架構(gòu)向分布式體系遷移的路徑及策略

目前現(xiàn)有數(shù)據(jù)庫系統(tǒng)以集中式架構(gòu)為主，且當前實際業(yè)務和第三方應用大部分也是基于集中式數(shù)據(jù)庫結(jié)構(gòu)實現(xiàn)的。如何在數(shù)據(jù)庫架構(gòu)從集中式向分布式轉(zhuǎn)移過程中，保證上層業(yè)務的正常服務能力以及盡量少的原有業(yè)務體系變動，是需要格外注意的問題。為達到此目的，首先需要對轉(zhuǎn)型后系統(tǒng)與原系統(tǒng)的兼容能力做一個充分評估，其次需要合理規(guī)劃轉(zhuǎn)型過程中存量業(yè)務和增量業(yè)務的關(guān)系，最后需要在新型系統(tǒng)正式上線前進行充分驗證，做好原有系統(tǒng)災備的充足準備。

（4）驗證分布式事務數(shù)據(jù)處理系統(tǒng)產(chǎn)品能力

在正式遷移應用之前，需要正確篩選符合要求的分布式事務數(shù)據(jù)處理系統(tǒng)產(chǎn)品，同時驗證各類分布式事務數(shù)據(jù)處理系統(tǒng)產(chǎn)品能力范圍。筆者所在單位于2017年7月開始分布式事務數(shù)據(jù)處理系統(tǒng)標準化的嘗試，梳理出分布式事務數(shù)據(jù)處理系統(tǒng)基準測試的方法論和具體實施方法?；鶞蕼y試主要包括功能和性能兩大方向，指標項包括兼容能力、透明能力、管理能力、分布式能力、事務能力、安全能力、高可用能力、場景化性能指標等多個維度，從而全面衡量分布式事務數(shù)據(jù)處理系統(tǒng)產(chǎn)品能力。

5　分布式事務數(shù)據(jù)處理系統(tǒng)未來趨勢

近幾年，以Google Spanner為代表的NewSQL類數(shù)據(jù)庫發(fā)展迅速，其以全球范圍內(nèi)的擴展性、強事務支持能力、靈活的應用形式、廉價的軟硬件成本等特點，逐漸成為數(shù)據(jù)庫的最新演進形態(tài)，而這也是當前信息社會環(huán)境下的必然結(jié)果。究其原因，數(shù)據(jù)庫的最初需求就是高性價比地實現(xiàn)數(shù)據(jù)的管理工作。首先高性價比可以從經(jīng)濟成本和業(yè)務成本兩方面衡量，NewSQL類數(shù)據(jù)庫實現(xiàn)了基于x86等廉價服務器搭建，并在底層實現(xiàn)數(shù)據(jù)自動化均衡處理，對業(yè)務侵入性不高，不需要應用過多感知，同時節(jié)約了經(jīng)濟成本和業(yè)務成本。其次，數(shù)據(jù)的管理工作分為存儲和處理兩方面。在大數(shù)據(jù)時代，數(shù)據(jù)的基本特征為數(shù)量大、類型多、價值密度低、速度快、時效高，所以對數(shù)據(jù)處理的需求為擴展性強、數(shù)據(jù)兼容能力強、具備分析能力、處理能力強，而NewSQL類數(shù)據(jù)庫具備聯(lián)機分析處理（online analytical processing，OLAP）/聯(lián)機事務處理過程（on-line transaction processing，OLTP）混合能力、存儲與計算強擴展性、兼容結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)等多個特點，切合了當前時代數(shù)據(jù)管理功能需求。

隨著大數(shù)據(jù)、物聯(lián)網(wǎng)、人工智能等應用的快速興起，分布式架構(gòu)取代集中式架構(gòu)是大勢所趨，未來分布式事務數(shù)據(jù)處理系統(tǒng)將會作為數(shù)據(jù)時代的技術(shù)結(jié)構(gòu)，為未來技術(shù)浪潮的發(fā)展提供更多的數(shù)據(jù)基礎能力，未來分布式事務數(shù)據(jù)處理系統(tǒng)將在幾個方面繼續(xù)延伸變化。

首先，分布式事務數(shù)據(jù)處理系統(tǒng)的功能形態(tài)將會更加豐富。隨著大數(shù)據(jù)和人工智能產(chǎn)業(yè)的發(fā)展，各數(shù)據(jù)應用企業(yè)都利用自身快速增長的業(yè)務數(shù)據(jù)，擴展出核心業(yè)務能力之外的數(shù)據(jù)分析能力，這就需要底層數(shù)據(jù)處理過程除了滿足事務型邏輯之外，分析功能需求占到越來越多的比例。數(shù)據(jù)庫作為數(shù)據(jù)底層服務設施，保障上層業(yè)務事務特性的同時提供高可用的分析能力是未來的發(fā)展趨勢。目前已有將底層存儲結(jié)構(gòu)對接上層兩套邏輯系統(tǒng)，完成上述功能的實例。未來如何平衡事務和分析兩種業(yè)務的支撐占比以及相應技術(shù)實現(xiàn)方式，仍然需要繼續(xù)探索與實踐。

其次，新型硬件之下的分布式事務數(shù)據(jù)處理系統(tǒng)形態(tài)得到發(fā)展。底層存儲與計算硬件（如3D內(nèi)存、Flash卡、硬件壓縮卡、非易失性存儲器等）的快速發(fā)展，是原有數(shù)據(jù)庫系統(tǒng)發(fā)展過程未曾預想到的。當前數(shù)據(jù)庫系統(tǒng)的底層讀寫模式仍是以原有磁盤存儲介質(zhì)特點進行設計并發(fā)展起來的，例如事務日志刷盤模式、緩沖區(qū)大小計算方法、I/O與網(wǎng)絡的性能瓶頸評估等，這些傳統(tǒng)設計方法造成了新型硬件介質(zhì)的優(yōu)勢特點無法被現(xiàn)有數(shù)據(jù)庫系統(tǒng)充分應用。未來的分布式事務數(shù)據(jù)處理系統(tǒng)需要針對新型硬件特性進行相關(guān)研發(fā)，從而突破傳統(tǒng)數(shù)據(jù)庫的思維及認知局限。

最后，利用協(xié)調(diào)硬件突破軟件困境。例如因為物理時鐘難以同步，所以傳統(tǒng)事務數(shù)據(jù)庫通常采用邏輯時鐘維護事務順序，但是邏輯時鐘的維護會限制數(shù)據(jù)庫的規(guī)模大小，所以覆蓋全球范圍的事務數(shù)據(jù)庫幾乎不可能實現(xiàn)。而Google公司推出的Spanner數(shù)據(jù)庫直接采用硬件GPS加上原子鐘方案，解決了物理時鐘同步問題，做到了全球范圍的數(shù)據(jù)庫事務一致性。預計未來將會出現(xiàn)更多協(xié)調(diào)硬件輔助數(shù)據(jù)庫軟件系統(tǒng)解決之前無法解決的問題。

6　結(jié)束語

IT架構(gòu)作為企業(yè)架構(gòu)的基礎，支撐著上層業(yè)務架構(gòu)的建設與發(fā)展，促進了頂層愿景和戰(zhàn)略的順利實施。而傳統(tǒng)集中式事務數(shù)據(jù)處理系統(tǒng)面對新環(huán)境下OLTP業(yè)務的迅速增長，相關(guān)問題逐漸暴露，故需要完成集中式體系向分布式體系的轉(zhuǎn)型，從而釋放數(shù)據(jù)紅利，充分發(fā)展數(shù)字經(jīng)濟。而當前分布式事務數(shù)據(jù)處理系統(tǒng)正處于快速創(chuàng)新發(fā)展時期，多種體系架構(gòu)并存，在擴展性、性能、可用性等方面優(yōu)于傳統(tǒng)集中式數(shù)據(jù)處理系統(tǒng)，但穩(wěn)定性、服務能力等方面仍與傳統(tǒng)集中式數(shù)據(jù)處理系統(tǒng)存在差距。故在轉(zhuǎn)型過程中，應用方需要充分掌握相關(guān)技術(shù)特點、應用方法、實現(xiàn)方式等知識體系，從而實現(xiàn)快速、平穩(wěn)的轉(zhuǎn)型進程。

參考文獻：

[1]CORBETT J C, DEAN J, EPSTEIN M, et al.Spanner: Google's globally-distributed database[C]//USENIX Conference on Operating Systems Design and Implementation, October 8-10, 2012,Hollywood, USA. Berkeley: USENIX Association, 2012: 251-264.

[2]CHEUNG D W, NG V T, FU A W,et al. Efficient mining of association rules in distributed databases[J]. IEEE Transactions on Knowledge & Data Engineering, 1996, 8(6): 911-922.

[3]?ZSU M T, VALDURIEZ P. Principles of distributed database systems[M]. Berlin:Springer, 1999, 24(1): 31-41.

[4]BERNSTEIN P A. Concurrency control in distributed database systems[J]. ACM Computing Surveys, 1989, 13(2): 185-221.

[5]PAIVA J, RUIVO P, Romano P, et al.AutoPlacer: scalable self-tuning data placement in distributed key-value stores[J].ACM Transactions on Autonomous &Adaptive Systems, 2014, 9(4):19.

[6]KUMAR R, GUPTA N, CHARU S, et al.Manage big data through NewSQL[C]//National Conference on Innovation in Wireless Communication and Networking Technology,April 6-9, 2014, Istanbul, Turkey.Piscataway: IEEE Press, 2014: 1-6.

[7]KUMAR R, PARASHAR B B, GUPTA S, et al.Apache Hadoop, NoSQL and NewSQL solutions of big data[J]. International Journal of Advance Foundation and Research in Science & Engineering, 2014,1(6): 28-36.

[8]ARDEKANI M S, TERRY D B. A selfconfigurable geo-replicated cloud storage system[C]//USENIX Conference on Operating Systems Design and Implementation, October 6-8, 2014,Broomfield, USA. Berkeley: USENIX Association, 2015: 367-381.

[9]LING G U, WENG H X, HUA-LIANG H U,et al. OceanBase schema design for OLAP application[J]. Journal of East China Normal University, 2014(5): 301-310.

[10]RAMANATHAN S, GOEL S,ALAGUMALAI S. Comparison of cloud database: Amazon's simpleDB and Google's bigtable[C]// International Conference on Recent Trends in Information Systems,June 3-5, 2011, Chennai, India.

[11]SUKHWANI B, MIN H, THOENNES M,et al. Database analytics acceleration using FPGAs[C]// International Conference on Parallel Architectures and Compilation Techniques, September 9-13, 2017,Portland, USA. Piscataway: IEEE Press,2017: 411-420.

[12]ABBAS Q, SHAFIQ H, AHMAD I, et al.Concurrency control in distributed database system[C]// International Conference on Computer Communication and Informatics, January 7-9, 2016,Coimbatore, India. Piscataway: IEEE Press, 2016: 1-4.