写点什么

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

  • 2024-06-04
    广东
  • 本文字数:1834 字

    阅读完需:约 6 分钟

从数据库设计到性能调优,全面掌握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 / 60MShard 数量受本地磁盘性能限制,因为不同 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 是一款开源分布式时序数据库,主要聚焦于海量时序数据的存储和分析,通过技术创新,简化业务系统架构,降低存储成本,提升时序数据的存储和分析效率。


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

发布于: 刚刚阅读数: 4
用户头像

提供全面深入的云计算技术干货 2020-07-14 加入

生于云,长于云,让开发者成为决定性力量

评论

发布
暂无评论
从数据库设计到性能调优,全面掌握openGemini应用开发最佳实践_数据库_华为云开发者联盟_InfoQ写作社区