真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

MySQL流轉(zhuǎn)工具M(jìn)axwell的代碼改造和優(yōu)化方法教程

本篇內(nèi)容介紹了“MySQL流轉(zhuǎn)工具M(jìn)axwell的代碼改造和優(yōu)化方法教程”的有關(guān)知識,在實(shí)際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!

成都創(chuàng)新互聯(lián)公司是一家網(wǎng)站設(shè)計(jì)公司,集創(chuàng)意、互聯(lián)網(wǎng)應(yīng)用、軟件技術(shù)為一體的創(chuàng)意網(wǎng)站建設(shè)服務(wù)商,主營產(chǎn)品:成都響應(yīng)式網(wǎng)站建設(shè)公司、品牌網(wǎng)站建設(shè)、成都全網(wǎng)營銷。我們專注企業(yè)品牌在網(wǎng)站中的整體樹立,網(wǎng)絡(luò)互動的體驗(yàn),以及在手機(jī)等移動端的優(yōu)質(zhì)呈現(xiàn)。成都網(wǎng)站建設(shè)、做網(wǎng)站、移動互聯(lián)產(chǎn)品、網(wǎng)絡(luò)運(yùn)營、VI設(shè)計(jì)、云產(chǎn)品.運(yùn)維為核心業(yè)務(wù)。為用戶提供一站式解決方案,我們深知市場的競爭激烈,認(rèn)真對待每位客戶,為客戶提供賞析悅目的作品,網(wǎng)站的價(jià)值服務(wù)。

Maxwell是開源產(chǎn)品,相比Canal的體量也小很多,綜合考慮下,在短期內(nèi)選擇了Maxwell.

從快速上手到功能支持,算是一個(gè)總體支持還不錯的產(chǎn)品,也讓技術(shù)調(diào)研和迭代進(jìn)度進(jìn)展相對快了很多。

一般說要比較,基本都會拿出這幅圖來(數(shù)據(jù)帶有主觀特點(diǎn),僅供參考),因?yàn)榭紤]到bootstrap是個(gè)硬性需求,所以這部分的功能考量也是一個(gè)重要權(quán)衡。

MySQL流轉(zhuǎn)工具M(jìn)axwell的代碼改造和優(yōu)化方法教程

最近在做數(shù)據(jù)庫到大數(shù)據(jù)流轉(zhuǎn)的過程中發(fā)現(xiàn)了Maxwell的一些問題和改進(jìn)點(diǎn):

1)Maxwell的服務(wù)管理模式目前只支持start模式,如果要停止只能采用手工kill的方式,相對粗暴一些,當(dāng)然和作者交流,可以使用信號處理的方式來間接實(shí)現(xiàn)。

2)Maxwell的核心配置是對于同步對象的過濾,可以支持正則等模式,如果過濾規(guī)則較為復(fù)雜,或者后期不斷的調(diào)整,每次調(diào)整都需要重新啟動Maxwell服務(wù),沒有類似reload的模式。

3)對于DDL變更,如果Maxwell的初始化已完成,服務(wù)已啟動,在后續(xù)創(chuàng)建一張表的時(shí)候,Maxwell會把變更記錄至`schemas`表中維護(hù)版本變更記錄,在已有的元數(shù)據(jù)表中`tables`和`columns`里面就沒有這些信息了,對于后端的服務(wù)解析表結(jié)構(gòu)會帶來一些偏差(DDL的變更配置會有相應(yīng)的JSON)

1.問題定位

這些問題算起來大多是建議,不算是致命問題,所以整體的進(jìn)度依然可以繼續(xù)推進(jìn),但是最近在做了幾張大表的同步之后發(fā)現(xiàn)了一些數(shù)據(jù)問題。

1)bootstrap的時(shí)間比較長,查看Maxwell相關(guān)監(jiān)控,整體的數(shù)據(jù)吞吐量在800條/秒左右,好像是達(dá)到了整個(gè)同步的瓶頸,同步一張200多萬數(shù)據(jù)的表需要1個(gè)小時(shí)左右,相對比較長,我們在近期的測試中,幾張千萬級的大表如果串行初始化,差不多得2-3個(gè)小時(shí),實(shí)在是太長了。

2)同步數(shù)據(jù)的時(shí)間字段值存在差異,這也是在中端(maxwell規(guī)劃為中端服務(wù))和后端(Flink,Kudu規(guī)劃為后端)在做數(shù)據(jù)比對中發(fā)現(xiàn)的,bootstrap的數(shù)據(jù)比對結(jié)果幾乎沒有相同的,也就意味是bootstrap在數(shù)據(jù)方面存在一些潛在問題,所以整個(gè)事情輪盤到了Maxwell的bootstrap部分。

查看代碼邏輯,著實(shí)讓我一驚,這個(gè)問題目前僅在bootstrap的環(huán)節(jié)出現(xiàn),比如數(shù)據(jù)的時(shí)間字段值為:

MySQL流轉(zhuǎn)工具M(jìn)axwell的代碼改造和優(yōu)化方法教程

但是經(jīng)過邏輯處理后,會有時(shí)區(qū)的計(jì)算,會自動補(bǔ)上時(shí)區(qū)的差異。

現(xiàn)在的問題已經(jīng)不是初始化帶來的性能隱患,而是數(shù)據(jù)質(zhì)量出現(xiàn)了侵入性,導(dǎo)致數(shù)據(jù)看起來錯亂。

對于這個(gè)問題,分析的重點(diǎn)就是時(shí)區(qū)的處理差異,本來想這個(gè)改動應(yīng)該很小,沒想到調(diào)試和環(huán)境集成著實(shí)花了不少功夫。

2.問題修正

對于時(shí)區(qū)的數(shù)據(jù)差異,主要在于datetime數(shù)據(jù)類型存在時(shí)區(qū)差異,目前差距在13個(gè)小時(shí)。

查看Maxwell的代碼類SynchronousBootstrapper:

MySQL流轉(zhuǎn)工具M(jìn)axwell的代碼改造和優(yōu)化方法教程

經(jīng)過調(diào)試,需要改動的代碼邏輯范圍是基于函數(shù)setRowValues:

MySQL流轉(zhuǎn)工具M(jìn)axwell的代碼改造和優(yōu)化方法教程

可以修改為:

MySQL流轉(zhuǎn)工具M(jìn)axwell的代碼改造和優(yōu)化方法教程

改動之后,整個(gè)bootstrap的邏輯經(jīng)過調(diào)試和反復(fù)測試就正常了。

3.性能問題的取舍和修正

當(dāng)然在這個(gè)之外,也做了一些細(xì)小的改進(jìn)。

第一個(gè)問題就是bootstrap的性能問題,之前看似乎是有瓶頸,吞吐量在800左右就上不去了,對此我做了如下的改進(jìn):

1).bootstrap的一個(gè)基本原理就是select * from xxxx order by id;這種使用模式,如果表數(shù)據(jù)量比較大,其實(shí)order  by的部分看起來是走了主鍵,該子句會強(qiáng)制走全索引掃描,但是整體的效果反而不是全表掃描,所以我就干脆去除了邏輯中的order by子句。

整個(gè)邏輯的改造也很輕量:

private ResultSet getAllRows(String databaseName, String tableName, Table table, String whereClause,         if ( pk != null && !pk.equals("") ) {             sql += String.format(" order by %s", pk);         }

2).去除了寫入數(shù)據(jù)后的sleep 1毫秒

進(jìn)一步分析代碼,發(fā)現(xiàn)bootstrap中吞吐量的瓶頸是其中一個(gè)詭異的sleep  1的處理,根據(jù)初步分析,可能考慮到bootstrap的任務(wù)會產(chǎn)生大量數(shù)據(jù),對于帶寬和負(fù)載壓力較大,通過sleep的方式能夠做到降速,整體可控。

另外對于bootstrap的日志統(tǒng)計(jì)中會包括同步的數(shù)據(jù)條數(shù),這個(gè)指標(biāo)值目前的依賴度不高,而且數(shù)據(jù)校驗(yàn)的工作目前會先停止Slave再進(jìn)行數(shù)據(jù)比對

性能提升和改進(jìn),在3-5倍左右,所以這個(gè)部分的邏輯我們可以根據(jù)實(shí)際情況取舍,在我們的流傳設(shè)計(jì)中,數(shù)據(jù)都是基于Slave端進(jìn)行流轉(zhuǎn)的,所以不會對主庫造成沖擊,改動的這個(gè)部分的邏輯也很輕巧,注釋掉sleep(1)即可。

public void performBootstrap(BootstrapTask task, AbstractProducer producer, Long currentSchemaID) throws Exception {                producer.push(row);                Thread.sleep(1);                ++insertedRows;

改動后經(jīng)過測試和對比,發(fā)現(xiàn)性能好了很多,最多的時(shí)候能有6000多,同樣的初始化不到15分鐘左右就全部搞定了。

MySQL流轉(zhuǎn)工具M(jìn)axwell的代碼改造和優(yōu)化方法教程

這樣一些細(xì)小的改進(jìn)也給我們帶來了一些成就感,后續(xù)的數(shù)據(jù)同步規(guī)模繼續(xù)擴(kuò)大,也沒有再反饋過數(shù)據(jù)質(zhì)量的問題,當(dāng)然在這個(gè)基礎(chǔ)上還有一些工作需要細(xì)化。

4.后續(xù)對于bootstrap方向的改進(jìn)

1)使用分片的思路來完善bootstrap

提高數(shù)據(jù)提取的效率,對于千萬級以上的大表數(shù)據(jù)抽取,可以按照區(qū)間分段來提取(需要考慮到數(shù)據(jù)的變更和寫入的影響),目前的邏輯過于僵硬。

private ResultSet getAllRows(String databaseName, String tableName, Table table, String whereClause,                                 Connection connection) throws SQLException {        Statement statement = createBatchStatement(connection);        String pk = table.getPKString();        String sql = String.format("select * from `%s`.%s", databaseName, tableName);        if ( whereClause != null && !whereClause.equals("") ) {            sql += String.format(" where %s", whereClause);        }        if ( pk != null && !pk.equals("") ) {            sql += String.format(" order by %s", pk);        }        return statement.executeQuery(sql);    }

2)數(shù)據(jù)字典索引優(yōu)化

Maxwell數(shù)據(jù)字典的優(yōu)化,目前的數(shù)據(jù)字典中,部分SQL執(zhí)行頻率較高,但是從數(shù)據(jù)庫層面來看是全表掃描,這些細(xì)節(jié)的地方還需要進(jìn)一步調(diào)整。

比如如下的SQL語句:

>>explain select * from bootstrap where is_complete = 0 and client_id = 'dts_hb30_130_200_maxwell003' and (started_at is null or started_at <= now()) order by isnull(started_at), started_at asc, id asc;

基于業(yè)務(wù)場景的改進(jìn)和調(diào)整,也讓我們通過真實(shí)場景的落地,更好的擁抱開源,并在一定程度上能夠回饋和反哺。

“MySQL流轉(zhuǎn)工具M(jìn)axwell的代碼改造和優(yōu)化方法教程”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實(shí)用文章!


分享文章:MySQL流轉(zhuǎn)工具M(jìn)axwell的代碼改造和優(yōu)化方法教程
鏈接分享:http://weahome.cn/article/pegoid.html

其他資訊

在線咨詢

微信咨詢

電話咨詢

028-86922220(工作日)

18980820575(7×24)

提交需求

返回頂部