GaussDB (for Cassandra) 資料庫治理:大key與熱key問題的檢測與解決

語言: CN / TW / HK
摘要: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. 增加快取

增加快取,業務應用先從快取中讀取熱門檔案資訊,沒有查詢到,則從資料庫中查詢,減少資料庫查詢次數。

整個優化邏輯如下:

  1. 先查快取,當快取存在,直接返回結果。
  2. 當快取不存在,查詢熱門視訊快取(快取不存在,則查詢hot表),當視訊為為熱門視訊時,查詢hotmovieaccess表。
  3. 當hotmovieaccess表存在結果時,直接返回,當hotmovieaccess表不存在記錄時,查詢movie表。
  4. 並快取查詢結果。

案例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:

  1. 單個分割槽鍵的行數不能超過10萬
  2. 單個分割槽的大小不超過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會造成以下危害:

  1. 流量集中,達到物理網絡卡上限。
  2. 請求過多,快取分片服務被打垮。
  3. DB擊穿,引起業務雪崩。

GaussDB(for Cassandra) 針對熱key問題,常見的修復手段如下:

  1. 設計上需要考慮熱key的問題,避免在資料庫上產生熱key
  2. 業務側通過增加快取來減少熱key出現的情況下對資料庫造成的衝擊。考慮多級快取解決熱key問題(如Redis + 本地二級快取)
  3. 遮蔽熱點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的大小,要控制大小,否則將影響效能和穩定性。超出後要及時優化。

 

點選關注,第一時間瞭解華為雲新鮮技術~