【DTSE Tech Talk 精选问答】NO.36丨openGemini时序数据库应用场景与技术实践

围绕场景、案例、架构、功能、性能、开发、成本等方面，帮助开发者更容易、更清晰的了解openGemini是什么，要解决什么问题，提供哪些能力，差异化竞争力是什么，性能如何，如何使用（安装部署、应用开发等）以及如何运维等一系列问题。
直播链接：https://bbs.huaweicloud.com/live/DTT_live/202307191630.html

※ 关于openGemini ※

Q：时序数据库是否支持与批处理系统的集成？？

A：可以与批处理系统集成，比如AI模型训练、报表生成、Spark/Flink数据分析等。目前支持Spark和Flink，其他的比如AI分析框架或者报表工具暂时不能直接支持，需要开发对应的Connector或者基于SDK开发功能模块

Q：openGemini是否自动支持特定时间间隔的汇总？

A：支持，如果仅仅对某个时间范围内的数据（目标数据量不是很大）按特定时间间隔汇总，可以直接使用select语句或者select into语句。如果目标数据量太大，建议使用openGemini将要推出的continue query功能，如果不需要保留历史数据明细，可以使用openGemini提供的多级降采样功能。

Q：如何优化时序数据库的存储和查询，以提高数据的处理效率？

A:1. 如果可以接受部分数据丢失，可以设置不写WAL;2. 尽可能批量写;3. 增加openGemini的缓存占比;4. Tag名字尽量简短；可以指定分区键，减少网络扇出度。

Q：openGemini对于CPU 资源有哪些要求？

A：部署节点的CPU至少4核起步

Q：如何在应用程序中使用openGemini时序数据库进行事务处理和并发控制？

A：openGemini不支持事务，数据一旦成功写入便不能回滚。

Q：openGemini的应用开发流程是怎样的，下载sdk、配置文件、创建连接、创建表？比如，开发者如何利用openGemini进行数据的读写操作。

A：openGemini的开发流程是：下载openGemini二进制或者源码编译，修改配置文件并启动openGemini单机或者集群节点、创建库和表、下载SDK、基于SDK开发读写数据功能模块进行数据读写。 各语言的SDK下载地址可以参考社区主目录下README中给出的链接。每种语言的SDK项目中都提供了DEMO

Q：企业如何建设时序数据库基准测试和标准？

A：基准测试有3个要素：数据、负载和度量体系。简单来说，做时序数据库基准测试和标准，需要考虑测试的数据模型是什么样，测试模型和负载如何设计，设计哪些性能度量指标。企业要做这方面的基准测试，需要注意标准的公正、公平和客观性，避免出现基准之争。建议和开源社区以及典型企业共同来做，这是一件非常有意义的事情。openGemini表示支持。

Q：openGemini是否有详细的文档和教程或者案例？比如，是否有官方文档和教程以帮助开发者快速上手和解决问题。

A：openGemini有快速上手的文档，见：https://docs.opengemini.org/zh/guide/quick_start/get_started.html 目前还欠缺的内容包括内置函数和新特性的功能、示例介绍。暂时可以先参考InfluxDB的文档：https://docs.influxdata.com/influxdb/v1.8/，所有算子用法是兼容的。 openGemini自身运维监控参考：https://mp.weixin.qq.com/s/hbb3CnVWCqBulIvgNU_bIw

Q：openGemini时序数据库是否支持数据可视化和报表生成？

A：openGemini支持Grafana进行数据可视化展示，但不能生成表表，需要有额外的开发工作。

Q：openGemini是否支持多种操作系统和平台？比如，可以在docker、x86,鸿蒙、麒麟、Linux、Windows等不同操作系统上运行。

A：支持docker、K8s、KubeEdge、x86、ARM64、Linux（openEuler、Ubuntu、Centos、Redhat等），windows将于下个版本支持。暂时还没有适配国产的其他操作系统，比如麒麟、鸿蒙。

Q：openGemini是否支持多种存储介质和存储引擎？

A：目前支持两种存储引擎（默认存储引擎和高基数存储引擎），openGemini采用Go语言开发，操作系统和Go语言标准库屏蔽了底层存储介质，不管是SSD和HDD，对openGemini来说是不感知的。

Q：openGemini时序数据库能否用于数据仓库和数据湖的集成？

A：可以用于集成，主要存储时序类型的指标、日志等数据。但目前没有开发集成工具来实现。

Q：写入数据页时发送断电数据文件和数据页是否会导致数据损坏？

A：openGemini写数据时，会先写WAL文件，再写缓存，缓存满了再刷磁盘文件存储。如果数据在写WAL文件时断电，数据写失败，这部分数据会丢失，写WAL成功后，再断电，数据不会丢失，通过WAL回放会重新找回数据。

Q：openGemini 时序数据库处理和分析结构化、非结构化和半结构化数据的方式有哪些不同？

A：结构化数据支持友好，半结构化数据需要进行数据各式转换后才能存储在openGemini中，比如XML、JSON, 或者把整个XML或者JSON内容按照string类型存储也可以，暂不支持对非结构化数据的处理。 具体使用场景，可以联系我进行交流，这方面需求如果很普遍，社区可以考虑新增支持半结构化数据的数据类型。

Q：openGemini如何保证实时数据服务。提供数据的实时值的查询、修改？

A：openGemini并不是严格的实时系统，所有设备（时间线）的数据，写第一条数据时，由于要创建倒排索引，需要在写入成功后等待1s后查到，随后的数据可以即写即查。 没有单独的更命令，如果需要更新，可以重写，确保时间与待修改数据的时间保持一致

Q：openGemini时序数据库在华为云SRE中如何进行进行故障排除和性能调试？

A：使用openGemini自身提供的监控手段，在SRE中为openGemini集群搭建了监控面板，监控指标包括磁盘存储空间、CPU和内存利用率，写入带宽、查询时延、查询QPS、WAL时延等等，根据指标面板分析发现潜在问题，再进行问题排查。举个例子，某一次SRE给openGemini做版本升级后，通过面板发现写入性能存在明显的毛刺。如下是排除和解决的过程：

1. 求证业务是否平稳，是否因为业务流量原因导致，询问后排除。
2. 查看内核其他指标面板是否正常，发现写memtable时延波动明显，写WAL以及流控令牌获取均有不等的毛刺，推测是GC导致。
3. 求证，使用pprof抓取火焰图，重点分析火焰图上颜色较深的部分，通过内存池化或者减少这部分函数内的变量数量和内存申请次数进行优化，优化后再一次抓取火焰图，发现有明显的改善，毛刺消失了。
   
   
   

Q：openGemini数据容量取决于服务器存储的容量吗？在大容量下是否能保持较高的数据读取性能？

A：openGemini中，数据按时间范围进行分区，理论上没有数据容量上限，取决于服务器存储的容量大小，openGemini的数据读取性能取决于目标数据量规模，规模越大，读取数据的时间相对更长，比如历史数据有1PB，但是每次查询1天内的数据，性能同样是很高效的。

Q：openGemini适用于哪些具体的场景？比如，适用于物联网、金融行业或其他需要处理大量时序数据的场景。

A：适用于物联网、车联网、运维监控、电力、能源、制造业、物流、智能建筑、金融等存在大量遥测数据存储和分析的场景

Q：openGemini时序数据库如何优化数据插入和存储问题？

A：数据插入优化建议：

1. 尽量采用批量写入，减少网络交互次数
2. 集群模式下，数据写入压力尽量分散到不同的ts-sql上
3. 如果内存资源充足，可以开启Hot模式（对应配置文件：shard-tier= hot）
4. 如果内存资源充足，可以适当调大缓存的占比，默认10%（imm-table-max-memory-percentage）
   
   
   

Q：openGemini兼容现有哪些时序数据库工具链？

A：

• 数据可视化工具：Grafana、Chronograf等

• 大数据分析工具：Flink、Spark等

• SDK驱动：兼容已有的C/C++, Java, Python, Javascript, Rust, Go等SDK

• 其他：支持InfluxDB的带界面的客户端

Q：openGemini支持信创操作系统吗？目前在行业内成熟的应用或者解决方案有哪些？

A：信创的操作系统中仅支持openEuler。目前openGemini整理的行业内成熟的解决方案有：

1. 基于openGemini + EMQ + Kuiper + grafana的物联网数据可视化解决方案
2. openGemini + ngix的集群负载均衡解决方案
3. openGemini作为prometheus后端存储的解决方案
4. openGemini + KubeEdge的边缘计算解决方案
   等等，还有更多待挖掘
   
   

Q：如何评估和比较不同时序数据库的性能和功能？主要依据哪些项目测试和指标？

A：性能和功能评估这块，先说性能：

1. 需要了解自己的业务，比如需要存储什么数据，有哪些字段，1分钟或者1秒钟需要写入的数据量大约是多大，单条数据长度，并发量多大，未来预期增长水平，能接受的最大查询时延，自己能提供的机器规格是多大，购买硬件设备的预算是多少等等。
2. 依据上述类容，使用现有的测试工具（比如TSBS）进行多种数据库进行性能对比，同时还要自己写一些测试程序来完成和业务相关的性能和功能测试，包括稳定性
3. 测试指标通常是写入平均速度、查询平均时延两大类，部分业务可能关注查询的P95、P99性能数据。
   功能方面：了解自己业务痛点和现有的查询语句，对比其他时序数据库提供的能力。
   
   

Q：企业如何针对时序数据库建设基准测试项目和测试标准？

A：基准测试有3个要素：数据、负载和度量体系。简单来说，做时序数据库基准测试和标准，需要考虑测试的数据模型是什么样，测试模型和负载如何设计，设计哪些性能度量指标。企业要做这方面的基准测试，需要注意标准的公正、公平和客观性，避免出现基准之争。建议和开源社区以及典型企业共同来做，这是一件非常有意义的事情。openGemini表示支持。

Q：openGemini 单机和分布式的语法都是一样的吗？openGemini能否根据硬件情况自动调优

A：单机和集群的语法是一样的。 openGemini还不能根据硬件情况自动调整参数优化，这需要大量的应用案例学习。而且这件事情很复杂，仅仅根据硬件情况只能优化一小分部参数，比如缓存、并发数量等。硬件上运行的应用有可能读多写少，有可能写多读少，也有可能读写差不多，有可能时间线很少，但数据量很大，也有可能时间线很多，单条时间线数据量很少，这些情况有需要重新调整缓存和并发，以及其他参数。这也是一个值得研究的问题。

※ openGemini 优势 ※

Q：时序数据库相比传统数据库有哪些核心特性，什么情况下有必要选择openGemini？

A：相比传统数据库，openGemini的核心特性有：针对时序业务特点和时序数据特点做了垂直优化，在架构上：采用MPP架构，支持大规模横向扩展，满足更大的业务负载要求。在数据存储上：提供数据批量写入、时间范围分片、冷热分级存储、列式存储、数据压缩、LSM等能力，解决海量数据持续写入性能问题；在数据分析方面：提供数据预聚合、滑窗聚合、降采样、流式聚合、时序异常检测/预测、日志检索等功能，解决数据分析效率问题。总的来说，openGemini具备高性能、高扩展、低存储成本等优势。

什么情况下有必要选择openGemini？前提是处理时序业务的情况下。
首先：如果使用了关系数据库存储时序数据，即使还未出现性能问题，也建议换到openGemini，因为迟早会出现性能问题。
其次：当你使用其他时序数据库时，比如InfluxDB、openTSDB等，如果已经出现性能问题，可以考虑openGemini。如果预期业务会有大的增长，接入的时间线/设备数量大幅增多，可以考虑openGemini。
再次：如果使用了NoSQL数据库，出现查询语言表达弱、存储成本较高、计算和内存资源长期消耗大，这种情况有必要选择使用openGemini。

Q：openGemini的成本如何？比如，相比其他时序数据库是否更具有成本优势。

A：测试结果来看，TSBS生产的测试数据，共计25亿条，纯文本800GB，压缩后88GB，写入到openGemini后只有14GB，数据压缩比在60:1左右。从实际生产环境来看，华为云SRE业务中，压缩比是15:1。相比其他时序数据库（比如TD），相同数据集，openGemini数据压缩率更高，最终数据量比TD还少70%-200%不等。

Q：openGemini是否支持数据的加密和安全性控制？比如可以对数据进行加密以保证数据的安全性。

A：openGemini支持数据传输加密，可以在配置文件中打开https，配置安全证书即可。节点之间数据传输也支持数据加密。另外，openGemini支持用户权限控制，并且普通用户只能看到自己创建的库和表。 参考文档： https://docs.opengemini.org/zh/guide/manage/https.html https://docs.opengemini.org/zh/guide/manage/authentication_and_authorization.html

Q：openGemini相比其他时序数据库有什么具体的差异化竞争力？

A：大的方面有两个：性能和功能

性能方面，当前在Devops场景下，性能处于领先优势。
6大功能，提高差异化竞争力，包括高基数引擎（解决了高基数问题），基于AI的异常检测和预测（解决数据分析问题），多级降采样（进一步降低存储成本），日志存储于检索，流计算等。

Q：时序数据库灾备和恢复有什么解决方案吗

A：进程级的灾备可以通过数据多副本和看门狗实时监测进程状态并拉起进程的办法解决，跨机房可以通过数据双写、数据订阅的方式解决。跨地域的情况，通常不要求数据实时同步，可以定期通过全量/增量备份的方式解决。

Q：针对不同时序业务场景，openGemini扩展性能怎么样？是否支持组件单独扩展？

A：openGemini在华为云SRE业务中共部署有25套集群，最大集群规模是70节点，openGemini实际可以支持100+节点规模。支持openGemini的组件单独扩展。

Q：openGemini是否支持数据的分区和分片？例如，可以将数据分散存储在多个节点或服务器上以提高性能和可扩展性。

A：openGemini支持数据的分区和分片，默认按时间线分区，也可以按指定分区键分区。默认按时间分片，创建database时设定分片的时间范围。 参考文档：https://docs.opengemini.org/zh/guide/geminiql/sql_syntax/DDL/create_database.html https://docs.opengemini.org/zh/guide/geminiql/sql_syntax/DDL/create_measurement.html

Q：使用openGemini时序数据库如何保障数据安全和访问控制？

A：openGemini支持数据传输加密，可以在配置文件中打开https，配置安全证书即可。节点之间数据传输也支持数据加密。另外，openGemini支持用户权限控制，并且普通用户只能看到自己创建的库和表。 参考文档： [https://docs.opengemini.org/zh/guide/manage/https.html](https://docs.opengemini.org/zh/guide/manage/https.html) [https://docs.opengemini.org/zh/guide/manage/authentication_and_authorization.html](https://docs.opengemini.org/zh/guide/manage/authentication_and_authorization.html)

Q：如果发生故障，有哪些协议可以避免数据不一致的问题？

A：首先，时序数据库一般没有数据更新的操作，所以并发写入不会造成数据不一致的情况。即使有更新操作，也是做历史数据的修正，不太可能出现并发修正同一条数据的情况。 其次，raft协议主要用于主从节点数据同步，应用非常广泛，但它仍无法避免数据不一致问题，一旦出现问题，还需要人工干预。

※ 关于开源 ※

Q：新手小白如何参与openGemini开源项目贡献？

A：openGemini的贡献可分为代码和非代码贡献，非代码包括文档以及翻译、活动策划、社区运营、社区大使、技术文章分享、源码分享等。代码贡献包括内核功能特性开发、Bug修复、测试用例编写、周边工具开发、生态集成工具开发等。 至于如何参与项目贡献，可以先联系社区，告知你的擅长领域和方向，根据你的情况，社区会提供相关的开发、运营、文档编写等方面的指导。目前社区有很多事情可以做，但还没有全部都以issue的方式发布出来。新手小白，可以从贡献文档、修复简单Bug、简单的小功能做起，也可以参与到社区运营、活动策划中。

※ openGemini 未来发展 ※

Q：openGemini的发展规划和未来展望如何，计划是怎么样的向那个方向发展？

A：openGemini未来的发展规划主要分为三个方面：

1. 性能方面：在运维监控和物联网场景上持续进行内核性能优化，很多优化的点可以做。
2. 功能方面：功能需求的来源有两个方面，一个是社区用户，另一个是社区伙伴。未来还将在日志数据存储和检索方面新增更多的功能，还会支持调用链数据存储，打造可观测性领域统一的数据存储底座。在物联网方面，将会联合伙伴开发更适合工业场景的功能。
3. 生态方面社区会在生态工具上持续投入，打通数据采集-存储-分析全链路上的主流生态。包括但不限于数据迁移工具、数据接入中间件、大数据生态集成工具、AI分析平台、可视化、报表、数据湖、数据集市等。
   
   
   

想要了解更多openGemini相关知识，欢迎观看DTSE Tech Talk 系列技术直播