國產(chǎn)數(shù)據(jù)庫應(yīng)用實踐三大難點剖析總結(jié)

企業(yè)國產(chǎn)數(shù)據(jù)庫應(yīng)用實踐問題及難點剖析總結(jié)導(dǎo)讀傳統(tǒng)企業(yè)現(xiàn)在的系統(tǒng)絕大多數(shù)還是運行在Oracle，DB2等國外商業(yè)數(shù)據(jù)庫上，隨著近些年來數(shù)據(jù)庫的變化，正有越來越多的企業(yè)面臨將傳統(tǒng)數(shù)據(jù)庫遷移到開源或新型商業(yè)產(chǎn)品上才能實現(xiàn)自主可控的目標。然而不同數(shù)據(jù)庫的特性有差別，SQL語法也有很多差異，因此在遷移數(shù)據(jù)庫的過程中不僅涉及數(shù)據(jù)的遷移，還包括應(yīng)用的適配改造。首先，從傳統(tǒng)集中式數(shù)據(jù)庫遷移到國產(chǎn)分布式數(shù)據(jù)庫，異構(gòu)的兩種數(shù)據(jù)庫差別非常大，計算方式、數(shù)據(jù)存儲、架構(gòu)設(shè)計都區(qū)別較大，系統(tǒng)遷移時往往涉及大量的表結(jié)構(gòu)設(shè)計調(diào)整、業(yè)務(wù)重構(gòu)、應(yīng)用改造，同時給數(shù)據(jù)遷移帶來了一定困難；其次，分布式數(shù)據(jù)庫多節(jié)點設(shè)計給全局一致性的實現(xiàn)帶來了一定的要求和難度，分布式數(shù)據(jù)庫如果不實現(xiàn)全局一致，可能會帶來跨節(jié)點任務(wù)的數(shù)據(jù)不一致性問題（當然，這個問題可以通過應(yīng)用改造去規(guī)避，但是對業(yè)務(wù)的侵入性較大）；最后，應(yīng)用適配分布式數(shù)據(jù)庫，不僅僅是SQL語法語義層面的轉(zhuǎn)換，還會涉及到業(yè)務(wù)的優(yōu)化，應(yīng)用架構(gòu)優(yōu)化等等方面。所以，圍繞“國產(chǎn)數(shù)據(jù)庫數(shù)據(jù)分片和遷移難點實現(xiàn)”、“全局一致性難點實現(xiàn)”以及“應(yīng)用改造難點實現(xiàn)”三個方面，本期論壇組織了“國產(chǎn)數(shù)據(jù)庫應(yīng)用實踐難點線上核心探討”，特邀請了金融企業(yè)有國產(chǎn)數(shù)據(jù)庫實踐經(jīng)驗的專家，針對以上三個方面進行了充分的討論，現(xiàn)將交流內(nèi)容和精彩回答整理如下，以供大家學(xué)習(xí)交流。執(zhí)筆專家盧麗歡數(shù)據(jù)庫自主可控用戶委員會委員云原生應(yīng)用創(chuàng)新實踐聯(lián)盟——數(shù)據(jù)庫自主可控方向課題組專家。長期從事數(shù)據(jù)庫尤其是分布式數(shù)據(jù)庫應(yīng)用實踐工作，具備銀行核心系統(tǒng)、互聯(lián)網(wǎng)聚合支付系統(tǒng)、信貸系統(tǒng)、中間業(yè)務(wù)等銀行關(guān)鍵業(yè)務(wù)系統(tǒng)采用國產(chǎn)分布式數(shù)據(jù)庫落地實踐經(jīng)驗。協(xié)作專家苑華偉數(shù)據(jù)庫自主可控用戶委員會委員云原生應(yīng)用創(chuàng)新實踐聯(lián)盟——數(shù)據(jù)庫自主可控方向課題組專家。計算機碩士學(xué)歷，從事生產(chǎn)運維10余年，被國際災(zāi)備協(xié)會授予大師級業(yè)務(wù)連續(xù)性管理專家（MBCP）認證。先后從事IBM主機系統(tǒng)管理員、災(zāi)備管理員、ESB管理員、中間件管理員、數(shù)據(jù)庫管理員等工作。擅長災(zāi)備建設(shè)與演練、MQ中間件運維管理、國產(chǎn)數(shù)據(jù)庫運維管理工作。韓鋒數(shù)據(jù)庫自主可控用戶委員會委員云原生應(yīng)用創(chuàng)新實踐聯(lián)盟——數(shù)據(jù)庫自主可控方向課題組專家。有著豐富的一線數(shù)據(jù)庫架構(gòu)、軟件研發(fā)、產(chǎn)品設(shè)計、團隊管理經(jīng)驗。曾擔任多家公司首席DBA、數(shù)據(jù)庫架構(gòu)師等職。在云、電商、金融、互聯(lián)網(wǎng)等行業(yè)均有涉獵，精通多種關(guān)系型數(shù)據(jù)庫，對NoSQL及大數(shù)據(jù)相關(guān)技術(shù)也有涉足，實踐經(jīng)驗豐富。曾著有數(shù)據(jù)庫相關(guān)著作《SQL優(yōu)化最佳實踐》、《數(shù)據(jù)庫高效優(yōu)化》。李建明數(shù)據(jù)庫自主可控用戶委員會委員云原生應(yīng)用創(chuàng)新實踐聯(lián)盟——數(shù)據(jù)庫自主可控方向課題組專家。擅長基礎(chǔ)架構(gòu)規(guī)劃和管理，尤其擅長全棧式性能優(yōu)化，將基于云計算+微服務(wù)+OceanBase技術(shù)棧的新一代分布式架構(gòu)核心系統(tǒng)性能優(yōu)化到8000tps；在數(shù)據(jù)庫方面有豐富的經(jīng)驗，熟悉informix、oracle、elasticsearch、oceanbase等數(shù)據(jù)庫。一、國產(chǎn)數(shù)據(jù)庫數(shù)據(jù)分片和遷移難點實現(xiàn)1、建表基本問題：結(jié)合銀行業(yè)務(wù)系統(tǒng)改造案例，介紹下如何進行表容量規(guī)劃？【問題描述】建表時需要考慮表的容量，該表常用SQL以及字段類型選擇，請結(jié)合銀行業(yè)務(wù)系統(tǒng)改造案例，介紹下如何進行表容量規(guī)劃，該表常用SQL的提取分析，以及字段類型選擇的注意點（主要是字段長度較長的情況）等。專家建議：韓鋒數(shù)據(jù)庫自主可控用戶委員會委員：1.表容量的規(guī)劃這一問題本質(zhì)是數(shù)據(jù)對象的生命周期管理，針對數(shù)據(jù)對象在生命周期內(nèi)的創(chuàng)建、增、刪、改及歸檔銷毀等做到前期規(guī)劃。根據(jù)數(shù)據(jù)訪問特征，對表內(nèi)數(shù)據(jù)量的變化做到預(yù)測評估，盡量在早期階段對表做好分片、分區(qū)、歸檔策略等規(guī)劃。2.常用SQL提取分析對數(shù)據(jù)對象的訪問，SQL是主要的方式。需要定期分析SQL，提升訪問效率。對表的訪問往往是比較多元的，需要區(qū)分業(yè)務(wù)與非業(yè)務(wù)、常規(guī)與非常規(guī)、定期與隨機、高頻與低頻等SQL訪問特征。優(yōu)先處理業(yè)務(wù)、常規(guī)、定期、高頻的SQL。提取方法是有很多，很多平臺也都提供了相應(yīng)工具完成提取和分析的工作。3.字段類型選擇關(guān)于字段類型的選擇上，可本著如下原則：-

盡量使用簡單字段類型，針對如LOB、JSON等類型減少使用-

選擇合適的數(shù)據(jù)類型（如日期就選擇日期類型，而非數(shù)字或字符）和適當?shù)木?

對于超長的數(shù)據(jù)，原則上不建議在數(shù)據(jù)庫內(nèi)存儲，可通過外置方式保存。xiamx

某農(nóng)商行

DBA：字段類型選擇通常都用varchar,字段長度固定的情況才使用char，日期就用日期，文檔圖片類型用lob；你的問題不太明確，不清楚你在哪些字段抉擇上遇到問題。表容量問題和業(yè)務(wù)情況息息相關(guān)，通常只計算流水、交易記錄等量大的表，三年未能達到千萬級的表通常不考慮。而這些量大的數(shù)據(jù)通常有生命周期，保留三年或者五年，需要根據(jù)業(yè)務(wù)去估算周期內(nèi)的行數(shù)，在乘以1.2~1.8進行預(yù)留，行數(shù)和所占空間的比例需要測試才能知道結(jié)果，最終能估算出所需的空間。2、結(jié)合銀行關(guān)鍵業(yè)務(wù)系統(tǒng)表類型如何設(shè)計，重點表分別選擇了什么類型的表？【問題描述】分布式數(shù)據(jù)庫里有廣播表（每個數(shù)據(jù)節(jié)點都有全量）、分片表（每個數(shù)據(jù)節(jié)點存儲部分數(shù)據(jù)）以及普通表（僅存在于某個數(shù)據(jù)節(jié)點），請結(jié)合銀行關(guān)鍵業(yè)務(wù)系統(tǒng)案例，介紹該系統(tǒng)表類型如何設(shè)計，重點表分別選擇了什么類型的表？專家建議：韓鋒

數(shù)據(jù)庫自主可控用戶委員會委員：選擇表的類型，還是根據(jù)表的使用特征來分析。1.廣播表：適合于低頻修改，高頻查詢的場景2.分片表：適合于數(shù)據(jù)規(guī)模大，需要數(shù)據(jù)拆分的場景3.普通表：適合于需精確控制存儲位置或者使用頻率很低，性能要求不高的情況盧麗歡數(shù)據(jù)庫自主可控用戶委員會委員：廣播表（每個數(shù)據(jù)節(jié)點都有全量）：小表廣播，數(shù)據(jù)量不大，經(jīng)常關(guān)聯(lián)但更新較少的場景，比如參數(shù)表，像機構(gòu)表、利率表、產(chǎn)品表等；分片表（每個數(shù)據(jù)節(jié)點存儲部分數(shù)據(jù)）：除小表廣播以外的其他業(yè)務(wù)相關(guān)的表，建議均采用分片表，以確保分布式數(shù)據(jù)庫的性能和擴展性，例如賬戶信息表、客戶信息表、交易信息表等等；普通表（僅存在于某個數(shù)據(jù)節(jié)點）：不具備可擴展性，所以業(yè)務(wù)表不建議使用，除非是一些特點場景，比如一些臨時表，數(shù)據(jù)量也不少特別大的可以使用。3、結(jié)合銀行關(guān)鍵業(yè)務(wù)系統(tǒng)介紹下分片字段選擇的原則？【問題描述】分片字段選擇是分布式數(shù)據(jù)庫適配的關(guān)鍵，關(guān)系到數(shù)據(jù)的分布，查詢的效率，以及擴展性，請結(jié)合銀行關(guān)鍵業(yè)務(wù)系統(tǒng)案例，介紹下分片字段選擇的原則，重點表如何選取分片字段?？梢院汀氨眍愋瓦x擇”問題聯(lián)合進行介紹。專家建議：xiamx某農(nóng)商行DBA：這個問題是要和該表適不適合做分表、其他相關(guān)聯(lián)表的分片字段一起討論的。通常做分表的數(shù)據(jù)量一定是足夠大才考慮的，如果數(shù)據(jù)量小，就算有良好的分片字段，也沒有做分片的必要，可以考慮做成廣播表或單表。

這樣就可以規(guī)避掉很多分片字段的選擇場景。分布式數(shù)據(jù)庫在分表之間關(guān)聯(lián)時，如果關(guān)聯(lián)字段不是分片字段，則會引發(fā)數(shù)據(jù)上拉進行跨分片關(guān)聯(lián)，性能損耗極大。因此在選擇分片字段依據(jù)并且只依據(jù)關(guān)聯(lián)分表的分片字段情況。首先定好分片基調(diào)，例如銀行系統(tǒng)通常選擇是賬號或卡號，將所有與賬戶關(guān)聯(lián)的分表全部按業(yè)務(wù)邏輯的賬號或卡號的字段進行分片，便于與賬戶主表的關(guān)聯(lián)。對于其他的分表，則根據(jù)關(guān)聯(lián)查詢的表一起協(xié)定用一個字段做分片，盡可能統(tǒng)一。如果一個分表同時要和兩個分表做關(guān)聯(lián)，且關(guān)聯(lián)字段不同，解決思路:1.該表能否做成廣播表;2.是否能改查詢邏輯，與其中一個分表不做直接關(guān)聯(lián)。如果分表沒有關(guān)聯(lián)其他表，字段選擇優(yōu)先能夠讓數(shù)據(jù)均勻分布到各個分片上的字段，通常選唯一主鍵。韓鋒

數(shù)據(jù)庫自主可控用戶委員會委員：分片字段的選擇，需涉及的因素很多，可大致分為以下幾個方面：1.數(shù)據(jù)結(jié)構(gòu)主鍵或唯一索引字段是否要包含如分片字段。很多數(shù)據(jù)庫叢唯一性校驗，是必須要求包含分片鍵在其中，否則無法完成校驗工作。索引字段對分片字段的選擇上，沒有直接影響。對于全局索引的，可考慮通過二級索引表的方式解決；對于普通索引，則可以在分片基礎(chǔ)上做本地索引。字段類型，選擇適合分片的字段作為分片鍵。常見的分片類型包括有數(shù)字、日期、文本等。2.數(shù)據(jù)特征表規(guī)模，是是否使用分片的關(guān)鍵因素之一。表做了分片后，勢必會造成一定的“功能退化”，如能采取其他方式縮小表的大小，盡量采用?？赏ㄟ^表的全生命周期規(guī)劃，如常規(guī)的數(shù)據(jù)歸檔、壓縮、轉(zhuǎn)儲、清理策略，減少數(shù)據(jù)量。此外，數(shù)據(jù)庫內(nèi)置的如表分區(qū)、垂直分表等策略也可以有效減小表的大小。數(shù)據(jù)離散度，按某個字段或字段組合后，表的數(shù)據(jù)是否足夠分散。數(shù)據(jù)分片的初衷就是減少表的規(guī)模，盡量做到數(shù)據(jù)打散是其根本原則之一。這里需要統(tǒng)計數(shù)據(jù)拆分后離散程度，盡量選擇能充分打散的字段作為分片鍵。這里需注意，如果選擇字段是帶有業(yè)務(wù)特征，還要關(guān)注未來業(yè)務(wù)變化對它的影響。3.訪問特征可變化性，選擇相對固定、不再變化的字段作為分片鍵。雖然有些數(shù)據(jù)庫也支持分片鍵的修改，但畢竟修改后會涉及數(shù)據(jù)移動，成本代價很高；還是優(yōu)選不變的字段為好。事務(wù)隔離，盡量選擇按字段拆分后的數(shù)據(jù)，對數(shù)據(jù)的變化處理可集中在分片內(nèi)解決。這樣大量的業(yè)務(wù)變化是可以通過Local的事務(wù)完成，開銷比全局的要小很多，效率也高。關(guān)聯(lián)字段，如后續(xù)此表與其他關(guān)聯(lián)表經(jīng)常聯(lián)合使用，優(yōu)先那些參與到關(guān)聯(lián)操作的字段為佳。盡量是數(shù)據(jù)在關(guān)聯(lián)后，能在本地完成Join的動作，減少數(shù)據(jù)Shuffle或上移匯聚類的操作。4.其他因素如涉及到多個字段作為分片鍵的話，還需考慮如字段順序等問題。4、國產(chǎn)分布式數(shù)據(jù)庫如何解決計算下沉的問題，是否有一些通用的規(guī)則？專家建議：盧麗歡數(shù)據(jù)庫自主可控用戶委員會委員：分布式數(shù)據(jù)庫數(shù)據(jù)下沉屬于數(shù)據(jù)庫查詢算法優(yōu)化的范疇，對于我們使用者來說，盡可能在數(shù)據(jù)庫表設(shè)計的時候合理設(shè)計，例如分片字段的設(shè)計，廣播表的使用，增加冗余字段作為分區(qū)建，查詢時減少關(guān)聯(lián)層級，盡可能使用分區(qū)建關(guān)聯(lián)，才能達到較好的性能。5、分布式數(shù)據(jù)庫的通用分片規(guī)則參考的因素有哪些，分別如何評估和取舍，是否有統(tǒng)一的方法論？專家建議：lych370

北銀金科

系統(tǒng)運維工程師：分片分為橫向和縱向，一般都選擇橫向分片，按照一個統(tǒng)一的字段進行分片，按照數(shù)據(jù)量的大小，分片字段建議重復(fù)值少，便于索引，通常選擇編號類的主鍵進行分片，分片不建議太多，適量就行，要考慮檢索的速度和后期的擴展性。一般很少有人用縱向分片，主要是因為目前的數(shù)據(jù)結(jié)構(gòu)化原因，縱向類似業(yè)務(wù)的分庫分表，代價大，難度高苑華偉數(shù)據(jù)庫自主可控用戶委員會委員：說句實在話，Oracle也好，DB2也好，其實功能非常豐富，但是我們能用的功能非常少。用的功能越簡單，越不會出問題。國產(chǎn)分布式數(shù)據(jù)庫也是的，進行分片，別搞那些千奇百怪的，什么自定義分片規(guī)則、三級分片、分片之后再分片的多級分片之類的看起來很高端，復(fù)雜容易出問題。就是最簡單的，哈希，或者范圍（Range）。如果這兩種搞不定，這套系統(tǒng)就先不要搞分布式改造！?。。。。。≌娴?，越簡單越好！6、在表結(jié)構(gòu)，業(yè)務(wù)重構(gòu)的情況下，如何進行數(shù)據(jù)遷移，確保安全準確？【問題描述】數(shù)據(jù)遷移難題：這里的重點不討論遷移工具，討論落地遷移方案，確保數(shù)據(jù)遷移的準確性，尤其是在表結(jié)構(gòu)，業(yè)務(wù)重構(gòu)的情況下，如何進行數(shù)據(jù)遷移，確保安全準確。請結(jié)合銀行關(guān)鍵業(yè)務(wù)系統(tǒng)案例，介紹下數(shù)據(jù)遷移的方案。專家建議：韓鋒

數(shù)據(jù)庫自主可控用戶委員會委員：數(shù)據(jù)遷移的方案，從大的分類上有三種：1.基于數(shù)據(jù)的邏輯遷移這種方式的適配范圍更廣，適配場景多，但遷移效率一般較差其對庫表結(jié)構(gòu)有要求。2.基于日志的物理遷移這種方式的實時性較高，但需做更多的適配性工作。3.基于應(yīng)用的數(shù)據(jù)遷移這種方式屬于定制方案，需要應(yīng)用側(cè)解決數(shù)據(jù)遷移問題。效率中等，可加入定制策略。在保證數(shù)據(jù)安全方面，可通過數(shù)據(jù)校驗完成。一般的遷移都支持離線的校驗，原理是通過某種算法對部分或全部字段實現(xiàn)校驗；或者通過采樣統(tǒng)計的方式完成。二、全局一致性難點實現(xiàn)1、金融企業(yè)應(yīng)用分布式數(shù)據(jù)庫全局強一致性與性能取舍，這方面問題如何考慮？【問題描述】提供全局強一致性校驗的分布式數(shù)據(jù)庫，能夠達到集中式數(shù)據(jù)庫那樣的強一致性需求，但是相應(yīng)也會帶來性能的損失，而有的業(yè)務(wù)系統(tǒng)為了確保性能，通過業(yè)務(wù)改造和數(shù)據(jù)庫設(shè)計，弱化強一致性要求，即使全局最終一致性也能滿足業(yè)務(wù)需求。那么，堅持開啟全局強一致，還是關(guān)閉全局強一致，通過改造規(guī)避影響？結(jié)合銀行核心、信用卡、互聯(lián)網(wǎng)金融系統(tǒng)等關(guān)鍵業(yè)務(wù)系統(tǒng)改造案例，介紹該方面的問題是如何考慮的？專家建議：盧麗歡數(shù)據(jù)庫自主可控用戶委員會委員：從分布式數(shù)據(jù)庫的角度看，全局強一致性開啟后會由專門的組件負責(zé)全局事務(wù)的管理，在數(shù)據(jù)查詢時也需要判斷數(shù)據(jù)的提交狀態(tài)，對于存在大量分布式事務(wù)兩階段提交場景的應(yīng)用，會有一定的查詢性能的下降，大概會下降10%左右。從分布式數(shù)據(jù)庫的發(fā)展來看，全局強一致性是必要的功能，起碼把開啟和關(guān)閉的權(quán)限交由客戶決定，通過提高全局事務(wù)管理組件的性能和高可用，可以緩解性能下降的問題，對于事務(wù)較小的交易，例如單事務(wù)的平均SQL數(shù)量在100以內(nèi)的交易，開啟強一致性查詢帶來的性能損耗是完全可以接受的，而對于單事務(wù)的平均SQL數(shù)量在300以上的交易，那么開啟后帶來的性能損耗客戶是有一點感知的，一個交易應(yīng)用和數(shù)據(jù)庫進行300次以上的交互，其中網(wǎng)絡(luò)、數(shù)據(jù)庫的耗時加起來，交易耗時可能達到500ms以上。當然這個問題也可以通過將事務(wù)改造成小事務(wù)來解決問題，當然也會給應(yīng)用的改造帶來一定負擔。現(xiàn)階段的情況來看，建議業(yè)務(wù)遷移分布式數(shù)據(jù)庫時原則上是開啟全局強一致性，通過優(yōu)化抵消開啟的損耗。李建明數(shù)據(jù)庫自主可控用戶委員會委員：“分庫分表”類型的分布式數(shù)據(jù)庫一般采用強同步的方式實現(xiàn)寫一致性，可用性較差，而原生分布式數(shù)據(jù)庫一般采用Paxos/Raft等多節(jié)點同步一致性的技術(shù)，可用性較好。此外“分庫分表”類型的分布式數(shù)據(jù)庫，應(yīng)用在不知道數(shù)據(jù)的分片鍵的情況下，需要對所有主庫發(fā)起SQL，導(dǎo)致性能較差；為提高系統(tǒng)性能，在操作數(shù)據(jù)時應(yīng)用需要帶上分片鍵，使得對應(yīng)用的改造量很大。韓鋒

數(shù)據(jù)庫自主可控用戶委員會委員：是否啟用強一致性，主要取決于業(yè)務(wù)架構(gòu)。針對全局強一致是剛需，絕大部分業(yè)務(wù)都是需要的。只有當業(yè)務(wù)做過單元化改造，也做到局部的業(yè)務(wù)閉環(huán)下可考慮關(guān)閉全局一致，提升效率。苑華偉數(shù)據(jù)庫自主可控用戶委員會委員：本次回答是基于2022年國產(chǎn)數(shù)據(jù)庫的發(fā)展階段進行。對于金融行業(yè)，保證分布式數(shù)據(jù)庫的強一致性是金融企業(yè)的首選。尤其對于銀行業(yè)來說，哪怕不是核心系統(tǒng)，也不是什么重要系統(tǒng)，就是重要等級一般但是交易并發(fā)量高的系統(tǒng)。保證分布式數(shù)據(jù)庫的強一致性，仍然是首選。至于性能方面的取舍，我不認為這是個問題。如果有問題的話，可能是某家銀行引進的國產(chǎn)分布式數(shù)據(jù)庫，還不夠成熟穩(wěn)定，或者用的不是國內(nèi)頭部幾家大廠的分布式數(shù)據(jù)庫產(chǎn)品。我們想想，MySQL開源社區(qū)版，很多商業(yè)銀行用MySQL既能保障數(shù)據(jù)庫的強一致性，也能支持一定的并發(fā)。如果花錢用了某款商用的國產(chǎn)分布式數(shù)據(jù)庫（很可能是基于MySQL改進的），性能反而不如MySQL，或者沒法保障事務(wù)的強一致性了。那我只能說：1，別玩了，換頭部廠家的國產(chǎn)分布式數(shù)據(jù)庫吧。個別銀行的核心系統(tǒng)的數(shù)據(jù)庫已經(jīng)完成了國產(chǎn)化改造，已經(jīng)實現(xiàn)了超高并發(fā)的同時解決了強一致性的問題。這個問題的提出可能是客戶用到了不夠成熟的產(chǎn)品。2，可能真的是這個系統(tǒng)的交易量太大，那就再等等，先別拿這個系統(tǒng)的數(shù)據(jù)庫做國產(chǎn)化改造，再等等。先改造交易量小、并發(fā)低的系統(tǒng)，等兩年再看看，那時候再根據(jù)國產(chǎn)數(shù)據(jù)庫的發(fā)展情況對這個高并發(fā)系統(tǒng)開展國產(chǎn)化改造。2、分布式實例一致性備份恢復(fù)如何實現(xiàn)？低效率SQL如何快速定位？【問題描述】自動化運維：自動化運維的關(guān)注點有哪些？運維工具選擇與行內(nèi)現(xiàn)有平臺的結(jié)合？分布式實例一致性備份恢復(fù)如何實現(xiàn)？低效率SQL如何快速定位？專家建議：盧麗歡數(shù)據(jù)庫自主可控用戶委員會委員：分布式數(shù)據(jù)庫組件和節(jié)點較多，需要自動化運維平臺方便管理，自動化平臺需要重點關(guān)注：1、自動化安裝部署，包括全量和增量部署；2、自動化數(shù)據(jù)庫實例申請和快速自動交付；3、各分布式管控組件的管理和監(jiān)控；4、各數(shù)據(jù)庫節(jié)點的性能監(jiān)控，例如CPU、IO、內(nèi)存等等；5、數(shù)據(jù)庫實例監(jiān)控，數(shù)據(jù)庫運行狀態(tài)、各性能指標；性能問題快速定位，提供慢查詢語句快速定位；故障診斷分析；異常會話管理等；6、數(shù)據(jù)庫的故障切換管理，故障自動切換，故障節(jié)點更換等維護；7、數(shù)據(jù)庫在線擴縮容；8、數(shù)據(jù)庫備份和恢復(fù)。分布式數(shù)據(jù)庫的各節(jié)點的備份通常是物理備份，恢復(fù)時各節(jié)點通過物理備份加日志的形式進行恢復(fù)，恢復(fù)時需要考慮分布式事務(wù)一致性問題，多個節(jié)點在恢復(fù)完成后，需要確保各節(jié)點間的分布式事務(wù)是一致的，因此給恢復(fù)帶來了一定的難度，需要通過日志和全局事務(wù)ID進行分布式事務(wù)補齊，各類異常場景比較復(fù)雜，可能會造成數(shù)據(jù)庫一致性恢復(fù)失敗，比如一些跨度較長的事務(wù)，需要各廠商提供更為完備的恢復(fù)方案，這一塊在引入時需要重點關(guān)注。慢SQL：需要分布式數(shù)據(jù)庫提供完備的自動化運維平臺，能夠?qū)β齋QL進行及時收集和分析展示，便于出現(xiàn)性能問題時DBA能快速定位。苑華偉數(shù)據(jù)庫自主可控用戶委員會委員：問題一：分布式實例一致性備份恢復(fù)如何實現(xiàn)？備份恢復(fù)是最常用的數(shù)據(jù)庫日常運維手段，在分布式數(shù)據(jù)庫集群中，我們一般會關(guān)注兩個問題：一是數(shù)據(jù)分片/分區(qū)存儲后，如何保證備份功能的簡單易用；二是在數(shù)據(jù)恢復(fù)時如何保證全局事務(wù)的一致性。下面以基于MySQL+分布式中間件的某數(shù)據(jù)庫為例：在保證分布式架構(gòu)下備份功能的簡單易用方面，該數(shù)據(jù)庫提供多種靈活的備份配置，支持全量/增量備份、定時/實時備份，備份操作可通過管理門戶界面發(fā)起，備份任務(wù)可進行全程可視化管理。此外，該數(shù)據(jù)庫提供原子腳本，可以與商用備份工具進行對接，接入統(tǒng)一運維系統(tǒng)，極大降低了備份恢復(fù)的使用和對接難度。在備份恢復(fù)一致性方面，該數(shù)據(jù)庫具備全局一致性備份恢復(fù)能力，支持恢復(fù)到備份階段任意時刻，恢復(fù)前后的數(shù)據(jù)保持一致，相同數(shù)據(jù)的多個副本之間保持一致。其實現(xiàn)原理主要是，利用全局事務(wù)管理器GTM保存的恢復(fù)時間點所有處在活躍狀態(tài)的事務(wù)日志和全局狀態(tài)信息（包含元數(shù)據(jù)、表數(shù)據(jù)、BinLog活躍事務(wù)列表等），將恢復(fù)出的未提交事務(wù)回滾，達到剔除活躍事務(wù)的目的，保證恢復(fù)數(shù)據(jù)的全局一致性。問題二：低效率SQL如何快速定位？針對低效率SQL我們需要快速定位，分析SQL語句并優(yōu)化。該數(shù)據(jù)庫支持對事務(wù)、SQL執(zhí)行、鎖的統(tǒng)計與審計，并提供DB級別的AWR報告。具體介紹如下：1)支持對事務(wù)進行統(tǒng)計與審計。舉例如下：TOP5事務(wù)信息；性能指標，TPS峰值/平均值、時延情況；事務(wù)分布情況，總數(shù)、失敗數(shù)、提交異常數(shù)等；分布式事務(wù)分布情況，包括比重、分發(fā)情況等。2)支持鎖沖突情況展示和分析。舉例如下：數(shù)據(jù)節(jié)點上的表鎖沖突率、行鎖平均等待時長；計算節(jié)點上分布式鎖沖突情況，可展示發(fā)生沖突的用戶原始的讀/寫SQL、每條SQL沖突次數(shù)、SQL詳情（SQl執(zhí)行時長）、SQL最終執(zhí)行結(jié)果（成功、失?。┑?；自動記錄發(fā)生鎖資源競爭SQL的情況，方便用戶進行關(guān)聯(lián)性分析；數(shù)據(jù)節(jié)點和計算節(jié)點的鎖超時次數(shù)統(tǒng)計。3)支持對SQL執(zhí)行情況進行統(tǒng)計與審計。舉例如下：慢SQL分析。按執(zhí)行總時間最長、平均執(zhí)行時間最長、按執(zhí)行次數(shù)統(tǒng)計等；各類SQL語句統(tǒng)計。李建明數(shù)據(jù)庫自主可控用戶委員會委員：分布式實例一致性備份恢復(fù)如何實現(xiàn)？全局一致性備份依賴于全局序發(fā)生器的生成，有的原生分布式數(shù)據(jù)庫支持全局一致性備份而有的“分庫分表”類型的數(shù)據(jù)庫，但有些數(shù)據(jù)庫沒有實現(xiàn)全局序生成器的機制，并不能支持全局一致性備份恢復(fù)。低效率SQL如何快速定位？需要數(shù)據(jù)記錄了SQL的執(zhí)行時間、CPU、IO、節(jié)點等信息，通過統(tǒng)一的管理平臺或者系統(tǒng)性能視圖查詢低效sql。三、應(yīng)用改造難點實現(xiàn)