華為云數(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é)點負載不均，集群穩(wěn)定性會下降，這一類問題稱為大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é)點負載不均，集群穩(wěn)定性會下降，這一類問題稱為大key問題。當某一熱點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ù)進行合理的schema設(shè)計，規(guī)避業(yè)務(wù)穩(wěn)定性風(fēng)險。

大key的分析與解決

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

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

案例1：

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

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

CREATE TABLE movie (??? movieid text,??? appid int,??? uid bigint,??? accessstring text,??? moviename text,??? access_time timestamp,??? PRIMARY KEY (movieid, appid, uid, accessstring, moviename))

表設(shè)計分析

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

解決方法：

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

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

CREATE TABLE hotmovieaccess (??? movieid text,??? appid int,??? accessstring text,??? access_time timestamp,??? PRIMARY KEY (movieid, appid))

2. 增加緩存

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

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

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

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

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

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

案例2：

movie_meta以月度建表，每個表只存當月的數(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,??? PRIMARY KEY (path, moviename))

解決辦法：

新分區(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告警。當發(fā)生大key事件時，會第一時間通知。及時整改，可避免業(yè)務(wù)波動。

大key告警字段解釋

[ {??????????? ?"partition_size": "1008293497", ??????????????????????????? //超大分區(qū)鍵的總大小??????????? ?"timestamp": "2021-09-08 07:08:18,240", ??????? ????????????//大key產(chǎn)生時間??????????? ?"partition_num": "676826", ???????????????????????????????? //超大分區(qū)鍵的總行數(shù)??????????? ?"keyspace_name": "ssss", ?????????????????????? ????????????//keyspace名稱??????????? ?"table_name": "zzzz", ????????????????????????? //表名稱??????????? ?"table_id": "024a1070-0064-11eb-bdf3-d3fe5956183b",??? //表id??????????? ?"partition_key": "{vin=TESTW3YWZD2021003}"????????????? //分區(qū)鍵 }]

?

熱key的危害與解決

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

?

熱key會造成以下危害：

1.流量集中，達到物理網(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è)進行定制, 支持熱key黑白名單能力，可以將熱key臨時屏蔽。

熱key的檢測

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

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

熱key告警字段解釋：

{??????????? "sampler_type": "WRITES", ?????? // 采樣類型。取值有WRITES, READS; WRITES代表寫，READS代表讀。??????????? "partition_num": "2969", ??????????????????????????????????? // 分區(qū)鍵的熱點次數(shù)??????????? "keyspace_name": "performance", ???????????????? ????????????// keyspace名稱??????????? "table_id": "a10f3bb0-3626-11ec-bbdf-63e05bbb4391",???? // 表id??????????? "table_name": "stresstable", ??????????????????????????????? // 表名??????????? "partition_key": "85897376" ???????????????????????????????? // 產(chǎn)生熱點分區(qū)鍵的值}

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ī)則 的治理流程進行。合理的設(shè)計一般會降低大部份風(fēng)險發(fā)生的概率，對于應(yīng)用來說，任何表的設(shè)計都要考慮是否會造成熱key,大key的產(chǎn)生，是否會造成負載傾斜的問題；另外建立數(shù)據(jù)老化機制，表中的數(shù)據(jù)不能無限制的增長而不刪除或者老化；針對讀多寫少的場景，要增加緩存機制，來應(yīng)對讀熱點問題，并提升查詢性能；對于每個PK以及每行Row的大小，要控制大小，否則將影響性能和穩(wěn)定性。超出后要及時優(yōu)化。

?

?

?