近些年來(lái)，國(guó)產(chǎn)數(shù)據(jù)庫(kù)成為較熱門(mén)的話題。有越來(lái)越多的公司考慮采用國(guó)產(chǎn)數(shù)據(jù)庫(kù)產(chǎn)品。近期在與twt社區(qū)的互動(dòng)中，發(fā)現(xiàn)有大量相關(guān)的討論，關(guān)注度也較高。特將自己回答的部分問(wèn)題摘錄如下，也算是對(duì)若干熱點(diǎn)問(wèn)題的個(gè)人觀點(diǎn)。

如何結(jié)合不同的業(yè)務(wù)場(chǎng)景選擇合適的數(shù)據(jù)庫(kù)？1

在做出合適選擇之前，需要以下準(zhǔn)備工作：

1. 業(yè)務(wù)畫(huà)像

針對(duì)不同的業(yè)務(wù)，做出業(yè)務(wù)側(cè)的數(shù)據(jù)庫(kù)畫(huà)像，包括但不限于如下維度：

業(yè)務(wù)指標(biāo)：使用方式、使用特征（在線用戶(hù)、峰值用戶(hù)、并發(fā)用戶(hù)等）、重要級(jí)別、可用性要求。此外，針對(duì)未來(lái)發(fā)展也要有所評(píng)估。

系統(tǒng)指標(biāo)：包括應(yīng)用系統(tǒng)來(lái)源、技術(shù)棧、開(kāi)發(fā)語(yǔ)言、系統(tǒng)拓?fù)洹⑴c數(shù)據(jù)庫(kù)交互方式等

數(shù)據(jù)庫(kù)指標(biāo)：包括數(shù)據(jù)規(guī)模、訪問(wèn)特征、物理環(huán)境、軟件環(huán)境、數(shù)據(jù)庫(kù)拓?fù)涞?

運(yùn)行特征：場(chǎng)景分類(lèi)（TP、AP、混合）、架構(gòu)分類(lèi)、數(shù)據(jù)規(guī)模、數(shù)據(jù)特征、計(jì)算規(guī)模、事務(wù)一致性要求、擴(kuò)展性要求、高可用要求、應(yīng)用耦合性等

2. 產(chǎn)品測(cè)試

對(duì)數(shù)據(jù)庫(kù)產(chǎn)品進(jìn)行測(cè)試，形成對(duì)產(chǎn)品的統(tǒng)一認(rèn)識(shí)。這其中包括數(shù)據(jù)庫(kù)內(nèi)核、管理、開(kāi)發(fā)、安全等多方面能力的評(píng)估。這方面可參考我之前分享的《分布式數(shù)據(jù)庫(kù)評(píng)測(cè)標(biāo)準(zhǔn)》。

3. 其他因素

除上述外，還應(yīng)包括企業(yè)內(nèi)部的一些自身因素的考慮，如成本、運(yùn)維、開(kāi)發(fā)改造等因素。

上述因素綜合考慮后，才能做出相對(duì)合理的選擇。

業(yè)務(wù)系統(tǒng)應(yīng)用架構(gòu)設(shè)計(jì)時(shí)如何適配分布式數(shù)據(jù)庫(kù)以實(shí)現(xiàn)高性能，在線擴(kuò)展后性能如何同步提升？2

性能問(wèn)題，是需要慎重考慮的。如果僅僅考察個(gè)體的表現(xiàn)，分布式數(shù)據(jù)庫(kù)很有可能不如傳統(tǒng)單機(jī)數(shù)據(jù)庫(kù)或集中式數(shù)據(jù)庫(kù)。其分布式架構(gòu)在原理就先天存在一些短板，對(duì)于要求極致性能的場(chǎng)景是不合適的。

分布式數(shù)據(jù)庫(kù)的強(qiáng)處，是在于擴(kuò)展系統(tǒng)的整體吞吐能力，可承載更多的業(yè)務(wù)量。因此從原理上講，擴(kuò)展后不會(huì)提升性能。當(dāng)然，分布式系統(tǒng)擴(kuò)展后，數(shù)據(jù)庫(kù)被做個(gè)更多的拆分，會(huì)有助于單體執(zhí)行效率的提升，這種情況下是有性能提升的。

基于上面，在應(yīng)用架構(gòu)設(shè)計(jì)時(shí)，應(yīng)充分利用分布式數(shù)據(jù)庫(kù)的數(shù)據(jù)分布特點(diǎn)，做好業(yè)務(wù)單元化。通過(guò)在更小的數(shù)據(jù)單元完成，進(jìn)而達(dá)到優(yōu)化效果。

分布式數(shù)據(jù)庫(kù)故障時(shí)如何確保故障自動(dòng)轉(zhuǎn)移，自動(dòng)恢復(fù)業(yè)務(wù)，實(shí)現(xiàn)高可用？3

分布式庫(kù)的組件較多，大致可分為數(shù)據(jù)節(jié)點(diǎn)、計(jì)算節(jié)點(diǎn)、控制節(jié)點(diǎn)三類(lèi)角色。其中，計(jì)算節(jié)點(diǎn)一般為無(wú)狀態(tài)的，故障后可切換自動(dòng)恢復(fù)；控制節(jié)點(diǎn)一般采用自身高可用保障，出現(xiàn)問(wèn)題會(huì)主動(dòng)自愈；數(shù)據(jù)節(jié)點(diǎn)出現(xiàn)問(wèn)題時(shí)較為重要，因?yàn)槠渖厦娉休d的數(shù)據(jù)。我理解問(wèn)題主要是對(duì)應(yīng)這一角色。針對(duì)數(shù)據(jù)節(jié)點(diǎn)，不同分布式數(shù)據(jù)庫(kù)產(chǎn)品，底層實(shí)現(xiàn)有所差異，大致可分為兩種情況：

1.基于單機(jī)數(shù)據(jù)庫(kù)的主從復(fù)制模式

2.基于多數(shù)派協(xié)議保證的多副本模式

無(wú)論是哪種模式，當(dāng)出現(xiàn)故障時(shí)都會(huì)完成自動(dòng)選主，自動(dòng)切換，從而實(shí)現(xiàn)高可用。目前的大部分產(chǎn)品，都已可實(shí)現(xiàn)在同AZ、同城跨AZ的自主切換、對(duì)業(yè)務(wù)無(wú)感（業(yè)務(wù)需實(shí)現(xiàn)出錯(cuò)重試機(jī)制）。針對(duì)異地的情況，一般還是建議人工介入，而不自動(dòng)完成切換。

分布式數(shù)據(jù)庫(kù)全局一致性和高性能如何取舍達(dá)到平衡？4

個(gè)人覺(jué)得這兩者不存在平衡關(guān)系，一般一致性要求是來(lái)源于業(yè)務(wù)，很難去做業(yè)務(wù)上的取舍。都是在有明確一致性要求的情況下，盡量做到性能最好。

中小銀行后端穩(wěn)態(tài)類(lèi)系統(tǒng)進(jìn)行分布式方向改造的必要性？5

分布式改造的必要性，主要來(lái)自于幾個(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)衡分布式改造所帶來(lái)的投入產(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)估。

是否有適合銀行業(yè)務(wù)場(chǎng)景的OLTP基準(zhǔn)測(cè)試？6

目前沒(méi)有統(tǒng)一的OLTP測(cè)試標(biāo)準(zhǔn)，其原因是銀行的業(yè)務(wù)也各有不同，很難找到統(tǒng)一標(biāo)準(zhǔn)。一般的做法是找出部分有代表性的業(yè)務(wù)，簡(jiǎn)化提煉后形成一個(gè)測(cè)試case。在測(cè)試中，通過(guò)不同測(cè)試case的組合，形成滿足某業(yè)務(wù)的測(cè)試集。

關(guān)于國(guó)產(chǎn)分布式數(shù)據(jù)庫(kù)未來(lái)趨勢(shì)分析？7

目前尚處于早期階段，趨勢(shì)發(fā)展上還不是很明朗。個(gè)人有以下一些判斷：

1.多技術(shù)路線會(huì)長(zhǎng)期共存

2.云會(huì)在未來(lái)達(dá)到統(tǒng)一，但周期會(huì)很長(zhǎng)

3.MySQL、PG會(huì)成為事實(shí)生態(tài)標(biāo)準(zhǔn)，各產(chǎn)品會(huì)加以適配

面對(duì)這么多國(guó)產(chǎn)分布式數(shù)據(jù)庫(kù)，如何制定一個(gè)選型標(biāo)準(zhǔn)？8

關(guān)于選型標(biāo)準(zhǔn)，目前沒(méi)有統(tǒng)一國(guó)家、行業(yè)標(biāo)準(zhǔn)，有條件的企業(yè)都在做自有標(biāo)準(zhǔn)。按照之前的工作，需梳理出選型測(cè)試的眾多評(píng)估維度及細(xì)化的指標(biāo)。這里是存在不小的工作量。這里可參考我近期發(fā)的一些內(nèi)容：分布式數(shù)據(jù)庫(kù)評(píng)估維度分析

在分布式數(shù)據(jù)庫(kù)架構(gòu)選型中，如何看待計(jì)算與存儲(chǔ)分離？9

存算分離，還是要看具體解決的問(wèn)題。其最早是由云廠商提出的，目的是將資源解耦，從而實(shí)現(xiàn)不同資源的分層擴(kuò)縮。看待這個(gè)特性，還是要看其背后帶來(lái)的收益，是否是自身關(guān)注的；否則沒(méi)有太大意義。

國(guó)產(chǎn)數(shù)據(jù)庫(kù)高可用和穩(wěn)定性混沌測(cè)試標(biāo)準(zhǔn)經(jīng)驗(yàn)分享？10

這方面經(jīng)驗(yàn)不多，國(guó)內(nèi)有些金融企業(yè)在自主構(gòu)建混沌測(cè)試平臺(tái)，某些廠商（如PingCAP）也開(kāi)源混沌測(cè)試平臺(tái)，可嘗試使用。

分布式數(shù)據(jù)庫(kù)容災(zāi)容錯(cuò)方案？11

高可用方案，各家產(chǎn)品實(shí)現(xiàn)有所差異。一般情況下，在同城雙中心異地單中心的情況下，當(dāng)同城某AZ出現(xiàn)問(wèn)題時(shí)，是無(wú)法自動(dòng)切換到同城第二個(gè)AZ，是需要引入第三個(gè)AZ，滿足仲裁需求的。當(dāng)然有些是可以寫(xiě)死切換邏輯在里面，但非標(biāo)準(zhǔn)的切換流程。因此，一般建議在同城采用3AZ，滿足多數(shù)派選舉，可實(shí)現(xiàn)自動(dòng)切換能力。異地一般不建議參與其中，畢竟存在較長(zhǎng)時(shí)延。

分布式數(shù)據(jù)庫(kù)系統(tǒng)批量?jī)?yōu)化改造方案？12

這方面經(jīng)驗(yàn)不多，據(jù)了解如果僅從吞吐量來(lái)衡量，分布式數(shù)據(jù)庫(kù)能力一般是要高于傳統(tǒng)數(shù)據(jù)庫(kù)的。當(dāng)然，前提條件是批量處理部分是可以有明確的單元拆分，充分利用并行能力帶來(lái)跑批的收益。

分布式數(shù)據(jù)庫(kù)使用規(guī)則？13

分布式數(shù)據(jù)庫(kù)較傳統(tǒng)單機(jī)數(shù)據(jù)庫(kù)或集中式數(shù)據(jù)庫(kù)，是存在較多不同，因此在開(kāi)發(fā)之處就有針對(duì)性的進(jìn)行規(guī)避比較重要。這其中常見(jiàn)的點(diǎn)包括：事務(wù)大小、SQL復(fù)雜度、分布式事務(wù)、DDL變更等。基本的處理原則就是3B原則，即避免Big SQL、Big Transaction、Big Batch。此外，盡量減小分布式數(shù)據(jù)庫(kù)中的變更，無(wú)論是架構(gòu)上的（如擴(kuò)縮容）、結(jié)構(gòu)上的（如DDL）等。

傳統(tǒng)dba如何轉(zhuǎn)型？14

這個(gè)話題有點(diǎn)大，可參考下我的總結(jié)。

DBA定位、突破與職業(yè)發(fā)展

OLTP類(lèi)業(yè)務(wù)基于分布式數(shù)據(jù)庫(kù)架構(gòu)，如何從軟件和硬件層面分別保障性能和可靠性？15

分布數(shù)據(jù)庫(kù)一般多從軟件層面做了可用性保證，如采取多副本機(jī)制等，通常不采用傳統(tǒng)基于硬件的可用性方案。

分布式數(shù)據(jù)庫(kù)如何選型？16

通常不會(huì)根據(jù)每套應(yīng)用來(lái)選擇合適的數(shù)據(jù)庫(kù)，這樣做的話技術(shù)棧可能過(guò)于發(fā)散。建議的做法是，根據(jù)公司業(yè)務(wù)場(chǎng)景，收斂為若干種類(lèi)型，然后為每個(gè)類(lèi)型選擇2~3款產(chǎn)品。選擇多款產(chǎn)品的原因，是為了避免廠商綁定問(wèn)題。然后需要根據(jù)每類(lèi)場(chǎng)景，制定開(kāi)發(fā)規(guī)范（取2~3款產(chǎn)品的功能交集作為標(biāo)準(zhǔn)）。

分布式數(shù)據(jù)庫(kù)，兩地三中心如何實(shí)現(xiàn)平穩(wěn)切換17

1.同城出現(xiàn)問(wèn)題，一般分布式數(shù)據(jù)庫(kù)可實(shí)現(xiàn)自動(dòng)切換，對(duì)應(yīng)用有瞬時(shí)影響，只要應(yīng)用支持錯(cuò)誤重試即可。

2.針對(duì)異地情況，一般無(wú)法自動(dòng)切換（也不建議自動(dòng)），還需要人工仲裁判斷是否切換。

有成熟的國(guó)產(chǎn)數(shù)據(jù)庫(kù)產(chǎn)品替代oracle、db2數(shù)據(jù)產(chǎn)品嗎？18

替代Oracle或DB2的產(chǎn)品，可分為幾種類(lèi)型：

1.核心業(yè)務(wù)

此類(lèi)業(yè)務(wù)特點(diǎn)是數(shù)據(jù)規(guī)模大、并發(fā)高、延遲要求低，但數(shù)據(jù)庫(kù)使用場(chǎng)景較為簡(jiǎn)單。通常這種方式可使用業(yè)務(wù)側(cè)單元化+國(guó)產(chǎn)庫(kù)方式。這種方式對(duì)庫(kù)的要求相對(duì)不高，可選擇的范圍較廣。

2.中型業(yè)務(wù)

此類(lèi)業(yè)務(wù)特點(diǎn)是數(shù)據(jù)規(guī)模中等，數(shù)據(jù)庫(kù)使用復(fù)雜度。這種方式要想很好地替代，相對(duì)較難。一般建議的做法是重構(gòu)。當(dāng)然這里需要考慮的改造成本比較高。可考慮的選型范圍是NewSQL系列產(chǎn)品。

3.小型業(yè)務(wù)

此類(lèi)業(yè)務(wù)特點(diǎn)是數(shù)據(jù)規(guī)模較小，復(fù)雜度不低。這種系統(tǒng)數(shù)量眾多，可考慮是使用對(duì)Oracle/DB2兼容性較高的產(chǎn)品。如很多從PG衍生的產(chǎn)品或國(guó)內(nèi)部分?jǐn)?shù)據(jù)庫(kù)產(chǎn)品。

是否有支持在多款數(shù)據(jù)庫(kù)之間遷移的產(chǎn)品？19

遷移可分為三種情況：

物理遷移：基于數(shù)據(jù)庫(kù)的日志，采用CDC的方式進(jìn)行。采用這種方式的商業(yè)產(chǎn)品比較多，例如國(guó)內(nèi)的DSG、英方等。

邏輯遷移：基于數(shù)據(jù)的遷移，類(lèi)似采用窗口方式提取數(shù)據(jù)實(shí)現(xiàn)遷移。采用這種方式的商業(yè)及開(kāi)源產(chǎn)品都比較多，比較典型如sqoop。

應(yīng)用遷移：應(yīng)用側(cè)自己搞定遷移問(wèn)題，需自研代碼。

國(guó)產(chǎn)數(shù)據(jù)庫(kù)如何實(shí)現(xiàn)在正式庫(kù)中進(jìn)行測(cè)試？20

庫(kù)內(nèi)測(cè)試的問(wèn)題，一般不是通過(guò)數(shù)據(jù)庫(kù)端實(shí)現(xiàn)的，可通過(guò)互聯(lián)網(wǎng)通常采用的影子庫(kù)方案來(lái)解決。也有一些開(kāi)源產(chǎn)品（如shardingsphere），內(nèi)置了這一能力，通過(guò)在上層模擬出數(shù)據(jù)庫(kù)的統(tǒng)一入口，內(nèi)部設(shè)置分流、限流策略，來(lái)完成壓測(cè)工作。

國(guó)產(chǎn)分布式數(shù)據(jù)庫(kù)，在成本上是否如宣傳的那樣比Oracle有較大的優(yōu)勢(shì)？21

采用分布式數(shù)據(jù)庫(kù)的成本來(lái)自幾個(gè)方面：

軟件授權(quán)費(fèi)用：這部分相對(duì)有一定優(yōu)勢(shì)，Oracle原廠費(fèi)用較高。

軟件服務(wù)費(fèi)用：這部分相對(duì)國(guó)產(chǎn)庫(kù)較高，因?yàn)槌墒於炔蛔悖€需大量人力投入且還未形成成熟的服務(wù)生態(tài)

硬件采購(gòu)費(fèi)用：這部分分布式國(guó)產(chǎn)庫(kù)較高，因?yàn)樯婕暗慕M件較多，需耗費(fèi)機(jī)器資源較多。

日常維護(hù)費(fèi)用：這部分國(guó)產(chǎn)庫(kù)較高，因需重新搭建隊(duì)伍，新增人力成本較高

NEWSQL分布式數(shù)據(jù)庫(kù)數(shù)據(jù)同步？22

NewSQL的同步，主要看其架構(gòu)：

基于分庫(kù)分表架構(gòu)，一般較難提供全局CDC能力，只能通過(guò)底層數(shù)據(jù)節(jié)點(diǎn)的數(shù)據(jù)同步，無(wú)法滿足全局一致性要求，有一定缺陷。

基于原生分布式架構(gòu)，一般可提供CDC能力（如TiDB），可滿足上述需求。

省級(jí)銀行推廣國(guó)產(chǎn)分布式數(shù)據(jù)庫(kù)，需要如何配置人力？各家主流廠商推薦客戶(hù)配置多少分布式數(shù)據(jù)庫(kù)DBA ？23

這部分沒(méi)有一定之規(guī)，一般國(guó)產(chǎn)分布式數(shù)據(jù)庫(kù)的成熟度差異較大，需根據(jù)各自不同數(shù)據(jù)庫(kù)來(lái)考慮。推薦按照每3~5個(gè)，配置一名DBA，長(zhǎng)期可過(guò)渡到5~10個(gè)庫(kù)一名DBA。

NewSQL分布式數(shù)據(jù)庫(kù)有哪些缺陷？24

主要缺陷取決于不同庫(kù)的架構(gòu)，這點(diǎn)差異很大。重點(diǎn)可考察：

分布式事務(wù)、全局一致性

全局日志，數(shù)據(jù)唯一性

同城&異地高可用

生態(tài)功能（如針對(duì)研發(fā)）

管控能力（管理、優(yōu)化、監(jiān)控等）

NewSQL分布式數(shù)據(jù)庫(kù)在銀行業(yè)目前案例較少，未來(lái)發(fā)展前景如何？25

NewSQL代表著未來(lái)的趨勢(shì)，發(fā)展前景毋容置疑。相信會(huì)在未來(lái)3~5年內(nèi)，逐步普及。

云原生分布式數(shù)據(jù)庫(kù)與基于中間件架構(gòu)的數(shù)據(jù)庫(kù)，技術(shù)優(yōu)勢(shì)在哪里？26

系統(tǒng)上限能力較高

功能完整度很高

可快速增強(qiáng)能力

國(guó)產(chǎn)數(shù)據(jù)庫(kù)去O，是用基于PG產(chǎn)品，還是考慮基于MySQL產(chǎn)品合適？27

在去O過(guò)程中，我們先明確一點(diǎn)，沒(méi)有數(shù)據(jù)庫(kù)產(chǎn)品是可以完全替代的。即完成去O工作，是需要通過(guò)“應(yīng)用改造+數(shù)據(jù)庫(kù)選型+應(yīng)用遷移”，結(jié)合在一起才能完成。這里需要考慮整體目標(biāo)及路徑。問(wèn)題中的兩種方式，原則上都是可以完成去O工作，但對(duì)于應(yīng)用改造及遷移的影響差異較大。

PG類(lèi)產(chǎn)品，其企業(yè)級(jí)功能較為完善，使用體感與Oracle相近。有些基于PG為內(nèi)核的產(chǎn)品，在Oracle兼容性上做了了大量工作。對(duì)用戶(hù)來(lái)說(shuō)，使用上與Oracle更為相近，甚至大部分可以做到無(wú)縫遷移；少部分需要修改上，也相對(duì)工作量不大。

MySQL類(lèi)產(chǎn)品，流行程度更高，但與Oracle相比，功能差異較多。如在去O中選用，需做較大的修改。

數(shù)據(jù)遷移如何保證前后一致性？28

數(shù)據(jù)遷移后，前后環(huán)境處于靜態(tài)切面，做數(shù)據(jù)對(duì)比是比較簡(jiǎn)單的。操作上可有幾種方式：

自研-數(shù)據(jù)

可通過(guò)SQL語(yǔ)句完成簡(jiǎn)單的數(shù)據(jù)對(duì)比，如記錄條目數(shù)，多維度統(tǒng)計(jì)報(bào)告進(jìn)行比對(duì)。

自研-過(guò)程

可針對(duì)遷移過(guò)程中的日志的方式，通過(guò)代碼提取對(duì)比。這種方式對(duì)目標(biāo)庫(kù)無(wú)影響。

外部工具

有些外部產(chǎn)品也支持?jǐn)?shù)據(jù)比對(duì)，如DSG的super sync等

問(wèn)題：數(shù)據(jù)比對(duì)的核心問(wèn)題是效率，需找到一種平衡。

目前國(guó)產(chǎn)化分布式數(shù)據(jù)庫(kù)產(chǎn)品繁多，對(duì)OLTP數(shù)據(jù)庫(kù)在去O轉(zhuǎn)向國(guó)產(chǎn)化該如何做選型評(píng)估？29

這個(gè)問(wèn)題比較寬泛，可分為幾種情況：

兼容性評(píng)估

這與去O的路線有關(guān)，如考慮盡量減少去O的應(yīng)用遷移難度，選擇兼容Oracle的產(chǎn)品，則兼容性需要重點(diǎn)評(píng)估。Oracle的功能非常豐富，目前國(guó)產(chǎn)化產(chǎn)品無(wú)法做到全部兼容，對(duì)于分布式數(shù)據(jù)庫(kù)而言，這點(diǎn)更為突出。

產(chǎn)品評(píng)估

除去上面因素外，就是從數(shù)據(jù)產(chǎn)品本身維度進(jìn)行測(cè)試。這里涉及的測(cè)試點(diǎn)很多，具體細(xì)節(jié)可參考我之前的社區(qū)文章。

在核心業(yè)務(wù)系統(tǒng)方面去O轉(zhuǎn)向國(guó)產(chǎn)化數(shù)據(jù)庫(kù)產(chǎn)品有哪些典型案例？30

各家在去O場(chǎng)景上，案例還是很多的，包括部分股份制銀行、城商行等。如中信、平安、張家口商業(yè)、億聯(lián)、北京銀行等。

從未來(lái)趨勢(shì)來(lái)看，目前國(guó)內(nèi)去O尚未形成較為主流的實(shí)現(xiàn)路線，各家策略均有不同。從技術(shù)路線來(lái)看，也未達(dá)到形式上的統(tǒng)一。因此建議金融企業(yè)，根據(jù)自身特點(diǎn)，選擇更為通用性的標(biāo)準(zhǔn)作為遷移依據(jù)。即從應(yīng)用角度入手，重點(diǎn)考慮兼容標(biāo)準(zhǔn)開(kāi)發(fā)模式，忽略個(gè)體產(chǎn)品差異。對(duì)未來(lái)不同路線，保持充分的靈活性。

目前國(guó)產(chǎn)數(shù)據(jù)庫(kù)有哪些自研的遷移工具或軟件，遷移的停機(jī)時(shí)間是多少？31

從上述數(shù)據(jù)庫(kù)遷移到國(guó)產(chǎn)庫(kù)，可分為兩種技術(shù)路線：

物理遷移：基于日志

這種方式的產(chǎn)品很多，如國(guó)內(nèi)的DSG、英方、Datapipe等

邏輯遷移：基于數(shù)據(jù)

這種方式的產(chǎn)品，開(kāi)源和商業(yè)的都有，如典型的Kettle、DataX等

影響遷移的時(shí)長(zhǎng)，主要取決于幾個(gè)因素：

遷移邏輯：是否存在加工轉(zhuǎn)換

數(shù)據(jù)對(duì)比：是否需做質(zhì)量檢查

數(shù)據(jù)規(guī)模/鏈路：一般都采用全量+增量方式，這一因素一般影響不大

從oracle遷移到新的數(shù)據(jù)庫(kù)后，如何比較兩端數(shù)據(jù)內(nèi)容的一致性？有沒(méi)有工具？32

數(shù)據(jù)遷移后，前后環(huán)境處于靜態(tài)切面，做數(shù)據(jù)對(duì)比是比較簡(jiǎn)單的。操作上可有幾種方式：

自研-數(shù)據(jù)

可通過(guò)SQL語(yǔ)句完成簡(jiǎn)單的數(shù)據(jù)對(duì)比，如記錄條目數(shù)，多維度統(tǒng)計(jì)報(bào)告進(jìn)行比對(duì)。

自研-過(guò)程

可針對(duì)遷移過(guò)程中的日志的方式，通過(guò)代碼提取對(duì)比。這種方式對(duì)目標(biāo)庫(kù)無(wú)影響。

外部工具

有些外部產(chǎn)品也支持?jǐn)?shù)據(jù)比對(duì)，如DSG的super sync等

問(wèn)題：數(shù)據(jù)比對(duì)的核心問(wèn)題是效率，需找到一種平衡。

目前國(guó)產(chǎn)數(shù)據(jù)庫(kù)在對(duì)標(biāo)O記的pdb技術(shù)上有什么解決方案？33

目前國(guó)產(chǎn)數(shù)據(jù)庫(kù)在租戶(hù)方面，能力上普遍不足。OceanBase在這方面，應(yīng)該是比較超前的，沒(méi)有 具體 使用經(jīng)驗(yàn)。對(duì)于不足之處，一般可從解決方案層面解決。考慮在接入層、計(jì)算層、存儲(chǔ)層做好相應(yīng)的隔離工作即可。

去O國(guó)產(chǎn)中面對(duì)的存儲(chǔ)過(guò)程、函數(shù)等如何處理？34

國(guó)產(chǎn)數(shù)據(jù)庫(kù)在庫(kù)內(nèi)計(jì)算（存儲(chǔ)過(guò)程、函數(shù)）及特性能力（如視圖），較Oracle數(shù)據(jù)庫(kù)還存在一定差距。特別是采取分布式架構(gòu)的國(guó)產(chǎn)數(shù)據(jù)庫(kù)，差距更為明顯。從實(shí)際推動(dòng)工作上看，也是兩種策略：

盡量選擇兼容性產(chǎn)品，這樣代價(jià)相對(duì)較小

簡(jiǎn)化數(shù)據(jù)庫(kù)應(yīng)用，將上述能力在應(yīng)用層解決，數(shù)據(jù)庫(kù)只做CRUD

國(guó)產(chǎn)數(shù)據(jù)庫(kù)遷移中應(yīng)用改造量的評(píng)估？35

應(yīng)用改造工作量的評(píng)估，是有一定參考依據(jù)的。之前在項(xiàng)目實(shí)踐中，也積累些方法并形成小工具。基本原理就是根據(jù)對(duì)象和語(yǔ)句的數(shù)量、復(fù)雜度等作為輸入，根據(jù)實(shí)踐總結(jié)出的單位工時(shí)進(jìn)行評(píng)估。在后續(xù)的不斷迭代中，改進(jìn)評(píng)估方法。

國(guó)產(chǎn)數(shù)據(jù)庫(kù)對(duì)DB2的支持？36

DB2的生態(tài)環(huán)境，相較于Oracle更加封閉。目前已知的一些國(guó)內(nèi)主流的數(shù)據(jù)庫(kù)遷移廠商，也支持從DB2到其他庫(kù)的數(shù)據(jù)遷移工作。只不過(guò)使用相對(duì)案例少些，需要打磨功能。

在O上的偏OLAP類(lèi)業(yè)務(wù)如何處理？37

Oracle的AP分析能力是比較強(qiáng)的，這主要受益于其自身強(qiáng)大的優(yōu)化器能力。如去O的話，目標(biāo)庫(kù)是否具備同等分析能力存疑，是需要做評(píng)測(cè)的。如遇到數(shù)據(jù)庫(kù)自身分析能力不足問(wèn)題，可考慮使用組合方案，如TP+AP的模式或引入大數(shù)據(jù)技術(shù)棧來(lái)解決。

國(guó)產(chǎn)數(shù)據(jù)庫(kù)的系統(tǒng)安全怎么評(píng)估？38

這方面是有所欠缺的，主流的安全廠商工具尚不支持國(guó)產(chǎn)庫(kù)，這部分還需持續(xù)增強(qiáng)。當(dāng)前使用上，還需更多依賴(lài)國(guó)產(chǎn)庫(kù)廠商自身，評(píng)估解決可能潛在的安全漏洞。

有沒(méi)有數(shù)據(jù)庫(kù)綜合管理平臺(tái)推薦？39

該提問(wèn)點(diǎn)出了一個(gè)遷移到國(guó)產(chǎn)庫(kù)的共性問(wèn)題，即數(shù)據(jù)庫(kù)碎片化。在傳統(tǒng)數(shù)據(jù)庫(kù)選型中，主打兩三款數(shù)據(jù)庫(kù)，就可以覆蓋幾乎所有的業(yè)務(wù)場(chǎng)景，而到了國(guó)產(chǎn)庫(kù)上則情況大不同。一方面數(shù)據(jù)庫(kù)的架構(gòu)類(lèi)別多樣；二方面還沒(méi)形成壟斷性產(chǎn)品，眾多產(chǎn)品都可選擇；三方面各產(chǎn)品能力差異較突出，都有各自的適應(yīng)性場(chǎng)景。基于上述現(xiàn)狀，這一問(wèn)題勢(shì)必會(huì)影響到企業(yè)的使用。影響的方面包括：數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)、應(yīng)用開(kāi)發(fā)、管理維護(hù)等多方面。我將此問(wèn)題，發(fā)散回答下。

1.架構(gòu)設(shè)計(jì)

不同國(guó)產(chǎn)庫(kù)的架構(gòu)差異很大，沒(méi)有辦法統(tǒng)一架構(gòu)，但這方面可通過(guò)標(biāo)準(zhǔn)進(jìn)行規(guī)范化。國(guó)家及行業(yè)也推出一些規(guī)范，指導(dǎo)企業(yè)進(jìn)行架構(gòu)設(shè)計(jì)。例如：針對(duì)可用性設(shè)計(jì)上面，同城3AZ成為很多分布式數(shù)據(jù)庫(kù)的默認(rèn)，以此才能提供自動(dòng)切換能力，滿足RTO=0,RPO=0的預(yù)期。

2.應(yīng)用開(kāi)發(fā)

應(yīng)用開(kāi)發(fā)方面，整體差異不大。現(xiàn)有主流數(shù)據(jù)庫(kù)還是遵循關(guān)系建模，可利用之前的工具完成。問(wèn)題比較大的是在結(jié)構(gòu)設(shè)計(jì)方面，特別是分布式架構(gòu)有其特點(diǎn)，很多傳統(tǒng)的設(shè)計(jì)思想需要改變；SQL語(yǔ)句開(kāi)發(fā)方面，盡量做到簡(jiǎn)潔處理，避免重度依賴(lài)國(guó)產(chǎn)庫(kù)。這方面可使用一些數(shù)據(jù)庫(kù)審核工具，輔助做些結(jié)構(gòu)設(shè)計(jì)、語(yǔ)法開(kāi)發(fā)的質(zhì)量檢查工作；但這方面是否有欠缺的，主要是現(xiàn)有工具幾乎無(wú)法對(duì)各家數(shù)據(jù)庫(kù)產(chǎn)品做到差異化審核，只能完成比較初級(jí)的檢查。而廠商自有產(chǎn)品能力，大部分還未涉及此部分。

3.管理維護(hù)

在管理維護(hù)方面，如上面談到的，各家產(chǎn)品架構(gòu)差異明顯，尚無(wú)法做到統(tǒng)一管理。雖然有些第三方廠商產(chǎn)品支持多種數(shù)據(jù)庫(kù)平臺(tái)的管理功能，但大部分是支持國(guó)外商業(yè)數(shù)據(jù)庫(kù)和較為流行的開(kāi)源數(shù)據(jù)庫(kù)。對(duì)國(guó)產(chǎn)庫(kù)的支持，尚比較有限。甚至大部分廠商自有產(chǎn)品，在這方面的能力都不太健全。因此，想實(shí)現(xiàn)一體化的數(shù)據(jù)庫(kù)管理，困難較大。解決的方法，要么是通過(guò)自研的方式解決，要么是等待國(guó)內(nèi)三方產(chǎn)品完善起來(lái)，要么是依賴(lài)云平臺(tái)（全棧使用某云廠家產(chǎn)品）。

4.應(yīng)用訪問(wèn)

在應(yīng)用訪問(wèn)方面，是否可提供統(tǒng)一的訪問(wèn)接入也是用戶(hù)比較頭疼的問(wèn)題。大量在數(shù)據(jù)上層應(yīng)用（如審計(jì)、安全、可視化等）是無(wú)法兼容多種數(shù)據(jù)庫(kù)（特別是國(guó)產(chǎn)庫(kù)）。這方面有些第三方的數(shù)據(jù)庫(kù)中間層產(chǎn)品，可提供一定的屏蔽能力，滿足統(tǒng)一訪問(wèn)的訴求。但比較完美的不多，很多還需要二研增強(qiáng)。

將商業(yè)數(shù)據(jù)庫(kù)Oracle、DB2、SQL Server上的應(yīng)用，遷移到國(guó)產(chǎn)數(shù)據(jù)庫(kù)，有哪些風(fēng)險(xiǎn)點(diǎn)？40

從商業(yè)數(shù)據(jù)庫(kù)遷移到國(guó)產(chǎn)庫(kù)，風(fēng)險(xiǎn)是來(lái)自多方面的：

1.技術(shù)風(fēng)險(xiǎn)

國(guó)產(chǎn)庫(kù)的功能較大型商業(yè)數(shù)據(jù)庫(kù)仍存在一定差距，需要在選型時(shí)期就有清晰認(rèn)識(shí)。不同國(guó)產(chǎn)庫(kù)架構(gòu)不同、技術(shù)路線各異，需要建立符合企業(yè)自身要求的評(píng)測(cè)體系。通過(guò)完善的測(cè)試，對(duì)國(guó)產(chǎn)庫(kù)有著全面細(xì)致的了解。雖然無(wú)法做到功能一一對(duì)應(yīng)，但起碼要做到對(duì)功能邊界清晰可控。通過(guò)上述手段，規(guī)避可能潛在的技術(shù)風(fēng)險(xiǎn)。

2.開(kāi)發(fā)風(fēng)險(xiǎn)

沒(méi)有能夠完美替代數(shù)據(jù)庫(kù)的產(chǎn)品，都是需要開(kāi)發(fā)做一定適配性改造。此處的風(fēng)險(xiǎn)主要一方面來(lái)自國(guó)產(chǎn)庫(kù)功能缺失帶來(lái)的應(yīng)用實(shí)現(xiàn)側(cè)的技術(shù)難度；一方面則來(lái)自開(kāi)發(fā)資源的投入。特別是當(dāng)面臨后者的不確定性時(shí)，風(fēng)險(xiǎn)更大。此外，還需通過(guò)引入測(cè)試完成對(duì)開(kāi)發(fā)結(jié)果的驗(yàn)證，規(guī)避可能的處理邏輯、性能風(fēng)險(xiǎn)。

3.遷移風(fēng)險(xiǎn)

這里談到的遷移包括數(shù)據(jù)遷移和應(yīng)用遷移。針對(duì)前者，相對(duì)好處理些，通過(guò)應(yīng)用邏輯或其他三方工具是完成數(shù)據(jù)的遷移工作，重點(diǎn)需考慮遷移后的質(zhì)量對(duì)比，避免數(shù)據(jù)不一致問(wèn)題。更多難點(diǎn)在于應(yīng)用遷移，如何平滑完成遷移很重要。此外，相關(guān)的灰度、回退等遷移能力同樣需要具備。而此方面，很難找到通用的平臺(tái)來(lái)提供基礎(chǔ)能力，大部分還是需要用戶(hù)自研完成。

4.運(yùn)行風(fēng)險(xiǎn)

數(shù)據(jù)庫(kù)上線只是第一步，長(zhǎng)期穩(wěn)定運(yùn)行更為重要。國(guó)產(chǎn)數(shù)據(jù)庫(kù)普遍面臨發(fā)展時(shí)間短，缺少大量線上運(yùn)行積累，缺少較為成熟的運(yùn)行維護(hù)體系。包括常見(jiàn)的監(jiān)控、診斷、優(yōu)化、排障、備份、高可用、升級(jí)等均需要完善支持。

用戶(hù)對(duì)自己的信息化都不了解的情況下。如何去更快的了解企業(yè)的數(shù)信息化數(shù)據(jù)庫(kù)業(yè)務(wù)？41

造成這一問(wèn)題的原因有多種。有些是自研的，因企業(yè)人員流失導(dǎo)致信息丟失；有些是采用外包方式，隨著外包公司的變化消失而導(dǎo)致信息丟失。上述這些現(xiàn)象是客觀存在的，解決方法無(wú)外乎兩種，通過(guò)業(yè)務(wù)側(cè)和技術(shù)側(cè)解決，亦或是兩者配合使用。

1.業(yè)務(wù)側(cè)：需要通過(guò)文檔、人員調(diào)研等方式，搜集現(xiàn)有系統(tǒng)運(yùn)行情況。

2.技術(shù)側(cè)：通過(guò)各類(lèi)日志、報(bào)告等形式，收集現(xiàn)有系統(tǒng)運(yùn)行情況。如針對(duì)數(shù)據(jù)庫(kù)，可利用下述方法做好調(diào)研收集工作。可以參考這篇文章：

做一次成功的數(shù)據(jù)庫(kù)調(diào)研

國(guó)產(chǎn)數(shù)據(jù)庫(kù)選型集中式與分布式如何選取？42

集中式和分布式，是數(shù)據(jù)庫(kù)兩個(gè)大的架構(gòu)類(lèi)型，兩者都有各自適應(yīng)場(chǎng)景。從過(guò)去二三十年發(fā)展來(lái)看，集中式架構(gòu)很好地解決了金融機(jī)構(gòu)的場(chǎng)景問(wèn)題，從技術(shù)角度來(lái)講絕大多數(shù)場(chǎng)景并沒(méi)有因能力不足而選擇分布式架構(gòu)的必要。這里更多的是需要考慮多種因素，來(lái)做這樣的選擇。

1.業(yè)務(wù)訴求

隨著金融機(jī)構(gòu)業(yè)務(wù)逐步互聯(lián)網(wǎng)化，很多敏態(tài)的業(yè)務(wù)需要底層數(shù)據(jù)庫(kù)提供更好的彈性、更大規(guī)模承載力，此時(shí)可考慮采用分布式架構(gòu)。

2.技術(shù)訴求

技術(shù)訴求這里主要來(lái)自?xún)蓚€(gè)方面，存儲(chǔ)與計(jì)算。一方面是存儲(chǔ)能力的不足，希望通過(guò)分布式架構(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)閲?guó)外大型商業(yè)數(shù)據(jù)庫(kù)經(jīng)濟(jì)成本較高，該選擇國(guó)產(chǎn)庫(kù)可相對(duì)降低成本投入。但因?yàn)閲?guó)產(chǎn)庫(kù)集中式架構(gòu)承載力相對(duì)受限，因而考慮分布式架構(gòu)。

5.發(fā)展訴求

從更為長(zhǎng)遠(yuǎn)的技術(shù)演進(jìn)路線角度考慮，引入分布式架構(gòu)做長(zhǎng)期儲(chǔ)備。

6.政策訴求

為響應(yīng)國(guó)家或監(jiān)管部門(mén)要求，而采用國(guó)產(chǎn)庫(kù)進(jìn)而使用到國(guó)產(chǎn)分布式數(shù)據(jù)庫(kù)。

數(shù)據(jù)庫(kù)遷移過(guò)程中的應(yīng)用側(cè)改造內(nèi)容？43

1.應(yīng)用側(cè)改造內(nèi)容

應(yīng)用側(cè)需改造內(nèi)容，分為幾個(gè)方面：

數(shù)據(jù)處理邏輯

這方面指使用數(shù)據(jù)庫(kù)的業(yè)務(wù)邏輯，簡(jiǎn)單分為結(jié)構(gòu)改造和語(yǔ)句改造。部分情況，可通過(guò)簡(jiǎn)單的Mapping方式去解決，但還有些需要重構(gòu)邏輯，甚至重新設(shè)計(jì)結(jié)構(gòu)來(lái)完成。有些特別復(fù)雜的或存在數(shù)據(jù)庫(kù)端無(wú)法實(shí)現(xiàn)的邏輯，就需要第二方面完成。

應(yīng)用處理邏輯

針對(duì)不易處理的邏輯，需要拆分到應(yīng)用側(cè)解決或者使用其他數(shù)據(jù)庫(kù)能力（如引入數(shù)據(jù)分析）來(lái)解決。

應(yīng)用遷移邏輯

為滿足后面平滑遷移需求，有時(shí)是需要在應(yīng)用側(cè)做些改造，例如同時(shí)適配多種數(shù)據(jù)源，實(shí)現(xiàn)應(yīng)用級(jí)雙發(fā)來(lái)保證數(shù)據(jù)一致等。

2.應(yīng)用平滑遷移

簡(jiǎn)單的可通過(guò)三方系統(tǒng)，滿足對(duì)數(shù)據(jù)遷移、同步需求，在窗口期可滿足情況下，可實(shí)現(xiàn)相對(duì)的平滑。當(dāng)然最好的方式，還是在業(yè)務(wù)側(cè)通過(guò)雙發(fā)邏輯實(shí)現(xiàn)遷移。可根據(jù)業(yè)務(wù)特點(diǎn)，定制遷移方式，滿足平滑性要求。

國(guó)產(chǎn)數(shù)據(jù)庫(kù)生產(chǎn)環(huán)境基礎(chǔ)硬件架構(gòu)是怎樣的？44

國(guó)產(chǎn)數(shù)據(jù)庫(kù)自身對(duì)基礎(chǔ)硬件環(huán)境要求和國(guó)外產(chǎn)品無(wú)本質(zhì)差別。

對(duì)于分布式架構(gòu)產(chǎn)品而言，有一定特殊性，受限于其架構(gòu)特點(diǎn)，各組件對(duì)CPU、IO、NET要求各不同。例如，通常對(duì)網(wǎng)絡(luò)要求較高，分布式組件間需要大量通信；數(shù)據(jù)節(jié)點(diǎn)建議使用SSD（甚至是NVMe SSD）。

國(guó)產(chǎn)化訴求，對(duì)基礎(chǔ)環(huán)境也提出新的要求。主要是CPU方面，對(duì)ARM產(chǎn)品有部分需求。

數(shù)據(jù)庫(kù)國(guó)產(chǎn)化方案的方案可行性確認(rèn)？45

評(píng)估可行性，可從多個(gè)角度并遵循一定步驟，例如下：

理論基礎(chǔ)

聽(tīng)取廠商的理論講述，從原理上了解產(chǎn)品能力。必要時(shí)，可引入外腦幫助決策。

功能評(píng)測(cè)

可要求廠商提供基礎(chǔ)功能測(cè)試報(bào)告，同時(shí)根據(jù)自有場(chǎng)景需求，挑選有代表性場(chǎng)景進(jìn)行評(píng)測(cè)。

案例考察

考察與自有業(yè)務(wù)類(lèi)似的其他客戶(hù)進(jìn)行考察，了解其使用情況。

核心演練

針對(duì)關(guān)注的核心要點(diǎn)（如高可用、遷移、性能）等，可安排專(zhuān)項(xiàng)演練。

pg相對(duì)于mysql咋樣呢，還在猶豫到底要不要換成pg14？46

PG和MySQL代表完全不同的兩類(lèi)技術(shù)路線。相對(duì)而言，MySQL生態(tài)更為成熟，PG在部分能力上更突出。至于選擇哪一種，關(guān)鍵還是看以下幾個(gè)方面：

技術(shù)路線，是否具備或計(jì)劃將PG列為技術(shù)棧

人員儲(chǔ)備，是否具有或計(jì)劃具備相關(guān)人員

業(yè)務(wù)場(chǎng)景，對(duì)目標(biāo)庫(kù)的核心要求

技術(shù)要求，例如對(duì)Oracle兼容能力

研發(fā)能力，更為熟悉哪種技術(shù)棧，如更換需考慮成本

服務(wù)能力，PG和MySQL都是開(kāi)源產(chǎn)品，建議引入商業(yè)服務(wù)來(lái)保證穩(wěn)定，需考慮服務(wù)方