華為云數據庫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

  appid

  uid

  accessstring

  moviename

  access_time

表設計分析

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

解決方法：

1.優化表結構

創建新表保存熱門短視頻信息，只保留短視頻公共信息，不包含用戶信息，確保該表不會產生大的分區鍵。熱門短視頻信息寫入該表中。

CREATE

TABLE

hotmovieaccess

(

  movieid

  appid

  accessstring

  access_time

)

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

)

解決辦法：

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

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

大key的定義與檢測手段

通過長時間的業務觀察，我們規定以下閾值，超過任何一個條件的閾值即為大key：

1.單個分區鍵的行數不能超過10萬

2.單個分區的大小不超過100MB

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

熱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告警。如下

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

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

審核編輯黃昊宇