華為云數(shù)據(jù)庫(kù)GaussDB (for Cassandra)?數(shù)據(jù)庫(kù)治理 --?大key與熱key問題的檢測(cè)與解決

華為云數(shù)據(jù)庫(kù)GaussDB (for Cassandra)數(shù)據(jù)庫(kù)治理 --大key與熱key問題的檢測(cè)與解決

Cassandra數(shù)據(jù)庫(kù)是一個(gè)高度可擴(kuò)展的高性能分布式數(shù)據(jù)庫(kù)，面向大數(shù)據(jù)場(chǎng)景，可用于管理大量的結(jié)構(gòu)化數(shù)據(jù)。在業(yè)務(wù)使用的過程中，隨著業(yè)務(wù)量和數(shù)據(jù)流量的持續(xù)增長(zhǎng)，往往一些業(yè)務(wù)的設(shè)計(jì)弊端逐漸暴露出來，降低了集群的穩(wěn)定性和可用性。比如主鍵設(shè)計(jì)不合理，單個(gè)分區(qū)的記錄數(shù)或數(shù)據(jù)量過大，出現(xiàn)超大分區(qū)鍵，引起了節(jié)點(diǎn)負(fù)載不均，集群穩(wěn)定性會(huì)下降，這一類問題稱為大key問題。當(dāng)某一熱點(diǎn)key的請(qǐng)求在某一主機(jī)上的訪問。

Cassandra數(shù)據(jù)庫(kù)是一個(gè)高度可擴(kuò)展的高性能分布式數(shù)據(jù)庫(kù)，面向大數(shù)據(jù)場(chǎng)景，可用于管理大量的結(jié)構(gòu)化數(shù)據(jù)。在業(yè)務(wù)使用的過程中，隨著業(yè)務(wù)量和數(shù)據(jù)流量的持續(xù)增長(zhǎng)，往往一些業(yè)務(wù)的設(shè)計(jì)弊端逐漸暴露出來，降低了集群的穩(wěn)定性和可用性。比如主鍵設(shè)計(jì)不合理，單個(gè)分區(qū)的記錄數(shù)或數(shù)據(jù)量過大，出現(xiàn)超大分區(qū)鍵，引起了節(jié)點(diǎn)負(fù)載不均，集群穩(wěn)定性會(huì)下降，這一類問題稱為大key問題。當(dāng)某一熱點(diǎn)key的請(qǐng)求在某一主機(jī)上的訪問超過server極限時(shí)，會(huì)導(dǎo)致熱點(diǎn)Key問題的產(chǎn)生。往往大key是造成熱key問題的間接原因。

GaussDB(for Cassandra)是一款基于華為自研的計(jì)算存儲(chǔ)分離架構(gòu)的分布式數(shù)據(jù)庫(kù)，兼容Cassandra生態(tài)的云原生NoSQL數(shù)據(jù)庫(kù)，支持類SQL語(yǔ)法CQL。在華為云高性能、高可用、高可靠、高安全、可彈性伸縮的基礎(chǔ)上，提供了一鍵部署、快速備份恢復(fù)、計(jì)算存儲(chǔ)獨(dú)立擴(kuò)容、監(jiān)控告警等服務(wù)能力。針對(duì)以上問題，GaussDB(for Cassandra)提供了大key和熱key的實(shí)時(shí)檢測(cè)，以幫助業(yè)務(wù)進(jìn)行合理的schema設(shè)計(jì)，規(guī)避業(yè)務(wù)穩(wěn)定性風(fēng)險(xiǎn)。

大key的分析與解決

大key的產(chǎn)生，最主要的原因是主鍵設(shè)計(jì)不合理，使得單個(gè)分區(qū)的記錄數(shù)或數(shù)據(jù)量過大。一旦某一個(gè)分區(qū)出現(xiàn)極大時(shí)，對(duì)該分區(qū)的訪問，會(huì)造成分區(qū)所在server的負(fù)載變高，甚至造成節(jié)點(diǎn)OOM等。

針對(duì)大key問題，一般采取兩種修復(fù)手段，一種是增加緩存，優(yōu)化表結(jié)構(gòu)。一種是基于現(xiàn)有分區(qū)鍵，增加分區(qū)鍵散列。對(duì)數(shù)據(jù)進(jìn)行打散，避免單個(gè)分區(qū)的記錄過大。GaussDB(for Cassandra)有如下整改事例，業(yè)務(wù)整改后負(fù)載平穩(wěn)運(yùn)行。

案例1：

XX集群的數(shù)據(jù)量過大，導(dǎo)致集群存在大分區(qū)鍵(排查數(shù)量大概為2000+)，最大的分區(qū)鍵達(dá)到38G。當(dāng)業(yè)務(wù)頻繁訪問這部分大的分區(qū)鍵時(shí)，會(huì)導(dǎo)致節(jié)點(diǎn)持續(xù)高負(fù)載，影響業(yè)務(wù)請(qǐng)求成功率。

表結(jié)構(gòu)如下

CREATE

TABLE

movie

(

  movieid

  appid

  uid

  accessstring

  moviename

  access_time

表設(shè)計(jì)分析

movie表保存了短視頻的相關(guān)信息，分區(qū)鍵為movieid，并且保存了用戶信息(uid)，如果movieid是一個(gè)熱門短視頻，有幾千萬(wàn)甚至上億用戶點(diǎn)贊此短視頻，則該熱門短視頻所在的分區(qū)非常大(當(dāng)前發(fā)現(xiàn)有38G)。

解決方法：

1.優(yōu)化表結(jié)構(gòu)

創(chuàng)建新表保存熱門短視頻信息，只保留短視頻公共信息，不包含用戶信息，確保該表不會(huì)產(chǎn)生大的分區(qū)鍵。熱門短視頻信息寫入該表中。

CREATE

TABLE

hotmovieaccess

(

  movieid

  appid

  accessstring

  access_time

)

2.增加緩存

增加緩存，業(yè)務(wù)應(yīng)用先從緩存中讀取熱門文件信息，沒有查詢到，則從數(shù)據(jù)庫(kù)中查詢，減少數(shù)據(jù)庫(kù)查詢次數(shù)。

整個(gè)優(yōu)化邏輯如下：

1.先查緩存，當(dāng)緩存存在，直接返回結(jié)果。

2.當(dāng)緩存不存在，查詢熱門視頻緩存（緩存不存在，則查詢hot表），當(dāng)視頻為為熱門視頻時(shí)，查詢hotmovieaccess表。

3.當(dāng)hotmovieaccess表存在結(jié)果時(shí)，直接返回，當(dāng)hotmovieaccess表不存在記錄時(shí)，查詢movie表。

4.并緩存查詢結(jié)果。

案例2：

movie_meta以月度建表，每個(gè)表只存當(dāng)月的數(shù)據(jù)，初始的這種設(shè)計(jì)是可以減輕或規(guī)避分區(qū)鍵過大問題的。由于業(yè)務(wù)頻繁寫入，熱門視頻存儲(chǔ)的記錄非常多，還是形成了大的數(shù)據(jù)分區(qū)。

CREATE

TABLE

movie_meta202110

(

  path text

  moviename text

  movieid text

  create_time timestamp

  modify_mtime timestamp

)

解決辦法：

新分區(qū)鍵增加一個(gè)隨機(jī)數(shù)（0~999）：將原來一個(gè)分區(qū)存儲(chǔ)的信息隨機(jī)離散存儲(chǔ)到1000個(gè)分區(qū)中。

采用新的分區(qū)鍵之后，沒有形成新超過100M的分區(qū)鍵，舊的超過100M的分區(qū)鍵數(shù)據(jù)，隨著時(shí)間老化過期即可。

大key的定義與檢測(cè)手段

通過長(zhǎng)時(shí)間的業(yè)務(wù)觀察，我們規(guī)定以下閾值，超過任何一個(gè)條件的閾值即為大key：

1.單個(gè)分區(qū)鍵的行數(shù)不能超過10萬(wàn)

2.單個(gè)分區(qū)的大小不超過100MB

GaussDB(for Cassandra)支持了大key的檢測(cè)與告警。在CES界面，可以配置實(shí)例的大key告警。當(dāng)發(fā)生大key事件時(shí)，會(huì)第一時(shí)間通知。及時(shí)整改，可避免業(yè)務(wù)波動(dòng)。

熱key的危害與解決

在日常生活中，經(jīng)常會(huì)發(fā)生各種熱門事件，應(yīng)用中對(duì)該熱點(diǎn)新聞進(jìn)行上萬(wàn)次的點(diǎn)擊瀏覽和評(píng)論時(shí)，會(huì)形成一個(gè)較大的請(qǐng)求量，這種情況下會(huì)造成短時(shí)間內(nèi)對(duì)同一個(gè)key頻繁操作，會(huì)導(dǎo)致key所在節(jié)點(diǎn)的CPU和load飆高，從而影響落在該節(jié)點(diǎn)的其他請(qǐng)求。導(dǎo)致業(yè)務(wù)成功率下降。諸如此類的還有熱門商品促銷，網(wǎng)紅直播等場(chǎng)景，這些典型的讀多寫少的場(chǎng)景也會(huì)產(chǎn)生熱點(diǎn)問題。

熱key會(huì)造成以下危害：

1.流量集中，達(dá)到物理網(wǎng)卡上限。

2.請(qǐng)求過多，緩存分片服務(wù)被打垮。

3.DB擊穿，引起業(yè)務(wù)雪崩。

GaussDB(for Cassandra)針對(duì)熱key問題，常見的修復(fù)手段如下：

1.設(shè)計(jì)上需要考慮熱key的問題，避免在數(shù)據(jù)庫(kù)上產(chǎn)生熱key

2.業(yè)務(wù)側(cè)通過增加緩存來減少熱key出現(xiàn)的情況下對(duì)數(shù)據(jù)庫(kù)造成的沖擊。考慮多級(jí)緩存解決熱key問題（如Redis +本地二級(jí)緩存）

3.屏蔽熱點(diǎn)key,比如在業(yè)務(wù)側(cè)進(jìn)行定制,支持熱key黑白名單能力，可以將熱key臨時(shí)屏蔽。

熱key的檢測(cè)

我們定義訪問頻率 大于 100000次/min的key為熱key。熱key事件分為兩種類型，一種時(shí)WRITES事件，代表寫熱點(diǎn)，一種是READS事件，表示讀熱點(diǎn)。

GaussDB(for Cassandra)也提供了熱key的監(jiān)測(cè)與告警。在CES界面，可以配置實(shí)例的熱key告警。如下

GaussDB(for Cassandra)提供了大key和熱key的實(shí)時(shí)監(jiān)控。確保第一時(shí)間感知業(yè)務(wù)風(fēng)險(xiǎn)。提供的大key和熱key解決方案，在面對(duì)大數(shù)據(jù)量洪峰場(chǎng)景，增強(qiáng)了集群的穩(wěn)定性與可用性。為客戶業(yè)務(wù)持續(xù)穩(wěn)定運(yùn)行保駕護(hù)航。

綜上，在線業(yè)務(wù)在使用Cassandra時(shí)，必須執(zhí)行相關(guān)的開發(fā)規(guī)則和使用規(guī)范，在開發(fā)設(shè)計(jì)階段就降低使用風(fēng)險(xiǎn)。一般按照 制定規(guī)范 -->接入評(píng)審 --> 定期巡檢 -->優(yōu)化規(guī)則 的治理流程進(jìn)行。合理的設(shè)計(jì)一般會(huì)降低大部份風(fēng)險(xiǎn)發(fā)生的概率，對(duì)于應(yīng)用來說，任何表的設(shè)計(jì)都要考慮是否會(huì)造成熱key,大key的產(chǎn)生，是否會(huì)造成負(fù)載傾斜的問題；另外建立數(shù)據(jù)老化機(jī)制，表中的數(shù)據(jù)不能無限制的增長(zhǎng)而不刪除或者老化；針對(duì)讀多寫少的場(chǎng)景，要增加緩存機(jī)制，來應(yīng)對(duì)讀熱點(diǎn)問題，并提升查詢性能；對(duì)于每個(gè)PK以及每行Row的大小，要控制大小，否則將影響性能和穩(wěn)定性。超出后要及時(shí)優(yōu)化。

審核編輯黃昊宇