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

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

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

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

大key的分析與解決

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

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

案例1：

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

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

CREATE

TABLE

movie

(

  movieid

  appid

  uid

  accessstring

  moviename

  access_time

表設(shè)計分析

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

解決方法：

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

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

CREATE

TABLE

hotmovieaccess

(

  movieid

  appid

  accessstring

  access_time

)

2.增加緩存

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

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

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

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

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

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

案例2：

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

CREATE

TABLE

movie_meta202110

(

  path text

  moviename text

  movieid text

  create_time timestamp

  modify_mtime timestamp

)

解決辦法：

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

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

大key的定義與檢測手段

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

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

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

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

熱key的危害與解決

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

熱key會造成以下危害：

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

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

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

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

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

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

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

熱key的檢測

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

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

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

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

審核編輯黃昊宇