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

Cassandra 資料庫是一個高度可擴充套件的高效能分散式資料庫，面向大資料場景，可用於管理大量的結構化資料。在業務使用的過程中，隨著業務量和資料流量的持續增長，往往一些業務的設計弊端逐漸暴露出來，降低了叢集的穩定性和可用性。比如主鍵設計不合理，單個分割槽的記錄數或資料量過大，出現超大分割槽鍵，引起了節點負載不均，叢集穩定性會下降，這一類問題稱為大key問題。當某一熱點key的請求在某一主機上的訪問。

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的大小，要控制大小，否則將影響效能和穩定性。超出後要及時最佳化。