國產(chǎn)分布式數(shù)據(jù)庫與Oracle架構(gòu)與成本分析

來自twt社區(qū)同行交流，歡迎更多同行參與交流國產(chǎn)分布式數(shù)據(jù)庫，在成本上是否如宣傳的那樣比Oracle有較大的優(yōu)勢？問題來自社區(qū)會員@huawei851120江蘇省農(nóng)村信用社聯(lián)合社系統(tǒng)工程師，探討來自twt社區(qū)眾多同行的分享，歡迎大家參與交流，各抒己見。*“爭議”欄目內(nèi)容來自同行分享的一手體驗和觀察，僅代表個人觀點@hanfeng_twt大型金融單位數(shù)據(jù)庫架構(gòu)師：采用分布式數(shù)據(jù)庫的成本來自幾個方面：1.軟件授權(quán)費用，這部分相對有一定優(yōu)勢，Oracle原廠費用較高。2.軟件服務費用，這部分相對國產(chǎn)庫較高，因為成熟度不足，還需大量人力投入且還未形成成熟的服務生態(tài)。3.硬件采購費用，這部分分布式國產(chǎn)庫較高，因為涉及的組件較多，需耗費機器資源較多。4.日常維護費用，這部分國產(chǎn)庫較高，因需重新搭建隊伍，新增人力成本較高。@luxh08某互聯(lián)網(wǎng)銀行科技部門副總：以我們實際經(jīng)驗告訴大家，成本還是需要對比。首先說硬件成本，假設之前Oracle你跑在兩臺小型機上，外帶一個中端存儲，加起來怎么200W起，現(xiàn)在用分布式數(shù)據(jù)庫，使用了9臺服務器，成本50w，性能還比之前強了，這種情況分布式數(shù)據(jù)庫絕對是節(jié)約成本。如果之前用兩臺PC服務器，性能沒有問題，容量沒有問題，那又何必非采用分布式數(shù)據(jù)庫，替換成單機國產(chǎn)數(shù)據(jù)庫也可以，分布式數(shù)據(jù)庫硬件成本是數(shù)據(jù)庫本身架構(gòu)決定的，分布式造成節(jié)點眾多。第二是運維成本，分布式數(shù)據(jù)庫應用門檻還是很高的，首先要求有數(shù)據(jù)庫的標準化和輕量化要做夯實，如果沒有深厚的數(shù)據(jù)庫自身能力，依賴廠商進行分布式數(shù)據(jù)庫實施和運維，那和之前用Oracle有什么區(qū)別？還是采用之前的商業(yè)模式，只不過是換了一個產(chǎn)品，打走了豺狼迎來了老虎。我們實際應用案例來說，我們采用了國產(chǎn)分布式數(shù)據(jù)庫造成了服務器數(shù)量增多，但是之前單機架構(gòu)兩臺服務器已經(jīng)滿足不了業(yè)務的處理性能要求，所以硬件成本不是更換數(shù)據(jù)庫造成的，而是為了滿足業(yè)務性能要求橫向擴展增加的。目前我們們分布式數(shù)據(jù)已經(jīng)大規(guī)模應用，我們做了很多準備工作，從17年成立開始一直采用MySQL數(shù)據(jù)庫標準，對數(shù)據(jù)庫規(guī)范和標準執(zhí)行的非常徹底，存儲過程、觸發(fā)器、特殊函等通通不讓使用，數(shù)據(jù)庫已經(jīng)非常輕量，我們之前已經(jīng)積累了數(shù)據(jù)庫自主可控技術能力，所以用分布式數(shù)據(jù)庫水到渠成。@孔再華中國民生銀行數(shù)據(jù)庫運維工程師：國產(chǎn)分布式數(shù)據(jù)庫與Oracle數(shù)據(jù)庫差異最大最值得關注的其實不應該是成本這塊。因為分布式數(shù)據(jù)庫與Oracle數(shù)據(jù)庫的技術特點不一樣，主打的應用場景不一樣，這才是最大的區(qū)別。僅僅從成本角度，Oracle的單元計價肯定是要比分布式數(shù)據(jù)庫貴的，但是分布式數(shù)據(jù)庫分布的機器多，而且每家客戶對于不同數(shù)據(jù)庫的最終談判價格差異很大，尤其是大客戶。硬件成本上，通常分布式數(shù)據(jù)庫不會只服務于一個系統(tǒng)，通常會采用多租戶的方式服務多套系統(tǒng)。而Oracle數(shù)據(jù)庫一般不會這么做。算上兩地三中心的硬件冗余情況，這方面分布式數(shù)據(jù)庫是有可能節(jié)省成本的。但是分布式數(shù)據(jù)庫也有自身缺陷，那就是分布式事務會存在性能瓶頸，跨節(jié)點大數(shù)據(jù)量查詢需要盡量避免，所以不是所有的應用場景都適合。我們將分布式數(shù)據(jù)庫定義為解決單點高并發(fā)，數(shù)據(jù)量大需要分片擴展的場景問題，并不會作為Oracle的大規(guī)模替代產(chǎn)品。未來云原生的數(shù)據(jù)庫才是整合資源替代傳統(tǒng)數(shù)據(jù)庫的方向。分布式數(shù)據(jù)庫的管理成本也比較高，因為組件較多技術復雜。未來擴容等需求也相對難做，需要很好的規(guī)劃。所以我的觀點是分布式數(shù)據(jù)庫可用，用在特定場景。替換Oracle的成本和運行維護成本未必會有大的下降。@lulihuan1987張家港行數(shù)據(jù)庫管理員：目前分布式數(shù)據(jù)庫在銀行的各個關鍵業(yè)務系統(tǒng)都有落地案例，例如核心系統(tǒng)、線上渠道整合（手機銀行、網(wǎng)銀）、互聯(lián)網(wǎng)金融（直銷銀行、聚合支付、移動信貸）系統(tǒng)，所以現(xiàn)在分布式數(shù)據(jù)庫的選型時，一定是要讓其運行在行內(nèi)關鍵業(yè)務系統(tǒng)之上，而且能夠滿足大部分行內(nèi)業(yè)務系統(tǒng)的遷移需求，這樣的前提下對比成本才更有意義：1）硬件投入對比：分布式數(shù)據(jù)庫通常都是通用X86或者ARM服務器，集中式數(shù)據(jù)庫通常需要高端小型機、SAN、高端存儲以及存儲雙活同步等，考慮集群加災備，基本上是要考慮三套。硬件成本投入的優(yōu)勢比較大。2）數(shù)據(jù)庫軟件授權(quán)對比。3）應用適配投入（改造成本）：這塊集中式數(shù)據(jù)庫比較有優(yōu)勢，應用適配分布式數(shù)據(jù)庫的改造可能會增加費用。4）咨詢和測試投入：基本差別不大。5）運維投入：分布式數(shù)據(jù)庫通常自帶自動化運維平臺，是不是需要另外采購，看商務，集中式數(shù)據(jù)庫運維工具和平臺可能需要額外采購；至于運維人員的培養(yǎng)，筆者認為做核心必須在整個過程中培養(yǎng)幾個對分布式數(shù)據(jù)庫掌握程度非常高的DBA，這塊應該算成本，不算投入。6）后續(xù)擴容：最好要在初期就要明確，各家差別也比較大?；痉植际綌?shù)據(jù)庫的投入肯定是要低于集中式數(shù)據(jù)庫的，互聯(lián)網(wǎng)企業(yè)早期去O的重要原因就是成本投入驅(qū)動。當然，金融行業(yè)國產(chǎn)化進程會越來越快，安全自主可控越來越重要。@潘延晟系統(tǒng)工程師：其實我覺得首要成本化數(shù)據(jù)庫要考慮的應該是安全問題，特別是通過這次俄烏克沖突，估計也會加速中國重點行業(yè)的國產(chǎn)化進程。了解過某國產(chǎn)數(shù)據(jù)庫，成本上確實應該還是比Oracle有優(yōu)勢的。不過畢竟項目之間的對比不是那么明確，這個成本的所謂高低也很難去有一個標準去衡量。不能說Oracle的報價600萬，國產(chǎn)化數(shù)據(jù)庫報價500萬或者400萬你覺得沒達到心理預期，這些都要具體看項目的情況。所以成本問題我覺得應該是一個次要問題，首要考慮的是所在的行業(yè)是否是重點行業(yè)。國產(chǎn)化的數(shù)據(jù)庫是否能夠滿足業(yè)務需求、穩(wěn)定運行。其次價格上能便宜當然最好。@某科技公司

系統(tǒng)架構(gòu)師：首先這個問題從業(yè)務場景出發(fā)，集中式和分布式的場景不同。分布式DB例如TIDB，需要多臺機器，單臺機器成本肯定比Oracle便宜，集群成本不好說。大多數(shù)企業(yè)都是從Oracle中下線后上到了TIDB或者OB中。分布式架構(gòu)和集中架構(gòu)不同，運維起來差別不小。@王巧雷sino-bridge系統(tǒng)工程師：新環(huán)境的成本主要包括硬件成本，軟件許可，后期運維等方面，這個相對好計算一點。一般來說硬件方面分布式會比Oracle的費用多一些，這個是架構(gòu)本身的原因?qū)е碌?；軟件許可，Oracle的單價比較高；后期運維，目前Oracle的生態(tài)比較占優(yōu)勢，不管是甲方自己的技術儲備，還是廠商、第三方的服務市場，都很成熟了，國產(chǎn)分布式還在起步階段，主要依靠原廠，自建團隊也需要一個過程。舊環(huán)境的遷移，還面臨著遷移成本，比如應用的改造適配，測試等方面。有些應用在規(guī)劃設計階段，下沉到數(shù)據(jù)庫層的部分過多，很多應用邏輯通過數(shù)據(jù)庫層實現(xiàn)，比如存儲過程、觸發(fā)器等，導致應用遷移涉及的改造部分會比較多，牽扯比較大的人力物力投放，涉及到應用、數(shù)據(jù)庫、開發(fā)測試等，這些都是需要考慮的部分。@趙海

技術經(jīng)理：使用Oracle數(shù)據(jù)庫，可