從資料庫設計到效能調優，全面掌握openGemini應用開發最佳實踐

华为云开发者联盟發表於2024-06-04
資料庫

本文分享自華為雲社群《DTSE Tech Talk × openGemini ：從資料庫設計到效能調優，全面掌握openGemini應用開發最佳實踐》，作者：華為雲開源。

在本期《從資料庫設計到效能調優，全面掌握openGemini應用開發最佳實踐》的主題直播中，華為雲開源DTSE技術佈道師&openGemini社群發起人Shawn，透過解析資料庫應用開發的一般流程與開發者們分享了熟悉業務場景是做好資料庫設計的關鍵這一重要觀點，並分別向大家介紹了openGemini庫和表設計、資料寫入、資料查詢的最佳實踐，希望能讓開發者們從優秀實踐中獲得新的啟發和提升。

熟悉業務場景是做好資料庫設計的關鍵

任何資料庫都不是萬能的，熟悉業務場景是做好資料庫設計非常關鍵的一環，同時，當了解清楚業務場景再去做資料庫選型時會給你帶來很大的幫助。做資料庫選型之前，大家可以按照以下8條去做細緻的評估：

  • 資料分類
  • 應用分類
  • 採集頻率(s)
  • 時間線評估
  • 每分鐘寫入資料量
  • 採集的指標
  • 業務查詢場景
  • 資料保留週期

從資料庫設計到效能調優，全面掌握openGemini應用開發最佳實踐

openGemini庫和表設計最佳實踐

當把業務場景都瞭解清楚過後，便可以做庫和表的設計了。Shard是openGemini的資料分片概念，openGemini支援shard延時載入，也就有了有活動shard和歷史shard的區別。每個shard有自己的索引和快取，增加DB，或者增加RP，都會增加同等數量的shard，也就增大了資料處理的併發度。個人建議在使用openGemini時採用多個庫，適度增加DB數量，有利於系統資源得到充分利用，並提升效能。

當機器規格一定時，支援的shard數量是有上限的
粗略的評估方法：shard數量 <= 總量記憶體 * 0.25 / 60M
Shard數量受本地磁碟效能限制，因為不同shard之間存在磁碟頻寬和I/O的競爭。

從資料庫設計到效能調優，全面掌握openGemini應用開發最佳實踐

shard或表過多，容易對系統效能造成影響：

  • DB/RP越多，shard越多，佔用記憶體資源會越大，磁碟I/O競爭越大
  • 表越多，資料檔案越多，佔用作業系統控制代碼資源越多
  • Shard和表越多，後設資料越多，ts-sql和ts-store與ts-meta之間同步後設資料時延大，會造成資料讀寫效能波動

表的設計原則：

  • 建表要結合查詢場景做綜合考慮
  • 建表要充分考慮指標列數量，大於1000列，建議開始分表

openGemini資料寫入最佳實踐

現在跟大家分享一下客戶端寫資料最佳實踐的注意事項：

  1. 客戶端批次寫入，減少網路互動
  2. 客戶端併發寫入，確保多批次資料之間時間線不存在交叉，減少亂序資料的產生
  3. BatchSize指一次批次寫入的資料大小，需多次實驗，找到最為合適的值
  4. ts-sql併發分發資料能力是一定的，增加sql數量才能處理更多資料
  5. 寫入併發比較大的情況下，可以適當減小BatchSize，否則ts-store容易造成資料堆積

從資料庫設計到效能調優，全面掌握openGemini應用開發最佳實踐寫效能的核心引數調優：正常情況下，業務的寫QPS是趨於穩定的，當出現比較大的波動時，引起原因可能是：資料量增大導致wal時延增加、磁碟IO瓶頸、資料快取堆積、Compaction阻塞等。

openGemini資料查詢最佳實踐

時間線比較多時（百萬以上），如下查詢場景要慎用，可能引發程序OOM：

  1. 全量時間線掃描，無TAG過濾
  2. 海量分組：TAG+Time | 細粒度Time
  3. 海量資料在ts-sql聚合場景（除first/last/count/sum/mean/min/max外）
  4. 海量時間線查詢, tag1=xxx 可能對應百萬時間線

從資料庫設計到效能調優，全面掌握openGemini應用開發最佳實踐

openGemini 查詢語句使用Tips：

1、查詢返回的資料量比較多時，推薦新增查詢引數：chunked=true&chunk_size=1000 ，可分批流式返回

例如：

curl -XPOST 'http://localhost:8086/query?db=mydb& chunked=true & chunk_size=1000 ' --data-urlencode 'q=SELECT * FROM mst'

2、在openGemini叢集中，一條時間線資料只屬於一個資料節點，因此在做簡單查詢時，可以使用Hint查詢，直接定位到具體資料節點查詢資料。

語法： /*+ full_series */

約束：查詢條件必須包含所有的TAG

例如:

SELECT /*+ full_series */ mean(C) FROM mst WHERE A=“a1” AND B=“b1” AND time > xxx AND time < xxx

3、巢狀查詢要遵循的原則：處在最裡層的子查詢儘可能透過TAG或者時間過濾資料，減少結果資料總量

例如：

SELECT * FROM
(SELECT temperature FROM disk_temp_monitor WHERE time > xxx AND time < xxx AND nd=“xxx” AND disk_type = SATA_HDD )
WHERE disk_type = SATA_HDD GROUP BY * LIMIT 1000

本次分享到這裡就結束了，openGemini社群旨在打造開放、合作、包容的全球性技術社群，歡迎大家試用openGemini時序資料庫，加入開源社群。

openGemini開源地址：https://github.com/openGemini

openGemini官網地址：https://opengemini.org

從資料庫設計到效能調優，全面掌握openGemini應用開發最佳實踐

openGemini是一款開源分散式時序資料庫，主要聚焦於海量時序資料的儲存和分析，透過技術創新，簡化業務系統架構，降低儲存成本，提升時序資料的儲存和分析效率。

從資料庫設計到效能調優，全面掌握openGemini應用開發最佳實踐

HDC 2024，6月21日-23日，東莞松山湖，期待與您相見！

更多詳情請參見大會官網：

中文：https://developer.huawei.com/home/hdc

英文：https://developer.huawei.com/home/en/hdc

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

相關文章