摘要：GaussDB(for Cassandra) 提供了大key和熱key的實時檢測，以幫助業務進行合理的schema設計，規避業務穩定性風險。
本文分享自華為雲社群《GaussDB (for Cassandra) 資料庫治理 -- 大key與熱key問題的檢測與解決》，作者：Cassandra官方 。
Cassandra資料庫是一個高度可擴充的高性能分布式資料庫，面向大資料場景，可用于管理大量的結構化資料。在業務使用的過程中，随着業務量和資料流量的持續增長，往往一些業務的設計弊端逐漸暴露出來，降低了叢集的穩定性和可用性。比如主鍵設計不合理，單個分區的記錄數或資料量過大，出現超大分區鍵，引起了節點負載不均，叢集穩定性會下降，這一類問題稱為大key問題。當某一熱點key的請求在某一主機上的通路超過server極限時，會導緻熱點Key問題的産生。往往大key是造成熱key問題的間接原因。
GaussDB(for Cassandra) 是一款基于華為自研的計算存儲分離架構的分布式資料庫，相容Cassandra生态的雲原生NoSQL資料庫，支援類SQL文法CQL。在華為雲高性能、高可用、高可靠、高安全、可彈性伸縮的基礎上，提供了一鍵部署、快速備份恢複、計算存儲獨立擴容、監控告警等服務能力。針對以上問題，GaussDB(for Cassandra) 提供了大key和熱key的實時檢測，以幫助業務進行合理的schema設計，規避業務穩定性風險。
大key的分析與解決
大key的産生，最主要的原因是主鍵設計不合理，使得單個分區的記錄數或資料量過大。一旦某一個分區出現極大時，對該分區的通路，會造成分區所在server的負載變高，甚至造成節點OOM等。
針對大key問題，一般采取兩種修複手段，一種是增加緩存，優化表結構。一種是基于現有分區鍵，增加分區鍵散列。對資料進行打散，避免單個分區的記錄過大。GaussDB(for Cassandra) 有如下整改事例，業務整改後負載平穩運作。
案例1：
XX叢集的資料量過大，導緻叢集存在大分區鍵(排查數量大概為2000+)，最大的分區鍵達到38G。當業務頻繁通路這部分大的分區鍵時，會導緻節點持續高負載，影響業務請求成功率。
表結構如下
CREATE TABLE movie (
movieid text,
appid int,
uid bigint,
accessstring text,
moviename text,
access_time timestamp,
PRIMARY KEY (movieid, appid, uid, accessstring, moviename)
) 表設計分析
movie表儲存了短視訊的相關資訊，分區鍵為movieid，并且儲存了使用者資訊(uid)，如果movieid是一個熱門短視訊，有幾千萬甚至上億使用者點贊此短視訊，則該熱門短視訊所在的分區非常大(目前發現有38G)。
解決方法：
1. 優化表結構
建立新表儲存熱門短視訊資訊，隻保留短視訊公共資訊，不包含使用者資訊，確定該表不會産生大的分區鍵。熱門短視訊資訊寫入該表中。
CREATE TABLE hotmovieaccess (
movieid text,
appid int,
accessstring text,
access_time timestamp,
PRIMARY KEY (movieid, appid)
) 2. 增加緩存
增加緩存，業務應用先從緩存中讀取熱門檔案資訊，沒有查詢到，則從資料庫中查詢，減少資料庫查詢次數。
整個優化邏輯如下：
- 先查緩存，當緩存存在，直接傳回結果。
- 當緩存不存在，查詢熱門視訊緩存（緩存不存在，則查詢hot表），當視訊為為熱門視訊時，查詢hotmovieaccess表。
- 當hotmovieaccess表存在結果時，直接傳回，當hotmovieaccess表不存在記錄時，查詢movie表。
- 并緩存查詢結果。
案例2:
movie_meta以月度建表，每個表隻存當月的資料，初始的這種設計是可以減輕或規避分區鍵過大問題的。由于業務頻繁寫入，熱門視訊存儲的記錄非常多，還是形成了大的資料分區。
CREATE TABLE movie_meta202110 (
path text,
moviename text,
movieid text,
create_time timestamp,
modify_mtime timestamp,
PRIMARY KEY (path, moviename)
) 解決辦法：
新分區鍵增加一個随機數（0~999）：将原來一個分區存儲的資訊随機離散存儲到1000個分區中。
采用新的分區鍵之後，沒有形成新超過100M的分區鍵，舊的超過100M的分區鍵資料，随着時間老化過期即可。
大key的定義與檢測手段
通過長時間的業務觀察，我們規定以下門檻值，超過任何一個條件的門檻值即為大key：
- 單個分區鍵的行數不能超過10萬
- 單個分區的大小不超過100MB
GaussDB(for Cassandra) 支援了大key的檢測與告警。在CES界面，可以配置執行個體的大key告警。當發生大key事件時，會第一時間通知。及時整改，可避免業務波動。
大key告警字段解釋
[
{
"partition_size": "1008293497", //超大分區鍵的總大小
"timestamp": "2021-09-08 07:08:18,240", //大key産生時間
"partition_num": "676826", //超大分區鍵的總行數
"keyspace_name": "ssss", //keyspace名稱
"table_name": "zzzz", //表名稱
"table_id": "024a1070-0064-11eb-bdf3-d3fe5956183b", //表id
"partition_key": "{vin=TESTW3YWZD2021003}" //分區鍵
}
] 熱key的危害與解決
在日常生活中，經常會發生各種熱門事件，應用中對該熱點新聞進行上萬次的點選浏覽和評論時，會形成一個較大的請求量，這種情況下會造成短時間内對同一個key頻繁操作，會導緻key所在節點的CPU和load飙高，進而影響落在該節點的其他請求。導緻業務成功率下降。諸如此類的還有熱門商品促銷，網紅直播等場景，這些典型的讀多寫少的場景也會産生熱點問題。
熱key會造成以下危害：
- 流量集中，達到實體網卡上限。
- 請求過多，緩存分片服務被打垮。
- DB擊穿，引起業務雪崩。
GaussDB(for Cassandra) 針對熱key問題，常見的修複手段如下：
- 設計上需要考慮熱key的問題，避免在資料庫上産生熱key
- 業務側通過增加緩存來減少熱key出現的情況下對資料庫造成的沖擊。考慮多級緩存解決熱key問題（如Redis + 本地二級緩存）
- 屏蔽熱點key, 比如在業務側進行定制, 支援熱key黑白名單能力，可以将熱key臨時屏蔽。
熱key的檢測
我們定義通路頻率 大于 100000 次/min 的key為熱key。熱key事件分為兩種類型，一種時WRITES事件，代表寫熱點，一種是READS事件，表示讀熱點。
GaussDB(for Cassandra) 也提供了熱key的監測與告警。在CES界面，可以配置執行個體的熱key告警。如下
熱key告警字段解釋：
{
"sampler_type": "WRITES", // 采樣類型。取值有WRITES, READS; WRITES代表寫，READS代表讀。
"partition_num": "2969", // 分區鍵的熱點次數
"keyspace_name": "performance", // keyspace名稱
"table_id": "a10f3bb0-3626-11ec-bbdf-63e05bbb4391", // 表id
"table_name": "stresstable", // 表名
"partition_key": "85897376" // 産生熱點分區鍵的值
} GaussDB(for Cassandra) 提供了大key和熱key的實時監控。確定第一時間感覺業務風險。提供的大key和熱key解決方案，在面對大資料量洪峰場景，增強了叢集的穩定性與可用性。為客戶業務持續穩定運作保駕護航。
綜上，線上業務在使用Cassandra時，必須執行相關的開發規則和使用規範，在開發設計階段就降低使用風險。一般按照 制定規範 --> 接入評審 --> 定期巡檢 --> 優化規則 的治理流程進行。合理的設計一般會降低大部份風險發生的機率，對于應用來說，任何表的設計都要考慮是否會造成熱key,大key的産生，是否會造成負載傾斜的問題；另外建立資料老化機制，表中的資料不能無限制的增長而不删除或者老化；針對讀多寫少的場景，要增加緩存機制，來應對讀熱點問題，并提升查詢性能；對于每個PK以及每行Row的大小，要控制大小，否則将影響性能和穩定性。超出後要及時優化。
點選關注，第一時間了解華為雲新鮮技術~