2.性能方面
2021年初,我們完整對(duì)比過3種數(shù)據(jù)庫(kù)的性能,包括TiFlash(4.0.10)、ClickHouse(20.3.8.53)、DorisDB(1.11.0)單表及多表join的性能情況。TiDB5.0的TiFlash已經(jīng)支持MPP,此處為4.0版本,無MPP。
測(cè)試使用業(yè)界流行的Star Schema Benchmark星型模型測(cè)試集。結(jié)論如下:
·單表/多表查詢,DorisDB總體時(shí)間均最短。
·單表查詢:DorisDB最快次數(shù)最多,ClickHouse次之。
·多表查詢:DorisDB所有執(zhí)行均最快。
關(guān)于TiDB/TiFlash
·TiDB/TiFlash總體時(shí)間單表/多表查詢均最長(zhǎng)。
·TiDB執(zhí)行計(jì)劃多數(shù)走TiKV,導(dǎo)致執(zhí)行時(shí)間長(zhǎng),且數(shù)據(jù)量越多,執(zhí)行時(shí)間越長(zhǎng)。
·TiDB強(qiáng)制走TiFlash,單表多數(shù)提速多,多表多數(shù)變慢,但4.0.10版本的執(zhí)行計(jì)劃多數(shù)不走。
關(guān)于Clickhouse
·ClickHouse多表查詢需要更改SQL,使類型一致才可以,且字段名、表名區(qū)分大小寫。
·ClickHouse單機(jī)性能強(qiáng)悍,性價(jià)比較高。
·ClickHouse大單表查詢方式效率好,多表關(guān)聯(lián)效率降低明顯。
關(guān)于DorisDB
·DorisDB單表和多表關(guān)聯(lián)查詢速度都非常快。
【單表查詢結(jié)果】
【多表關(guān)聯(lián)查詢結(jié)果】
二、業(yè)務(wù)需求及應(yīng)用
1.安全分析相關(guān)業(yè)務(wù)
每天,內(nèi)部服務(wù)器上的各類操作和運(yùn)行情況,是內(nèi)部安全人員比較關(guān)心的。但是服務(wù)器上每天有大量的信息,如何能快速收集落地、統(tǒng)一實(shí)時(shí)分析,是這個(gè)數(shù)據(jù)分析場(chǎng)景面臨的挑戰(zhàn)。具體來說,安全分析業(yè)務(wù)需要應(yīng)對(duì)以下情況:
·寫入數(shù)據(jù)量大,每天大約幾億的數(shù)據(jù)需要落地;
·實(shí)時(shí)快速的分析支持,例如:最近15分鐘,機(jī)器信息的情況是怎樣的;
·需要定期進(jìn)行數(shù)據(jù)清理;
·數(shù)據(jù)量不斷累積,數(shù)據(jù)總量規(guī)模增長(zhǎng)快。
綜合評(píng)估后,我們選擇了DorisDB來支持安全分析相關(guān)業(yè)務(wù)。在使用初期,我們使用了DorisDB的明細(xì)模型(即保留所有歷史數(shù)據(jù)),20天左右,數(shù)據(jù)行數(shù)總量就800億+了,磁盤空間占用8T左右,由于明細(xì)數(shù)據(jù)量龐大導(dǎo)致查詢性能也受到影響。
后與內(nèi)部研發(fā)人員討論,業(yè)務(wù)分析并不需要詳細(xì)的歷史明細(xì),數(shù)據(jù)按照指定時(shí)間粒度進(jìn)行聚合匯總即可。便將數(shù)據(jù)模型改成聚合模型,設(shè)置日期、小時(shí)和15分鐘三個(gè)時(shí)間維度,指標(biāo)數(shù)據(jù)按照這個(gè)級(jí)別的時(shí)間維度進(jìn)行聚合,聚合后每天新增的數(shù)據(jù)在10億左右,數(shù)據(jù)量降低了75%,查詢性能也得到大幅提升。且采用kafka+routine load的方式在DorisDB中進(jìn)行導(dǎo)入聚合,避免了引入冗余的組件,統(tǒng)一了技術(shù)棧。
2.DBA內(nèi)部業(yè)務(wù)
MySQL中間件,我們使用的ProxySQL,ProxySQL支持展示SQL情況。但是操作較為繁瑣,每次需要重置,才重新開始統(tǒng)計(jì)。如何分析指定時(shí)間的SQL情況,是困擾我們的另一問題。
每個(gè)ProxySQL有自己的全日志,我們可以分析全日志來獲取需要的信息。第一個(gè)架構(gòu)方案,我們想到了使用ES,ProxySQL全日志–>Filebeat采集–>Kafka–>Logstash–>ES。但是實(shí)際使用中,發(fā)現(xiàn)雖然可以查看流水,但是分析時(shí)就比較麻煩,不如寫SQL的方便。
后來架構(gòu)又改成了 ProxySQL全日志–>Filebeat采集–>Kafka–>DorisDB,這樣就可以進(jìn)行快速分析了。
另一個(gè)問題,因?yàn)榫€上的ProxySQL的日志量特別大,不能所有集群都開,我們?cè)O(shè)置了可以選擇開啟,這樣有需要的集群才進(jìn)行分析。降低存儲(chǔ)的壓力。
舉例:分析某30分鐘某集群的SQL執(zhí)行情況,按照次數(shù)排序,查詢很快。
除了上述兩個(gè)場(chǎng)景之外,DorisDB還被用在了銷售使用的報(bào)表系統(tǒng)等場(chǎng)景中,包含實(shí)時(shí)數(shù)據(jù)分析等業(yè)務(wù)場(chǎng)景,共50+張表,占用約100T存儲(chǔ)空間,查詢并發(fā)量100-500+。
三、系統(tǒng)運(yùn)維
1.數(shù)據(jù)接入
DorisDB支持的數(shù)據(jù)導(dǎo)入方式很豐富,例如本地文件、HDFS、Kafka(支持csv、json格式)、外表、批量SQL等。數(shù)據(jù)接入時(shí)有以下需要注意的問題:
·HDFS導(dǎo)入需要提供Namenode的信息,有些不方便提供就支持不了。
·外表模式,創(chuàng)建外表后,可以使用insert into select的方式,循環(huán)導(dǎo)入到DorisDB的本地表,能比較方便的從MySQL、TiDB導(dǎo)入數(shù)據(jù)。
·日常最常用的是Kafka的Json格式的數(shù)據(jù),需要開發(fā)提供:
··表字段、字段類型及模型(明細(xì)模型,聚合模型和更新模型)。
··Kafka信息:kafka_broker_list,kafka_topic,client.id等。
·Kafka的方式,DBA創(chuàng)建表及導(dǎo)入任務(wù)就可以導(dǎo)入數(shù)據(jù)了;日常需要注意的是:最好寫個(gè)小工具,查看下Kafka的數(shù)據(jù)信息,然后指明字段,這樣來保證成功率。
·查看導(dǎo)入任務(wù):SHOW ROUTINE LOADG;關(guān)注Statistic,ErrorLogUrls。
2.集群架構(gòu)
目前為單套集群,3個(gè)FE,3個(gè)BE,Broker按需建立,搭建1套監(jiān)控(Prometheus+Grafana),推薦使用kafka來接入數(shù)據(jù)。
3.運(yùn)維及自動(dòng)化
因?yàn)镈orisDB標(biāo)準(zhǔn)版無管理組件,需要DBA自己實(shí)現(xiàn):
·標(biāo)準(zhǔn)制定,例如:運(yùn)維標(biāo)準(zhǔn)、開發(fā)接入標(biāo)準(zhǔn)等;
·自動(dòng)化部署;
·自動(dòng)化擴(kuò)縮容;
·自動(dòng)化升級(jí);
·拓?fù)湔故?、登?
·搭建開源監(jiān)控;
·自己實(shí)現(xiàn)報(bào)警,例如存活報(bào)警、性能報(bào)警;
·相關(guān)運(yùn)維報(bào)表,例如表大小、集群磁盤使用情況、流量情況、SQL情況等。
目前我們自己已經(jīng)實(shí)現(xiàn)了部分運(yùn)維規(guī)范的制定,例如集群端口、目錄、拓?fù)浼軜?gòu)等,并開發(fā)了拓?fù)涔ぞ撸簈dorisdb,可以查看所有集群、指定集群、登錄、展示監(jiān)控節(jié)點(diǎn)信息等。
后期我們會(huì)開發(fā)相關(guān)自動(dòng)化管理工具,并整合至我們內(nèi)部的CDB平臺(tái),開發(fā)相關(guān)報(bào)表、工單等,方便開發(fā)人員使用。
【查看指定集群拓?fù)洹浚?/p>
【查看所有集群】:
4.服務(wù)器
當(dāng)前我們使用如下機(jī)器進(jìn)行部署,后期會(huì)考慮將FE節(jié)點(diǎn)使用虛擬機(jī)部署。
四、發(fā)現(xiàn)的問題及注意事項(xiàng)
·如果想混合部署,需要提前計(jì)劃好端口,集群間需要有一定間隔;
·DorisDB升級(jí)比較快,如果遇到bug可以咨詢官方,及時(shí)升級(jí)避開;
·查詢報(bào)錯(cuò):2021-05-09 11:38:56-WARN
com.mysql.jdbc.PacketTooBigException:Packet for query is too large(1095400>1048576).You can change this value on the server by setting the max_allowed_packet’variable;
··處理:set global max_allowed_packet=102410248;
·賬號(hào)授權(quán)跟MySQL不同,需要注意;
·標(biāo)準(zhǔn)版的周邊較少,希望能不斷豐富,讓更多的人用起來;
·Json格式數(shù)據(jù)導(dǎo)入,字段沒法復(fù)用,推薦官方添加上,例如:求最大最小時(shí)間,需要開發(fā)寫入Kafka兩個(gè)時(shí)間字段,無法復(fù)用一個(gè);
·導(dǎo)入數(shù)據(jù)需要一定的調(diào)試經(jīng)驗(yàn),例如Kafka,可以自己寫個(gè)工具,查看下Kafka里面的數(shù)據(jù),再進(jìn)行測(cè)試;
五、場(chǎng)景及定位
DorisDB是優(yōu)秀的分析型數(shù)據(jù)庫(kù),可以滿足多種數(shù)據(jù)分析場(chǎng)景的需求。但還有不少業(yè)務(wù)場(chǎng)景需要用其他數(shù)據(jù)庫(kù)來服務(wù),目前58DBA提供了多種數(shù)據(jù)庫(kù),方便業(yè)務(wù)方根據(jù)自身的場(chǎng)景進(jìn)行選擇。
總結(jié)
目前,我們已經(jīng)落地了兩套DorisDB集群,還有1-2套正在測(cè)試階段,后續(xù)會(huì)進(jìn)行進(jìn)一步推廣和落地更多應(yīng)用。最后,十分感謝DorisDB鼎石科技團(tuán)隊(duì)專業(yè)的支持服務(wù),希望我們能一起把DorisDB建設(shè)得更好。(作者:劉春雷 負(fù)責(zé)58同城MySQL、TiDB數(shù)據(jù)庫(kù)、DorisDB的運(yùn)維工作,主要從事數(shù)據(jù)庫(kù)自動(dòng)化、平臺(tái)化的建設(shè))