國產(chǎn)數(shù)據(jù)庫的熱點技術(shù)問題解讀

國產(chǎn)數(shù)據(jù)庫的熱點技術(shù)問題解讀

【導讀】近些年來，國產(chǎn)數(shù)據(jù)庫成為較熱門的話題，有越來越多的企業(yè)考慮采用國產(chǎn)數(shù)據(jù)庫產(chǎn)品。本文作者在twt社區(qū)互動中，發(fā)現(xiàn)有大量相關(guān)的討論，作者將參與探討的部分問題的個人分享匯編如下，希望針對這些熱點問題的觀點和經(jīng)驗?zāi)軌驗閺V大同行提供參考。1、如何結(jié)合不同的業(yè)務(wù)場景選擇合適的數(shù)據(jù)庫？在做出合適選擇之前，需要以下準備工作：1.業(yè)務(wù)畫像針對不同的業(yè)務(wù)，做出業(yè)務(wù)側(cè)的數(shù)據(jù)庫畫像，包括但不限于如下維度：業(yè)務(wù)指標：使用方式、使用特征（在線用戶、峰值用戶、并發(fā)用戶等）、重要級別、可用性要求。此外，針對未來發(fā)展也要有所評估。系統(tǒng)指標：包括應(yīng)用系統(tǒng)來源、技術(shù)棧、開發(fā)語言、系統(tǒng)拓撲、與數(shù)據(jù)庫交互方式等數(shù)據(jù)庫指標：包括數(shù)據(jù)規(guī)模、訪問特征、物理環(huán)境、軟件環(huán)境、數(shù)據(jù)庫拓撲等運行特征：場景分類（TP、AP、混合）、架構(gòu)分類、數(shù)據(jù)規(guī)模、數(shù)據(jù)特征、計算規(guī)模、事務(wù)一致性要求、擴展性要求、高可用要求、應(yīng)用耦合性等2.產(chǎn)品測試對數(shù)據(jù)庫產(chǎn)品進行測試，形成對產(chǎn)品的統(tǒng)一認識。這其中包括數(shù)據(jù)庫內(nèi)核、管理、開發(fā)、安全等多方面能力的評估。這方面可參考我之前分享的《分布式數(shù)據(jù)庫評測標準》。3.其他因素除上述外，還應(yīng)包括企業(yè)內(nèi)部的一些自身因素的考慮，如成本、運維、開發(fā)改造等因素。上述因素綜合考慮后，才能做出相對合理的選擇。2、業(yè)務(wù)系統(tǒng)應(yīng)用架構(gòu)設(shè)計時如何適配分布式數(shù)據(jù)庫以實現(xiàn)高性能，在線擴展后性能如何同步提升？性能問題，是需要慎重考慮的。如果僅僅考察個體的表現(xiàn)，分布式數(shù)據(jù)庫很有可能不如傳統(tǒng)單機數(shù)據(jù)庫或集中式數(shù)據(jù)庫。其分布式架構(gòu)在原理就先天存在一些短板，對于要求極致性能的場景是不合適的。分布式數(shù)據(jù)庫的強處，是在于擴展系統(tǒng)的整體吞吐能力，可承載更多的業(yè)務(wù)量。因此從原理上講，擴展后不會提升性能。當然，分布式系統(tǒng)擴展后，數(shù)據(jù)庫被做個更多的拆分，會有助于單體執(zhí)行效率的提升，這種情況下是有性能提升的。基于上面，在應(yīng)用架構(gòu)設(shè)計時，應(yīng)充分利用分布式數(shù)據(jù)庫的數(shù)據(jù)分布特點，做好業(yè)務(wù)單元化。通過在更小的數(shù)據(jù)單元完成，進而達到優(yōu)化效果。3、分布式數(shù)據(jù)庫故障時如何確保故障自動轉(zhuǎn)移，自動恢復業(yè)務(wù)，實現(xiàn)高可用？分布式庫的組件較多，大致可分為數(shù)據(jù)節(jié)點、計算節(jié)點、控制節(jié)點三類角色。其中，計算節(jié)點一般為無狀態(tài)的，故障后可切換自動恢復；控制節(jié)點一般采用自身高可用保障，出現(xiàn)問題會主動自愈；數(shù)據(jù)節(jié)點出現(xiàn)問題時較為重要，因為其上面承載的數(shù)據(jù)。我理解問題主要是對應(yīng)這一角色。針對數(shù)據(jù)節(jié)點，不同分布式數(shù)據(jù)庫產(chǎn)品，底層實現(xiàn)有所差異，大致可分為兩種情況：1.基于單機數(shù)據(jù)庫的主從復制模式2.基于多數(shù)派協(xié)議保證的多副本模式無論是哪種模式，當出現(xiàn)故障時都會完成自動選主，自動切換，從而實現(xiàn)高可用。目前的大部分產(chǎn)品，都已可實現(xiàn)在同AZ、同城跨AZ的自主切換、對業(yè)務(wù)無感（業(yè)務(wù)需實現(xiàn)出錯重試機制）。針對異地的情況，一般還是建議人工介入，而不自動完成切換。4、分布式數(shù)據(jù)庫全局一致性和高性能如何取舍達到平衡？個人覺得這兩者不存在平衡關(guān)系，一般一致性要求是來源于業(yè)務(wù)，很難去做業(yè)務(wù)上的取舍。都是在有明確一致性要求的情況下，盡量做到性能最好。5、中小銀行后端穩(wěn)態(tài)類系統(tǒng)進行分布式方向改造的必要性？分布式改造的必要性，主要來自于幾個方面：業(yè)務(wù)驅(qū)動（數(shù)據(jù)規(guī)模、算力不足等需要擴展）政策驅(qū)動（監(jiān)管方明確需求）技術(shù)驅(qū)動（為適配技術(shù)棧革新）管理驅(qū)動（從統(tǒng)一管理等角度考慮）這里需權(quán)衡分布式改造所帶來的投入產(chǎn)出比及對應(yīng)的風險評估。個人建議，中小型銀行的穩(wěn)態(tài)業(yè)務(wù)，不一定非要做分布式改造，需要做更嚴謹?shù)脑u估。6、是否有適合銀行業(yè)務(wù)場景的OLTP基準測試？目前沒有統(tǒng)一的OLTP測試標準，其原因是銀行的業(yè)務(wù)也各有不同，很難找到統(tǒng)一標準。一般的做法是找出部分有代表性的業(yè)務(wù)，簡化提煉后形成一個測試case。在測試中，通過不同測試case的組合，形成滿足某業(yè)務(wù)的測試集。7、關(guān)于國產(chǎn)分布式數(shù)據(jù)庫未來趨勢分析？目前尚處于早期階段，趨勢發(fā)展上還不是很明朗。個人有以下一些判斷：1.多技術(shù)路線會長期共存；2.云會在未來達到統(tǒng)一，但周期會很長；3.MySQL、PG會成為事實生態(tài)標準，各產(chǎn)品會加以適配。8、面對這么多國產(chǎn)分布式數(shù)據(jù)庫，如何制定一個選型標準？關(guān)于選型標準，目前沒有統(tǒng)一國家、行業(yè)標準，有條件的企業(yè)都在做自有標準。按照之前的工作，需梳理出選型測試的眾多評估維度及細化的指標。這里是存在不小的工作量。這里可參考我近期發(fā)的一些內(nèi)容：

分布式數(shù)據(jù)庫評估維度分析。9、在分布式數(shù)據(jù)庫架構(gòu)選型中，如何看待計算與存儲分離？存算分離，還是要看具體解決的問題。其最早是由云廠商提出的，目的是將資源解耦，從而實現(xiàn)不同資源的分層擴縮?？创@個特性，還是要看其背后帶來的收益，是否是自身關(guān)注的；否則沒有太大意義。10、分布式數(shù)據(jù)庫容災(zāi)容錯方案？高可用方案，各家產(chǎn)品實現(xiàn)有所差異。一般情況下，在同城雙中心異地單中心的情況下，當同城某AZ出現(xiàn)問題時，是無法自動切換到同城第二個AZ，是需要引入第三個AZ，滿足仲裁需求的。當然有些是可以寫死切換邏輯在里面，但非標準的切換流程。因此，一般建議在同城采用3AZ，滿足多數(shù)派選舉，可實現(xiàn)自動切換能力。異地一般不建議參與其中，畢竟存在較長時延。11、分布式數(shù)據(jù)庫使用規(guī)則？分布式數(shù)據(jù)庫較傳統(tǒng)單機數(shù)據(jù)庫或集中式數(shù)據(jù)庫，是存在較多不同，因此在開發(fā)之處就有針對性的進行規(guī)避比較重要。這其中常見的點包括：事務(wù)大小、SQL復雜度、分布式事務(wù)、DDL變更等?；镜奶幚碓瓌t就是3B原則，即避免BigSQL、BigTransaction、BigBatch。此外，盡量減小分布式數(shù)據(jù)庫中的變更，無論是架構(gòu)上的（如擴縮容）、結(jié)構(gòu)上的（如DDL）等。12、分布式數(shù)據(jù)庫如何選型？通常不會根據(jù)每套應(yīng)用來選擇合適的數(shù)據(jù)庫，這樣做的話技術(shù)?？赡苓^于發(fā)散。建議的做法是，根據(jù)公司業(yè)務(wù)場景，收斂為若干種類型，然后為每個類型選擇2~3款產(chǎn)品。選擇多款產(chǎn)品的原因，是為了避免廠商綁定問題。然后需要根據(jù)每類場景，制定開發(fā)規(guī)范（取2~3款產(chǎn)品的功能交集作為標準）。13、有成熟的國產(chǎn)數(shù)據(jù)庫產(chǎn)品替代Oracle、Db2數(shù)據(jù)產(chǎn)品嗎？替代Oracle或DB2的產(chǎn)品，可分為幾種類型：1.核心業(yè)務(wù)此類業(yè)務(wù)特點是數(shù)據(jù)規(guī)模大、并發(fā)高、延遲要求低，但數(shù)據(jù)庫使用場景較為簡單。通常這種方式可使用業(yè)務(wù)側(cè)單元化+國產(chǎn)庫方式。這種方式對庫的要求相對不高，可選擇的范圍較廣。2.中型業(yè)務(wù)此類業(yè)務(wù)特點是數(shù)據(jù)規(guī)模中等，數(shù)據(jù)庫使用復雜度。這種方式要想很好地替代，相對較難。一般建議的做法是重構(gòu)。當然這里需要考慮的改造成本比較高。可考慮的選型范圍是NewSQL系列產(chǎn)品。3.小型業(yè)務(wù)此類業(yè)務(wù)特點是數(shù)據(jù)規(guī)模較小，復雜度不低。這種系統(tǒng)數(shù)量眾多，可考慮是使用對Oracle/DB2兼容性較高的產(chǎn)品。如很多從PG衍生的產(chǎn)品或國內(nèi)部分數(shù)據(jù)庫產(chǎn)品。14、國產(chǎn)數(shù)據(jù)庫如何實現(xiàn)在正式庫中進行測試？庫內(nèi)測試的問題，一般不是通過數(shù)據(jù)庫端實現(xiàn)的，可通過互聯(lián)網(wǎng)通常采用的影子庫方案來解決。也有一些開源產(chǎn)品（如shardingsphere），內(nèi)置了這一能力，通過在上層模擬出數(shù)據(jù)庫的統(tǒng)一入口，內(nèi)部設(shè)置分流、限流策略，來完成壓測工作。15、國產(chǎn)分布式數(shù)據(jù)庫，在成本上是否如宣傳的那樣比Oracle有較大的優(yōu)勢？采用分布式數(shù)據(jù)庫的成本來自幾個方面：軟件授權(quán)費用：這部分相對有一定優(yōu)勢，Oracle原廠費用較高。軟件服務(wù)費用：這部分相對國產(chǎn)庫較高，因為成熟度不足，還需大量人力投入且還未形成成熟的服務(wù)生態(tài)硬件采購費用：這部分分布式國產(chǎn)庫較高，因為涉及的組件較多，需耗費機器資源較多。日常維護費用：這部分國產(chǎn)庫較高，因需重新搭建隊伍，新增人力成本較高。16、NewSQL分布式數(shù)據(jù)庫有哪些缺陷？主要缺陷取決于不同庫的架構(gòu)，這點差異很大。重點可考察：分布式事務(wù)、全局一致性全局日志，數(shù)據(jù)唯一性同城&異地高可用生態(tài)功能（如針對研發(fā)）管控能力（管理、優(yōu)化、監(jiān)控等）17、國產(chǎn)數(shù)據(jù)庫去O，是用基于PG產(chǎn)品，還是考慮基于MySQL產(chǎn)品合適？在去O過程中，我們先明確一點，沒有數(shù)據(jù)庫產(chǎn)品是可以完全替代的。即完成去O工作，是需要通過“應(yīng)用改造+數(shù)據(jù)庫選型+應(yīng)用遷移”，結(jié)合在一起才能完成。這里需要考慮整體目標及路徑。問題中的兩種方式，原則上都是可以完成去O工作，但對于應(yīng)用改造及遷移的影響差異較大。PG類產(chǎn)品，其企業(yè)級功能較為完善，使用體感與Oracle相近。有些基于PG為內(nèi)核的產(chǎn)品，在Oracle兼容性上做了了大量工作。對用戶來說，使用上與Oracle更為相近，甚至大部分可以做到無縫遷移；少部分需要修改上，也相對工作量不大。MySQL類產(chǎn)品，流行程度更高，但與Oracle相比，功能差異較多。如在去O中選用，需做較大的修改。18、數(shù)據(jù)遷移如何保證前后一致性？數(shù)據(jù)遷移后，前后環(huán)境處于靜態(tài)切面，做數(shù)據(jù)對比是比較簡單的。操作上可有幾種方式：自研-數(shù)據(jù)可通過SQL語句完成簡單的數(shù)據(jù)對比，如記錄條目數(shù)，多維度統(tǒng)計報告進行比對。自研-過程可針對遷移過程中的日志的方式，通過代碼提取對比。這種方式對目標庫無影響。外部工具有些外部產(chǎn)品也支持數(shù)據(jù)比對，如DSG的supersync等問題：數(shù)據(jù)比對的核心問題是效率，需找到一種平衡。19、目前國產(chǎn)化分布式數(shù)據(jù)庫產(chǎn)品繁多，對OLTP數(shù)據(jù)庫在去O轉(zhuǎn)向國產(chǎn)化該如何做選型評估？可分為幾種情況：兼容性評估這與去O的路線有關(guān)，如考慮盡量減少去O的應(yīng)用遷移難度，選擇兼容Oracle的產(chǎn)品，則兼容性需要重點評估。Oracle的功能非常豐富，目前國產(chǎn)化產(chǎn)品無法做到全部兼容，對于分布式數(shù)據(jù)庫而言，這點更為突出。產(chǎn)品評估除去上面因素外，就是從數(shù)據(jù)產(chǎn)品本身維度進行測試。這里涉及的測試點很多，具體細節(jié)可參考我之前的社區(qū)文章。20、在核心業(yè)務(wù)系統(tǒng)方面去O轉(zhuǎn)向國產(chǎn)化數(shù)據(jù)庫產(chǎn)品有哪些典型案例？各家在去O場景上，案例還是很多的，包括部分股份制銀行、城商行等。如中信、平安、張家口商業(yè)、億聯(lián)、北京銀行等。從未來趨勢來看，目前國內(nèi)去O尚未形成較為主流的實現(xiàn)路線，各家策略均有不同。從技術(shù)路線來看，也未達到形式上的統(tǒng)一。因此建議金融企業(yè)，根據(jù)自身特點，選擇更為通用性的標準作為遷移依據(jù)。即從應(yīng)用角度入手，重點考慮兼容標準開發(fā)模式，忽略個體產(chǎn)品差異。對未來不同路線，保持充分的靈活性。21、目前國產(chǎn)數(shù)據(jù)庫有哪些自研的遷移工具或軟件，遷移的停機時間是多少？從上述數(shù)據(jù)庫遷移到國產(chǎn)庫，可分為兩種技術(shù)路線：物理遷移：基于日志這種方式的產(chǎn)品很多，如國內(nèi)的DSG、英方、Datapipe等邏輯遷移：基于數(shù)據(jù)這種方式的產(chǎn)品，開源和商業(yè)的都有，如典型的Kettle、DataX等影響遷移的時長，主要取決于幾個因素：遷移邏輯：是否存在加工轉(zhuǎn)換數(shù)據(jù)對比：是否需做質(zhì)量檢查數(shù)據(jù)規(guī)模/鏈路：一般都采用全量+增量方式，這一因素一般影響不大22、去O國產(chǎn)中面對的存儲過程、函數(shù)等如何處理？國產(chǎn)數(shù)據(jù)庫在庫內(nèi)計算（存儲過程、函數(shù)）及特性能力（如視圖），較Oracle數(shù)據(jù)庫還存在一定差距。特別是采取分布式架構(gòu)的國產(chǎn)數(shù)據(jù)庫，差距更為明顯。從實際推動工作上看，也是兩種策略：盡量選擇兼容性產(chǎn)品，這樣代價相對較小簡化數(shù)據(jù)庫應(yīng)用，將上述能力在應(yīng)用層解決，數(shù)據(jù)庫只做CRUD23、國產(chǎn)數(shù)據(jù)庫遷移中應(yīng)用改造量的評估？應(yīng)用改造工作量的評估，是有一定參考依據(jù)的。之前在項目實踐中，也積累些方法并形成小工具?；驹砭褪歉鶕?jù)對象和語句的數(shù)量、復雜度等作為輸入，根據(jù)實踐總結(jié)出的單位工時進行評估。在后續(xù)的不斷迭代中，改進評估方法。24、有沒有數(shù)據(jù)庫綜合管理平臺推薦？該提問點出了一個遷移到國產(chǎn)庫的共性問題，即數(shù)據(jù)庫碎片化。在傳統(tǒng)數(shù)據(jù)庫選型中，主打兩三款數(shù)據(jù)庫，就可以覆蓋幾乎所有的業(yè)務(wù)場景，而到了國產(chǎn)庫上則情況大不同。一方面數(shù)據(jù)庫的架構(gòu)類別多樣；二方面還沒形成壟斷性產(chǎn)品，眾多產(chǎn)品都可選擇；三方面各產(chǎn)品能力差異較突出，都有各自的適應(yīng)性場景。基于上述現(xiàn)狀，這一問題勢必會影響到企業(yè)的使用。影響的方面包括：數(shù)據(jù)庫架構(gòu)設(shè)計、應(yīng)用開發(fā)、管理維護等多方面。我將此問題，發(fā)散回答下。1.架構(gòu)設(shè)計不同國產(chǎn)庫的架構(gòu)差異很大，沒有辦法統(tǒng)一架構(gòu)，但這方面可通過標準進行規(guī)范化。國家及行業(yè)也推出一些規(guī)范，指導企業(yè)進行架構(gòu)設(shè)計。例如：針對可用性設(shè)計上面，同城3AZ成為很多分布式數(shù)據(jù)庫的默認，以此才能提供自動切換能力，滿足RTO=0,RPO=0的預(yù)期。2.應(yīng)用開發(fā)應(yīng)用開發(fā)方面，整體差異不大?，F(xiàn)有主流數(shù)據(jù)庫還是遵循關(guān)系建模，可利用之前的工具完成。問題比較大的是在結(jié)構(gòu)設(shè)計方面，特別是分布式架構(gòu)有其特點，很多傳統(tǒng)的設(shè)計思想需要改變；SQL語句開發(fā)方面，盡量做到簡潔處理，避免重度依賴國產(chǎn)庫。這方面可使用一些數(shù)據(jù)庫審核工具，輔助做些結(jié)構(gòu)設(shè)計、語法開發(fā)的質(zhì)量檢查工作；但這方面是否有欠缺的，主要是現(xiàn)有工具幾乎無法對各家數(shù)據(jù)庫產(chǎn)品做到差異化審核，只能完成比較初級的檢查。而廠商自有產(chǎn)品能力，大部分還未涉及此部分。3.管理維護在管理維護方面，如上面談到的，各家產(chǎn)品架構(gòu)差異明顯，尚無法做到統(tǒng)一管理。雖然有些第三方廠商產(chǎn)品支持多種數(shù)據(jù)庫平臺的管理功能，但大部分是支持國外商業(yè)數(shù)據(jù)庫和較為流行的開源數(shù)據(jù)庫。對國產(chǎn)庫的支持，尚比較有限。甚至大部分廠商自有產(chǎn)品，在這方面的能力都不太健全。因此，想實現(xiàn)一體化的數(shù)據(jù)庫管理，困難較大。解決的方法，要么是通過自研的方式解決，要么是等待國內(nèi)三方產(chǎn)品完善起來，要么是依賴云平臺（全棧使用某云廠家產(chǎn)品）。4.應(yīng)用訪問在應(yīng)用訪問方面，是否可提供統(tǒng)一的訪問接入也是用戶比較頭疼的問題。大量在數(shù)據(jù)上層應(yīng)用（如審計、安全、可視化等）是無法兼容多種數(shù)據(jù)庫（特別是國產(chǎn)庫）。這方面有些第三方的數(shù)據(jù)庫中間層產(chǎn)品，可提供一定的屏蔽能力，滿足統(tǒng)一訪問的訴求。但比較完美的不多，很多還需要二研增強。25、將商業(yè)數(shù)據(jù)庫Oracle、DB2、SQLServer上的應(yīng)用，遷移到國產(chǎn)數(shù)據(jù)庫，有哪些風險點？從商業(yè)數(shù)據(jù)庫遷移到國產(chǎn)庫，風險是來自多方面的：1.技術(shù)風險國產(chǎn)庫的功能較大型商業(yè)數(shù)據(jù)庫仍存在一定差距，需要在選型時期就有清晰認識。不同國產(chǎn)庫架構(gòu)不同、技術(shù)路線各異，需要建立符合企業(yè)自身要求的評測體系。通過完善的測試，對國產(chǎn)庫有著全面細致的了解。雖然無法做到功能一一對應(yīng)，但起碼要做到對功能邊界清晰可控。通過上述手段，規(guī)避可能潛在的技術(shù)風險。2.開發(fā)風險沒有能夠完美替代數(shù)據(jù)庫的產(chǎn)品，都是需要開發(fā)做一定適配性改造。此處的風險主要一方面來自國產(chǎn)庫功能缺失帶來的應(yīng)用實現(xiàn)側(cè)的技術(shù)難度；一方面則來自開發(fā)資源的投入。特別是當面臨后者的不確定性時，風險更大。此外，還需通過引入測試完成對開發(fā)結(jié)果的驗證，規(guī)避可能的處理邏輯、性能風險。3.遷移風險這里談到的遷移包括數(shù)據(jù)遷移和應(yīng)用遷移。針對前者，相對好處理些，通過應(yīng)用邏輯或其他三方工具是完成數(shù)據(jù)的遷移工作，重點需考慮遷移后的質(zhì)量對比，避免數(shù)據(jù)不一致問題。更多難點在于應(yīng)用遷移，如何平滑完成遷移很重要。此外，相關(guān)的灰度、回退等遷移能力同樣需要具備。而此方面，很難找到通用的平臺來提供基礎(chǔ)能力，大部分還是需要用戶自研完成。4.運行風險數(shù)據(jù)庫上線只是第一步，長期穩(wěn)定運行更為重要。國產(chǎn)數(shù)據(jù)庫普遍面臨發(fā)展時間短，缺少大量線上運行積累，缺少較為成熟的運行維護體系。包括常見的監(jiān)控、診斷、優(yōu)化、排障、備份、高可用、升級等均需要完善支持。26、用戶對自己的信息化都不了解的情況下。如何去更快的了解企業(yè)的數(shù)信息化數(shù)據(jù)庫業(yè)務(wù)？造成這一問題的原因有多種。有些是自研的，因企業(yè)人員流失導致信息丟失；有些是采用外包方式，隨著外包公司的變化消失而導致信息丟失。上述這些現(xiàn)象是客觀存在的，解決方法無外乎兩種，通過業(yè)務(wù)側(cè)和技術(shù)側(cè)解決，亦或是兩者配合使用。1.業(yè)務(wù)側(cè)：需要通過文檔、人員調(diào)研等方式，搜集現(xiàn)有系統(tǒng)運行情況。2.技術(shù)側(cè)：通過各類日志、報告等形式，收集現(xiàn)有系統(tǒng)運行情況。如針對數(shù)據(jù)庫，可利用下述方法做好調(diào)研收集工作?？梢詤⒖歼@篇文章：做一次成功的數(shù)據(jù)庫調(diào)研27、國產(chǎn)數(shù)據(jù)庫選型集中式與分布式如何選取？集中式和分布式，是數(shù)據(jù)庫兩個大的架構(gòu)類型，兩者都有各自適應(yīng)場景。從過去二三十年發(fā)展來看，集中式架構(gòu)很好地解決了金融機構(gòu)的場景問題，從技術(shù)角度來講絕大多數(shù)場景并沒有因能力不足而選擇分布式架構(gòu)的必要。這里更多的是需要考慮多種因素，來做這樣的選擇。1.業(yè)務(wù)訴求隨著金融機構(gòu)業(yè)務(wù)逐步互聯(lián)網(wǎng)化，很多敏態(tài)的業(yè)務(wù)需要底層數(shù)據(jù)庫提供更好的彈性、更大規(guī)模承載力，此時可考慮采用分布式架構(gòu)。2.技術(shù)訴求技術(shù)訴求這里主要來自兩個方面，存儲與計算。一方面是存儲能力的不足，希望通過分布式架構(gòu)提供的水平擴展能力，滿足海量數(shù)據(jù)存儲；一方面是計算能力的不足，希望分布式架構(gòu)引入更多計算資源參與其中。3.風險訴求分布式架構(gòu)因其自身架構(gòu)設(shè)計特點，在高可用、數(shù)據(jù)一致性等方面，較集中式架構(gòu)有優(yōu)勢。有這方面訴求的可考慮分布式。4.成本訴求這點非針對分布式，主要是因為國外大型商業(yè)數(shù)據(jù)庫經(jīng)濟成本較高，該選擇國產(chǎn)庫可相對降低成本投入。但因為國產(chǎn)庫集中式架構(gòu)承載力相對受限，因而考慮分布式架構(gòu)。5.發(fā)展訴求從更為長遠的技術(shù)演進路線角度考慮，引入分布式架構(gòu)做長期儲備。6.政策訴求為響應(yīng)國家或監(jiān)管部