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

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

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

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