从数据库设计到性能调优,全面掌握openGemini应用开发最佳实践

本文分享自华为云社区《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数据写入最佳实践

现在跟大家分享一下客户端写数据最佳实践的注意事项:

  1. 客户端批量写入,减少网络交互
  2. 客户端并发写入,确保多批次数据之间时间线不存在交叉,减少乱序数据的产生
  3. BatchSize指一次批量写入的数据大小,需多次实验,找到最为合适的值
  4. ts-sql并发分发数据能力是一定的,增加sql数量才能处理更多数据
  5. 写入并发比较大的情况下,可以适当减小BatchSize,否则ts-store容易造成数据堆积

写性能的内核参数调优:正常情况下,业务的写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 查询语句使用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

点击关注,第一时间了解华为云新鲜技术~

相关推荐
冬奇Lab8 小时前
一天一个开源项目(第40篇):copyparty - 单文件便携文件服务器,断点续传/去重/多协议/媒体索引
开源·资讯
运维老王11 小时前
用 Python 写一个自动化部署脚本(完整代码)
开源
聚客AI12 小时前
🎉OpenClaw深度解析:多智能体协同的三种模式、四大必装技能与自动化运维秘籍
人工智能·开源·agent
IvorySQL12 小时前
双星闪耀温哥华:IvorySQL 社区两项议题入选 PGConf.dev 2026
数据库·postgresql·开源
哈基咪怎么可能是AI12 小时前
OpenClaw 插件系统:如何打造全能私人助理 --OpenClaw源码系列第2期
开源·ai编程
卡尔AI工坊19 小时前
2026年3月,我实操后最推荐的3个AI开源项目
人工智能·开源·ai编程
Jahzo2 天前
openclaw本地化部署体验与踩坑记录--飞书机器人配置
人工智能·开源
Jahzo2 天前
openclaw本地化部署体验与踩坑记录--windows
开源·全栈
冬奇Lab2 天前
一天一个开源项目(第39篇):PandaWiki - AI 驱动的开源知识库搭建系统
人工智能·开源·资讯
HelloGitHub2 天前
这个年轻的开源项目,想让每个人都能拥有自己的专业级 AI 智能体
开源·github·agent