數(shù)據(jù)庫“去O”的選型方案

數(shù)據(jù)庫“去O”的選型方案

來自twt社區(qū)同行交流，歡迎更多同行參與交流國產(chǎn)數(shù)據(jù)庫去O，是用基于PG產(chǎn)品，還是考慮基于MySQL產(chǎn)品合適？問題來自社區(qū)會員@wanggeng某銀行系統(tǒng)運維工程師，探討來自twt社區(qū)眾多同行的分享，歡迎大家參與交流，各抒己見。*“爭議”欄目內(nèi)容來自同行分享的一手體驗和觀察，僅代表個人觀點@孔再華中國民生銀行

數(shù)據(jù)庫運維工程師：國產(chǎn)數(shù)據(jù)庫去O，當(dāng)前主要是金融行業(yè)和政企。這些用戶都是oracle等商業(yè)數(shù)據(jù)庫的深耕用戶，重度依賴數(shù)據(jù)庫的能力，甚至用了很多存儲過程來加速處理性能。那么PG產(chǎn)品和MySQL產(chǎn)品哪個合適？MySQL用的那么廣泛，是否能承擔(dān)去O的重任？從相似度來說，PG數(shù)據(jù)庫比mysql更像Oracle，無論是數(shù)據(jù)庫對象的概念，還是數(shù)據(jù)庫內(nèi)的組件概念。但是落到技術(shù)的細節(jié)上，其實每個數(shù)據(jù)庫都天差地別。MySQL基于主鍵索引組織的表，PG的追加更新存儲引擎，和Oracle相比從根子上差異就很大。所以最終還是落到用戶的使用場景上來比較。Oracle的深度用戶的應(yīng)用場景是廣泛的，基本上屬于HTAP的場景。MySQL比較適合純tp的使用場景，對于復(fù)雜sql的支持能力一直很弱。而PG相對好一點。從這點來說，如果不做sql改造調(diào)優(yōu)，PG產(chǎn)品適用性更好。在存儲過程的支持上，PG也比MySQL要好，當(dāng)然這些還是需要遷移改造的成本，并非無縫遷移。除了適用的場景外，我們還需要關(guān)注PG和MySQL的其他能力。例如產(chǎn)品的成熟度，生態(tài)的成熟度。MySQL作為簡單的數(shù)據(jù)庫，在互聯(lián)網(wǎng)企業(yè)中深度使用。因此產(chǎn)品的能力，缺陷都很清楚。周邊的生態(tài)也是MySQL要好一些，周邊工具的支持通常都會先支持MySQL。而PG在這方面相對差一些，所以出于對可靠性，穩(wěn)定性等方面的考慮，使用PG產(chǎn)品還需要時間來催熟?？偨Y(jié)一下就是這兩類產(chǎn)品都可選，摒棄弱項，選擇強項，依據(jù)業(yè)務(wù)的場景（性能，可靠性等）來選擇合適的數(shù)據(jù)庫，用得好就是好的去O數(shù)據(jù)庫。@zhangjunpoCBIT數(shù)據(jù)庫運維工程師：這個還是看自己的業(yè)務(wù)場景，PG現(xiàn)在國內(nèi)社區(qū)感覺還是不太好，但是產(chǎn)品的功能還是可以的。如果使用MySQL替換O，還得慎重考慮，MySQL只適合業(yè)務(wù)場景比較簡單的，如果數(shù)據(jù)量和業(yè)務(wù)量比較大，得分庫分表，后續(xù)維護起來比較麻煩。個人感覺，如果真要替換O，也不一定非得用PG和MySQL，也可以考慮其他國產(chǎn)數(shù)據(jù)庫，綜合考慮。@hanfeng_twt大型金融單位數(shù)據(jù)庫架構(gòu)師：在去O過程中，我們先明確一點，沒有數(shù)據(jù)庫產(chǎn)品是可以完全替代的。即完成去O工作，是需要通過“應(yīng)用改造+數(shù)據(jù)庫選型+應(yīng)用遷移”，結(jié)合在一起才能完成。這里需要考慮整體目標及路徑。問題中的兩種方式，原則上都是可以完成去O工作，但對于應(yīng)用改造及遷移的影響差異較大。1.PG類產(chǎn)品，其企業(yè)級功能較為完善，使用體感與Oracle相近。有些基于PG為內(nèi)核的產(chǎn)品，在Oracle兼容性上做了了大量工作。對用戶來說，使用上與Oracle更為相近，甚至大部分可以做到無縫遷移；少部分需要修改上，也相對工作量不大。2.MySQL類產(chǎn)品，流行程度更高，但與Oracle相比，功能差異較多。如在去O中選用，需做較大的修改。@lulihuan1987張家港行數(shù)據(jù)庫管理員：這個需要結(jié)合業(yè)務(wù)系統(tǒng)來看，如果是分析型的可以考慮基于PG的產(chǎn)品，比如GaussDB，TDSQL-PG版本，如果是交易型的可以基于MySQL的，比如TDSQL-MYSQL版本，GoldenDB等等，如果是混合負載可以考慮國產(chǎn)純自研的如TIDB，OB等等。@某金融企業(yè)數(shù)據(jù)庫工程師：去O的database應(yīng)用有選擇PG數(shù)據(jù)庫的，也有選擇MySQL的，根據(jù)應(yīng)用的特點來選吧；好像大數(shù)據(jù)量，批處理文件多，import批量數(shù)據(jù)入庫頻繁的應(yīng)用選擇PostgreSQL多，面向前臺OLTP應(yīng)用，頻繁有批量查詢的應(yīng)用選MySQL的多一點。@jillmejollytechCIO：雖然MySQL用的非常的多，特別是電商領(lǐng)域。還有很多互聯(lián)網(wǎng)大廠都喜歡用MySQL。但是我個人認為MySQL對比

PG有極其強悍的SQL編程能力。特別很多函數(shù)或者原來Oracle實現(xiàn)的語法，可以簡單遷移或者對照換個替換函數(shù)使用。但是MySQL在這方面就差了一些。

此外PG在GIS、JSON和數(shù)組等比MySQL支持的多一些。PG對插件的支持比MySQL好，可以很好的彌補和擴展功能。當(dāng)然PG的流復(fù)制與MySQL的BINLOG比還是差了不少，特別還有在電商的單筆查詢或者根據(jù)主鍵查詢，PG的性能是弱于MySQL的。主要還是看使用的場景如何。一般的說電商用MySQL分析類用PG。@某企業(yè)DBA：去O先考慮架構(gòu)優(yōu)化吧.國產(chǎn)的DB架構(gòu)復(fù)雜且重,完全不適用于普遍的煙囪式IT架構(gòu).鼓噪分布式DB的公司沒有一家有煙囪式架構(gòu)的包袱.@GBase_David

DBA：去O是重點。其實去O本來不難。難就難在業(yè)務(wù)系統(tǒng)的適配，難就難在很多很多業(yè)務(wù)系統(tǒng)和某個數(shù)據(jù)庫綁定的特別特別死，無法拆分，最終數(shù)據(jù)庫兼容性成了重點。真正數(shù)據(jù)庫要能夠解決的核心問題就是事務(wù)和并發(fā)性。無論哪個應(yīng)用開發(fā)商都應(yīng)該把業(yè)務(wù)邏輯盡最大可能的從數(shù)據(jù)庫是遷移出去。數(shù)據(jù)庫只做數(shù)據(jù)庫該做的擅長的事情即可。@annoymous技術(shù)經(jīng)理：建議看具體的場景、行業(yè)。如果是傳統(tǒng)行業(yè)，建議PGSQL。如果是互聯(lián)網(wǎng)行業(yè)，建議MySQL。@HelloWorDomai