本文分享自華為雲社區《DTSE Tech Talk × openGemini :從資料庫設計到性能調優,全面掌握openGemini應用開發最佳實踐》,作者:華為雲開源。 在本期《從資料庫設計到性能調優,全面掌握openGemini應用開發最佳實踐》的主題直播中,華為雲開源DTSE技術佈道師&ope ...
本文分享自華為雲社區《DTSE Tech Talk × openGemini :從資料庫設計到性能調優,全面掌握openGemini應用開發最佳實踐》,作者:華為雲開源。
在本期《從資料庫設計到性能調優,全面掌握openGemini應用開發最佳實踐》的主題直播中,華為雲開源DTSE技術佈道師&openGemini社區發起人Shawn,通過解析資料庫應用開發的一般流程與開發者們分享了熟悉業務場景是做好資料庫設計的關鍵這一重要觀點,並分別向大家介紹了openGemini庫和表設計、數據寫入、數據查詢的最佳實踐,希望能讓開發者們從優秀實踐中獲得新的啟發和提升。
熟悉業務場景是做好資料庫設計的關鍵
任何資料庫都不是萬能的,熟悉業務場景是做好資料庫設計非常關鍵的一環,同時,當瞭解清楚業務場景再去做資料庫選型時會給你帶來很大的幫助。做資料庫選型之前,大家可以按照以下8條去做細緻的評估:
- 數據分類
- 應用分類
- 採集頻率(s)
- 時間線評估
- 每分鐘寫入數據量
- 採集的指標
- 業務查詢場景
- 數據保留周期
openGemini庫和表設計最佳實踐
當把業務場景都瞭解清楚過後,便可以做庫和表的設計了。Shard是openGemini的數據分片概念,openGemini支持shard延時載入,也就有了有活動shard和歷史shard的區別。每個shard有自己的索引和緩存,增加DB,或者增加RP,都會增加同等數量的shard,也就增大了數據處理的併發度。個人建議在使用openGemini時採用多個庫,適度增加DB數量,有利於系統資源得到充分利用,並提升性能。
當機器規格一定時,支持的shard數量是有上限的
粗略的評估方法:shard數量 <= 總量記憶體 * 0.25 / 60M
Shard數量受本地磁碟性能限制,因為不同shard之間存在磁碟帶寬和I/O的競爭。
shard或表過多,容易對系統性能造成影響:
- DB/RP越多,shard越多,占用記憶體資源會越大,磁碟I/O競爭越大
- 表越多,數據文件越多,占用操作系統句柄資源越多
- Shard和表越多,元數據越多,ts-sql和ts-store與ts-meta之間同步元數據時延大,會造成數據讀寫性能波動
表的設計原則:
- 建表要結合查詢場景做綜合考慮
- 建表要充分考慮指標列數量,大於1000列,建議開始分表
openGemini數據寫入最佳實踐
現在跟大家分享一下客戶端寫數據最佳實踐的註意事項:
- 客戶端批量寫入,減少網路交互
- 客戶端併發寫入,確保多批次數據之間時間線不存在交叉,減少亂序數據的產生
- BatchSize指一次批量寫入的數據大小,需多次實驗,找到最為合適的值
- ts-sql併發分發數據能力是一定的,增加sql數量才能處理更多數據
- 寫入併發比較大的情況下,可以適當減小BatchSize,否則ts-store容易造成數據堆積
寫性能的內核參數調優:正常情況下,業務的寫QPS是趨於穩定的,當出現比較大的波動時,引起原因可能是:數據量增大導致wal時延增加、磁碟IO瓶頸、數據緩存堆積、Compaction阻塞等。
openGemini數據查詢最佳實踐
時間線比較多時(百萬以上),如下查詢場景要慎用,可能引發進程OOM:
- 全量時間線掃描,無TAG過濾
- 海量分組:TAG+Time | 細粒度Time
- 海量數據在ts-sql聚合場景(除first/last/count/sum/mean/min/max外)
- 海量時間線查詢, tag1=xxx 可能對應百萬時間線
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是一款開源分散式時序資料庫,主要聚焦於海量時序數據的存儲和分析,通過技術創新,簡化業務系統架構,降低存儲成本,提升時序數據的存儲和分析效率。
HDC 2024,6月21日-23日,東莞松山湖,期待與您相見!
更多詳情請參見大會官網:
中文:https://developer.huawei.com/home/hdc
英文:https://developer.huawei.com/home/en/hdc