本文來自twt企業(yè)IT社區(qū)，以下內(nèi)容來自社區(qū)會(huì)員探討。
中小銀行采用集中式數(shù)據(jù)還是分布式數(shù)據(jù)庫，哪一種合適？
目前環(huán)境下，中小銀行在數(shù)據(jù)庫選型上，采用集中式還是分布式？其優(yōu)勢(shì)和特點(diǎn)如何？
anikikong中國民生銀行數(shù)據(jù)庫運(yùn)維工程師：
我認(rèn)為集中式基本就夠用了，而且當(dāng)前最有壓力的國產(chǎn)化群體也是原來的各種集中式數(shù)據(jù)庫。中小銀行的業(yè)務(wù)場(chǎng)景大概率不需要靠分布式數(shù)據(jù)庫來解決痛點(diǎn)。未來一步到位搞云原生的數(shù)據(jù)庫就好。
jillme CIO：
集中式。
雖然說分布式的優(yōu)點(diǎn)很多，但是運(yùn)維是難度提升數(shù)個(gè)階段，且分布式事務(wù)多多少少都不是很完美。
我個(gè)人一向認(rèn)為，一百頭牛和一個(gè)大象，選擇大象而不是100個(gè)牛。
wangzk0206 scrcu數(shù)據(jù)庫管理員：
這個(gè)與銀行的總體規(guī)劃有關(guān)，是否未來要上云？以及災(zāi)備架構(gòu)方面。還有就是與各自銀行的技術(shù)儲(chǔ)備有關(guān)系。如果只是暫時(shí)使用，可以先選擇一個(gè)服務(wù)支持水平高的數(shù)據(jù)庫比較靠譜。
flywiththewind BC項(xiàng)目經(jīng)理：
1、不應(yīng)該綁定一個(gè)數(shù)據(jù)庫；
2、不能綁定一個(gè)廠商；
3、業(yè)務(wù)不同，數(shù)據(jù)庫也不同；
4、沒有最好，只有適合；
采用多步走戰(zhàn)略，不能一口吃個(gè)胖子，解決最函待解決的問題。
匿名用戶：
實(shí)際上中小銀行自己的科技力量很弱，就我們合作的幾家還算規(guī)模比較大的農(nóng)信和城商，真落到地市一個(gè)支行也就一兩個(gè)人，省里的總行也不過幾十號(hào)人，也算是大的，選幾個(gè)數(shù)據(jù)庫根本不現(xiàn)實(shí)，最好是選一個(gè)數(shù)據(jù)庫，能把運(yùn)維極大的壓縮和降低，同時(shí)還是需要原廠給予很多售后支持和研發(fā)支持的，要不然根本轉(zhuǎn)不過來。所以，中小銀行強(qiáng)烈建議數(shù)據(jù)庫選型選一家，但是要能夠面向未來至少3-5年的周期，甚至5-8年發(fā)展周期，路線要清晰，策略要堅(jiān)定，要不然隔三岔五搞一次，要搞死人。
匿名用戶：
按照本行實(shí)際情況進(jìn)行，既要保持前瞻性，也不要過度設(shè)計(jì)。建議根據(jù)實(shí)際生產(chǎn)情況和未來業(yè)務(wù)增長，與廠商進(jìn)行溝通。
zhanxuechao數(shù)字研究院咨詢專家：
天下大事，合久必分，分久必合。是集中式還是分布式主要看業(yè)務(wù)系統(tǒng)及場(chǎng)景。
我的建議中小銀行或企業(yè)，主要以業(yè)務(wù)快速變現(xiàn)為主，相比分布式傳統(tǒng)的集中式較為簡單、穩(wěn)定且成熟，建議核心系統(tǒng)集中式，周邊系統(tǒng)可嘗試分布式。
wangzimingsq88本鋼礦業(yè)公司軟件開發(fā)工程師：
具體看應(yīng)用場(chǎng)景、行業(yè)、數(shù)據(jù)庫分布情況、地理位置、存儲(chǔ)架構(gòu)形式、功能和性能要求等，從而進(jìn)行綜合決定。傳統(tǒng)核心系統(tǒng)大多采用集中式架構(gòu)的存儲(chǔ)，分布式核心系統(tǒng)多采用分布式數(shù)據(jù)庫和分布式存儲(chǔ)架構(gòu)。具體選擇哪種數(shù)據(jù)庫，要看實(shí)際應(yīng)用情況。
pysx0503系統(tǒng)工程師：
結(jié)構(gòu)化數(shù)據(jù)，IO需求高的業(yè)務(wù)用集中式，非結(jié)構(gòu)化數(shù)據(jù)，如影像，圖片存檔等用分布式。具體的選擇還是要看應(yīng)用場(chǎng)景、業(yè)務(wù)規(guī)模還有技術(shù)、資金的投入來確定。可能對(duì)于中小銀行來說沒辦法分的這么詳細(xì)，那可能就要折中一下，看哪一類的業(yè)務(wù)更重要。
annoymous金融行業(yè)：
主要看行里的整體策略。
1.要考慮整體的業(yè)務(wù)情況，要什么？如果只是為了XC那就要考慮對(duì)芯片、OS的適配，包括性能以及是否可以混合部署，畢竟業(yè)務(wù)不受影響是最關(guān)鍵的。
2.要考慮遷移成本，包括是否兼容現(xiàn)有的應(yīng)用和系統(tǒng)，這個(gè)涉及到是否要改代碼以及代碼改造量，我們遇到過舊系統(tǒng)原來的開發(fā)人員都找不到了，改系統(tǒng)是不可能的，這個(gè)時(shí)候就要考慮數(shù)據(jù)庫對(duì)現(xiàn)有應(yīng)用的兼容性。
3.考慮存儲(chǔ)和容災(zāi)，一般現(xiàn)網(wǎng)都是主備（1+1或者1+2），集中式的就還是按原來的方式繼續(xù)做，如果業(yè)務(wù)上沒有訴求的話（一般都是渠道和營銷側(cè)的訴求比較多，還有互聯(lián)網(wǎng)信貸）沒必要上分布式，但小額信貸這么好的產(chǎn)品估計(jì)沒有哪個(gè)行不做，還有多渠道和營銷訴求估計(jì)也沒有哪個(gè)行不做，所以基本上排除了傳統(tǒng)集中式，這也是為什么這么多行不論大小都在往分布式上轉(zhuǎn)的原因，再有就是要符合監(jiān)管，這個(gè)是逃不掉的，高可用，業(yè)務(wù)不中斷，數(shù)據(jù)不丟失，這個(gè)是保命的。
4.考慮整體成本，分布式目前來看如果單點(diǎn)還需要有分布式事務(wù)開銷，會(huì)有一定的成本，這就需要估算業(yè)務(wù)上來后的QPS、TPS以及各種節(jié)假日的促銷峰值，涉及到多租戶、高并發(fā)，這個(gè)是分布式的強(qiáng)項(xiàng)，要綜合算一下，投入的設(shè)備、人力的綜合成本，雖然分布式用PC服務(wù)器，但也架不入多集群，考慮利舊以及逃生。
5.最后，才是考慮未來發(fā)展，可以安生多久。
lych370系統(tǒng)運(yùn)維工程師：
問題有點(diǎn)寬泛，所謂蘿卜青菜各有所愛，具體什么數(shù)據(jù)庫適合得具體看該銀行的架構(gòu)，目前知道的大多數(shù)銀行還是基于傳統(tǒng)的Oracle rac數(shù)據(jù)庫架構(gòu)，個(gè)別的新系統(tǒng)可能會(huì)使用Tidb之類的分布式數(shù)據(jù)庫。
fcospt系統(tǒng)架構(gòu)師：
就單系統(tǒng)來說大多場(chǎng)景集中式就可以滿足需求，但從容災(zāi)、管理效率、資源利用率來看，只有分布式才能更好的集中化管理，適合更多場(chǎng)景，尤其對(duì)于小規(guī)模企業(yè)更是如此！
此庫非彼庫數(shù)據(jù)庫管理員：
如果不考慮信創(chuàng)，O的集中式架構(gòu)絕對(duì)滿足中小銀行的業(yè)務(wù)需求，再加上現(xiàn)在IO問題也隨著全閃存陣列、一體機(jī)等新硬件的性能提升得到解決。所以沒必要非要用分布式數(shù)據(jù)庫，分布式數(shù)據(jù)庫的優(yōu)勢(shì)是天然具備兩地三中心高可用容災(zāi)架構(gòu)且能處理高并發(fā)，海量數(shù)據(jù)存儲(chǔ)等場(chǎng)景，可以根據(jù)這些需求來適當(dāng)選用，當(dāng)然應(yīng)用改造成本或者適配成本就另當(dāng)別論了。
如果考慮信創(chuàng)，國產(chǎn)的集中式數(shù)據(jù)庫說實(shí)在的，外圍非核心、非交易的系統(tǒng)可以用，但是核心類和高并發(fā)的系統(tǒng)或者對(duì)穩(wěn)定性要求高的系統(tǒng)還是不建議用，畢竟國產(chǎn)數(shù)據(jù)庫才是最近十年開始大量商用起來，穩(wěn)定性和安全性還有待驗(yàn)證，且性能上面跟Oracle還是有差距，高可用MAA方面也不夠完善和成熟，如果要滿足監(jiān)管的災(zāi)備5級(jí)要求還是有難度。這種情況下核心類高并發(fā)交易類就可以嘗試選用國產(chǎn)分布式數(shù)據(jù)庫，國產(chǎn)分布式數(shù)據(jù)庫在性能和容災(zāi)方面比國產(chǎn)集中式數(shù)據(jù)庫肯定要好，而且經(jīng)過這些年的金融行業(yè)的商用，已經(jīng)得到市場(chǎng)的認(rèn)可，主流的幾個(gè)分布式數(shù)據(jù)庫在金融行業(yè)已經(jīng)都有很多成熟案例。不過，確實(shí)存在分布式數(shù)據(jù)庫運(yùn)維復(fù)雜度的提升和應(yīng)用改造成本較大的問題，具體根據(jù)各家銀行的情況來定。
您怎么看？
歡迎來探討
