本文來自微信公眾號(hào)“twt企業(yè)IT社區(qū)”，作者/鄧毓。
完全替換路線中的分布式方案應(yīng)用場景有限、需顛覆性對(duì)應(yīng)用進(jìn)行重建、對(duì)于運(yùn)維管理工具和管理機(jī)制的改動(dòng)大，但在輕量級(jí)數(shù)據(jù)庫和分布式數(shù)據(jù)庫應(yīng)用場景下有良好的用武之地。而完全替換路線中的數(shù)據(jù)庫云化方案和平替方案，尤其是PG數(shù)據(jù)庫平替的方案，金融企業(yè)應(yīng)用場景廣泛、對(duì)應(yīng)用、運(yùn)維管理工具和機(jī)制的變動(dòng)小，更容易和更快被企業(yè)應(yīng)用系統(tǒng)大面積接受，成為去“O”主流方案。
一、引言
在企業(yè)信息系統(tǒng)中，數(shù)據(jù)庫扮演著至關(guān)重要的角色，當(dāng)前國內(nèi)無論是大型企業(yè)還是中小型企業(yè)，其核心、基礎(chǔ)、關(guān)鍵類信息系統(tǒng)的數(shù)據(jù)庫架構(gòu)仍然以傳統(tǒng)的集中式存儲(chǔ)+SAN交換機(jī)+集中式數(shù)據(jù)庫為主。隨著新技術(shù)體系的變革潮流，企業(yè)的信息系統(tǒng)架構(gòu)正逐步從IOE變革到信創(chuàng)+開源+云計(jì)算的新的技術(shù)體系。當(dāng)前變革實(shí)踐正深入開展，這當(dāng)中最困難、最復(fù)雜的變革當(dāng)屬數(shù)據(jù)庫。這不僅僅涉及數(shù)據(jù)庫自身的技術(shù)轉(zhuǎn)換，還涉及數(shù)據(jù)庫架構(gòu)相關(guān)聯(lián)的存儲(chǔ)技術(shù)和應(yīng)用數(shù)據(jù)庫開發(fā)的變換。尤其當(dāng)變革進(jìn)入企業(yè)信息系統(tǒng)深水區(qū)時(shí)，這其中牽涉的因素將越來越多，例如數(shù)據(jù)安全、數(shù)據(jù)備份、數(shù)據(jù)庫容災(zāi)、數(shù)據(jù)庫運(yùn)維、技術(shù)團(tuán)隊(duì)能力等等。因此在此背景下，如何將企業(yè)現(xiàn)有Oracle數(shù)據(jù)庫架構(gòu)穩(wěn)妥遷移至開源+信創(chuàng)融合數(shù)據(jù)庫架構(gòu)，成為企業(yè)當(dāng)前最核心最緊迫需求。
二、傳統(tǒng)數(shù)據(jù)庫架構(gòu)現(xiàn)狀及替換技術(shù)路線
企業(yè)現(xiàn)有的Oracle數(shù)據(jù)庫架構(gòu)通常有三種模式，底層均為集中式存儲(chǔ)，數(shù)據(jù)庫層為雙機(jī)熱備+Oracle數(shù)據(jù)庫模式、Oracle RAC雙活模式以及Oracle+DG讀寫分離模式。這三種模式既承載了高并發(fā)、短時(shí)延OLTP類數(shù)據(jù)庫應(yīng)用，也承載了高吞吐、大IO的OLAP類數(shù)據(jù)庫應(yīng)用。
目前存在兩種傳統(tǒng)數(shù)據(jù)庫架構(gòu)替換技術(shù)路線，一種是完全替換的方式，不考慮原有的數(shù)據(jù)庫技術(shù)架構(gòu)體系，采用全新的技術(shù)方向，如分布式數(shù)據(jù)庫+分布式存儲(chǔ)的方案，或者數(shù)據(jù)庫遷移上云（專有云或私有云）的方案，如云上的MySQL和PostgreSQL方案，徹底拋開了傳統(tǒng)的云下環(huán)境。另一種是采用“平替”的方式，是指在不重建應(yīng)用系統(tǒng)，以及不大幅度改造現(xiàn)有Oracle數(shù)據(jù)庫基礎(chǔ)架構(gòu)的前提下，以安全穩(wěn)健、TCO最優(yōu)的方式更替應(yīng)用系統(tǒng)所用的Oracle數(shù)據(jù)庫。原有的Oracle數(shù)據(jù)庫平替成了MySQL或者PostgreSQL（商用或者開源），底層的存儲(chǔ)架構(gòu)保持不變，相比完全替換的技術(shù)路線，該方式大幅減少了應(yīng)用層面的改造工作。
三、兩種技術(shù)路線方案對(duì)比
針對(duì)這兩種技術(shù)路線，哪種將成為自身企業(yè)的主流架構(gòu)，企業(yè)又該如何抉擇？這需要結(jié)合多方面因素來共同考慮。主要包括數(shù)據(jù)庫的需求因素（當(dāng)前數(shù)據(jù)庫的負(fù)載類型、性能要求、功能要求、管理要求、高可用要求等）、應(yīng)用改造或者更換因素（費(fèi)用、難度、復(fù)雜度等，涉及應(yīng)用本身及關(guān)聯(lián)的應(yīng)用系統(tǒng)兩個(gè)層面）、技術(shù)轉(zhuǎn)型因素（團(tuán)隊(duì)技術(shù)能力、技術(shù)管理能力等）、運(yùn)維管理因素（與現(xiàn)有監(jiān)控、備份、自動(dòng)化等運(yùn)維工具的契合度，以及對(duì)流程管理、應(yīng)急預(yù)案管理、容災(zāi)管理的影響等）。下面針對(duì)這兩種技術(shù)路線一一對(duì)比闡述：
1)數(shù)據(jù)庫的需求因素。考慮到傳統(tǒng)數(shù)據(jù)庫既有OLTP又有OLAP類型的工作負(fù)載，亦或是HTAP類型的混合負(fù)載。其不同的負(fù)載類型的性能要求也差異很大。采用平替方案時(shí)，應(yīng)充分考慮數(shù)據(jù)庫的應(yīng)用場景，對(duì)平替的數(shù)據(jù)庫和Oracle在不同負(fù)載類型上的性能進(jìn)行對(duì)比測試。沒有充分的測試就沒有發(fā)言權(quán)，不同負(fù)載上的性能差異取決因素太多，包括SQL調(diào)優(yōu)、參數(shù)調(diào)優(yōu)、內(nèi)核調(diào)優(yōu)、硬件、網(wǎng)絡(luò)等等，最重要的是無論是Oracle還是PG或者M(jìn)ySQL，其都有其獨(dú)特的特質(zhì)和缺點(diǎn)，但是了解什么功能適合應(yīng)用并集成這些功能最終會(huì)提高性能。因此就目前而言，Oracle并非所有應(yīng)用場景都性能優(yōu)于PG或者M(jìn)ySQL等主流開源平替方案，或者說PG在大部分應(yīng)用場景的性能可能已經(jīng)接近甚至超過了Oracle數(shù)據(jù)庫。對(duì)于完全替換的方案，有兩種情景，一種是數(shù)據(jù)庫上云，這種方式和平替方案基本類似，但需要注意測試云上塊存儲(chǔ)和專業(yè)共享存儲(chǔ)的性能差異。另一種是替換為分布式數(shù)據(jù)庫方案，首先該方案應(yīng)用場景有限，并非大部分原先的集中式的應(yīng)用場景都可以遷移或者必須遷移至分布式架構(gòu)下，分布式數(shù)據(jù)庫適用于海量的數(shù)據(jù)訪問和處理造成傳統(tǒng)的集中式數(shù)據(jù)庫開始表現(xiàn)出性能瓶頸的場景，企業(yè)這樣的場景不多，難以成為主流架構(gòu)。其次該方案對(duì)于分布式事務(wù)的實(shí)時(shí)一致性難以保證，對(duì)于像金融企業(yè)數(shù)據(jù)庫有強(qiáng)一致性要求而言，解決方案有限。
2)應(yīng)用改造或者更換因素。采用完全替換的方式可能將給應(yīng)用帶來顛覆性的改動(dòng)，相當(dāng)于應(yīng)用的重新立項(xiàng)開發(fā)，推倒重來，之前的軟硬件投入（硬件資源可能可以利舊給其他系統(tǒng)使用）無法保護(hù)，其相關(guān)聯(lián)的應(yīng)用系統(tǒng)也需要進(jìn)行相應(yīng)的接口改造和調(diào)整。通常而言，該方式只適合于企業(yè)當(dāng)前應(yīng)用系統(tǒng)功能、性能已不滿足業(yè)務(wù)需求，迫切需要進(jìn)行平臺(tái)級(jí)、技術(shù)/業(yè)務(wù)架構(gòu)級(jí)的徹底升級(jí)。當(dāng)然有一種場景是例外的，例如應(yīng)用上云的場景，原有云下的應(yīng)用+Oracle數(shù)據(jù)庫，通過應(yīng)用的少量優(yōu)化改造，匹配云上的PG等與Oracle兼容性好的數(shù)據(jù)庫，代碼基本上可以和Oracle實(shí)現(xiàn)一比一轉(zhuǎn)換。該場景要求企業(yè)擁有私有云/信創(chuàng)云戰(zhàn)略路線，數(shù)據(jù)庫上云是其戰(zhàn)略路線中的一項(xiàng)執(zhí)行行動(dòng)。而采用平替的方式的話，情況將更好，應(yīng)用可以依舊運(yùn)行在原有服務(wù)器上或者虛擬機(jī)上，存儲(chǔ)依然可以采用原有集中式存儲(chǔ)，充分保護(hù)了之前的投資，僅僅是數(shù)據(jù)庫軟件發(fā)生變化，應(yīng)用進(jìn)行微量改造，并進(jìn)行數(shù)據(jù)庫數(shù)據(jù)遷移。該方案非常適合于迭代較少、穩(wěn)定性高的應(yīng)用系統(tǒng)。因此，以應(yīng)用改造因素來衡量的話，平替的方案可能更容易和更快被企業(yè)應(yīng)用系統(tǒng)大面積接受。
3)技術(shù)轉(zhuǎn)型因素。該因素需結(jié)合企業(yè)內(nèi)部技術(shù)體系，和團(tuán)隊(duì)技術(shù)能力來考量。由于之前國內(nèi)大型互聯(lián)網(wǎng)公司去IOE化的推動(dòng)，其中實(shí)施方案中有一點(diǎn)就是將集中式的Oracle換為分布式的MySQL集群，利用MySQL可以通過水平擴(kuò)展來解決性能問題，也就是所謂的完全替換的方式。久而久之更是形成了LNMP（Linux+Nginx+MySQL+PHP）的架構(gòu)模式和生態(tài)，推廣至其他非互聯(lián)網(wǎng)企業(yè)，輿論上似乎形成了去“O”的事實(shí)標(biāo)準(zhǔn)。MySQL的技術(shù)專家也越來越多，不斷加入至企業(yè)團(tuán)隊(duì)中，MySQL技術(shù)也逐漸融入了企業(yè)的技術(shù)體系。而金融企業(yè)目前去“O”尚屬起步階段，部分非重要和邊緣系統(tǒng)也逐漸采用了MySQL系數(shù)據(jù)庫，少量采用了PG系數(shù)據(jù)庫，但大部分?jǐn)?shù)據(jù)庫主力軍依然是Oracle、SQL Server以及Db2（農(nóng)信主力）等數(shù)據(jù)庫。在這種金融企業(yè)技術(shù)體系背景下，采用MySQL完全替換或者平替的方式似乎更符合企業(yè)現(xiàn)有技術(shù)能力和生態(tài)需求。但MySQL在目前金融企業(yè)的應(yīng)用場景較窄，屬于輕量級(jí)數(shù)據(jù)庫，自身特性也不太豐富，適合業(yè)務(wù)邏輯簡單的OLTP應(yīng)用。因此，集中式MySQL的平替方案不太適合金融企業(yè)的去Oracle重型數(shù)據(jù)庫的需求，不太可能成為金融企業(yè)去“O”的主流架構(gòu)。而PG數(shù)據(jù)庫由于數(shù)據(jù)庫自身的特性非常豐富，與Oracle都屬于重型數(shù)據(jù)庫，天然適合金融應(yīng)用場景，成為去“O”主力架構(gòu)。但目前PG最大的問題是缺乏豐富的生態(tài)體系，仍需要一定時(shí)間成熟，逐漸融入企業(yè)技術(shù)體系直至被廣泛接受。
4)運(yùn)維管理因素。采用何種替換的方式也需要重點(diǎn)考慮運(yùn)維管理方面的因素。平替方案相對(duì)完全替換方案，對(duì)于生產(chǎn)的變動(dòng)和變更更小，較多的復(fù)用使得原有的運(yùn)維管理工具適配性改動(dòng)更少，對(duì)流程管理、應(yīng)急預(yù)案管理、容災(zāi)管理的影響也更輕，相應(yīng)制度或者規(guī)程的調(diào)整也更少。但這并不是徹底否認(rèn)完全替換的方案，僅僅表明運(yùn)維管理因素也應(yīng)該成為重點(diǎn)考量因素之一。例如結(jié)合企業(yè)的IT戰(zhàn)略路線，使用分布式的方案來對(duì)部分迫切需要提升性能的統(tǒng)計(jì)分析類的數(shù)據(jù)庫實(shí)現(xiàn)去“O”，進(jìn)行相關(guān)運(yùn)維管理工具的適配性改造或者重構(gòu)，運(yùn)維管理的相關(guān)機(jī)制、制度的變更等。
四、結(jié)語
通過針對(duì)完全替換和平替方案技術(shù)路線的對(duì)比，完全替換路線中的分布式方案應(yīng)用場景有限、需顛覆性對(duì)應(yīng)用進(jìn)行重建、對(duì)于運(yùn)維管理工具和管理機(jī)制的改動(dòng)大，難以成為企業(yè)主流去“O”方案，但在輕量級(jí)數(shù)據(jù)庫和分布式數(shù)據(jù)庫應(yīng)用場景下有良好的用武之地。而完全替換路線中的數(shù)據(jù)庫云化方案和平替方案，尤其是PG數(shù)據(jù)庫的方案，金融企業(yè)應(yīng)用場景廣泛，對(duì)應(yīng)用、運(yùn)維管理工具和機(jī)制的變動(dòng)小，對(duì)存儲(chǔ)硬件的投資更容易保護(hù)，更容易和更快被企業(yè)應(yīng)用系統(tǒng)大面積接受，成為去“O”主流方案。
