[TSDB] OpenGemini 综述：原理与架构
0 序： 续接《OpenGemini 安装指南》/《OpenGemini 运维指南》
1 概述：OpenGemini
OpenGemini
OpenGemini是一款面向物联网、车联网、工业互联网、运维监控等领域的，由华为发起的、基于Go-Lang语言开发的开源、分布式、时序数据库。
相比同样是高性能的开源时序数据库 Top1 的 InfluxDB，OpenGemini 有如下优势:
- 兼容 InfluxDB 的大部分特性
- 架构分布式（节点横向扩展）
InfluxDB 的集群版，需采购商业付费版，而 开源的 OpenGemini 天然支持。
- 读写分离
ts-store / ts-sql / ts-meta 进程
三大特点
OpenGemini是一款存储与分析并重的高性能时序数据库，具有的显著特点：
- 开源
OpenGemini采用的开源License是Apache 2.0，对商业友好，伙伴和开发者可以基于openGemini发布自己的商业版本，也可以基于openGemini搭建运维监控系统，还可以基于openGemini开发监控类产品和服务、构建车联网、物联网以及工业物联网平台等。
- 高性能
OpenGemini从孵化到开源，长期背靠华为云SRE运维监控业务，在产品打磨的过程中造就了openGemini卓越的读写性能和高效的数据分析能力。
- 分布式
单机版数据库始终受计算资源限制，无法获得更高的吞吐量和性能。
因此，openGemini从诞生一刻起就设计了分布式集群架构，具备良好的可扩展性和灵活性。
专注海量遥测数据存储分析场景
- 近年来，随着云计算、AI、5G、物联网等众多新技术的发展和普及，数字化转型如火如荼，在车联网、制造业、物流、电力、物联网、工业互联网、运维监控等领域的数据量出现猛增。
例如大型车企一天采集的车辆数据就在PB级；TOP级云厂商每天采集的运维数据超过数十TB。
- 面对如此海量的遥测数据，openGemini通过对上述场景中数据和业务特点深入了解，提出针对性的设计和技术优化方案，实现了集群高并发、高扩展、低时延、低成本的时序数据库系统。
-
目前，
openGemini已正式在华为云工业物联平台中商业化落地，同时也在支撑整个华为云的运维监控业务，在全网部署有约25套集群，最大集群规模为70节点，日均处理20TB数据，写TPS 4000万条/秒，读QPS 5万/秒。 -
在openGemini开源的数个月里，和社区取得联系并正式接入业务进行测试和适配的已知企业有46家。后起之星火，大有燎原的态势。
6大能力凸显openGemini差异化竞争力
- 性能优势：在openGemini差异化竞争力中，高性能是最重要的一项。
openGemini 相比开源 InfluxDB，简单查询场景提升 2 倍多，中等查询场景提升 5 倍多，复杂查询场景下，openGemini 依然可以快速响应，然而 InfluxDB 则出现
OOM无法工作。
此外，openGemini 新研发的高基数引擎，支持时间线无上限，进一步扩大了应用范围。
需要了解与其他同类产品的性能对比，可以在官网找到联系方式进行索要。
除此之外，openGemini在数据存储和数据分析方面推出一系列实用功能，以此构建更多差异化竞争力，主要功能如下：
- 流式聚合：流式聚合是一种前置聚合方式，一边写数据、一边对数据进行降采样.
其目的是解决传统降采样方法从磁盘读取大量历史数据进行计算，造成
I/O放大严重的问题。
- 多级降采样：对于存量的历史数据，传统降采样方式会保留历史数据明细。
在某些场景下，历史数据明细并不重要，只需保留数据特征即可，多级降采样功能可以实现对历史数据明细的特征提取，并原地替换历史数据明细，可进一步降低50%的存储成本。
- 日志检索：日志数据是一种特殊的时序数据，多数时序数据库支持日志存储，但仅仅是存储日志数据时还远远不够，日志检索和分析才是存储日志的最终目的。
主流针对日志的处理多使用ELK技术栈，但面对海量日志时，ES也变得很吃力。
openGemini采用动态分词方法，在内核实现了全文索引，且具有内存资源占用少，检索效率高的优点，欢迎大家试用和反馈。
-
异常检测和预测：openGemini针对时序数据的最终应用开发了基于AI的数据分析框架，可实现对时序数据的异常检测和预测，可检测13种常见的异常场景，具有检测速度快、准确性高、流批一体的优点，让数据就近处理，提高数据分析效率。
-
高基数引擎：高基数会带来索引膨胀，从而引起内存资源消耗过高，读写性能降低，长期以来一直困扰着时序数据库的发展。
openGemini从
AP系统中寻找到解决办法，研发了全新的高基数引擎HSCE，可支持时间线无上限。
目前核心能力已具备，正在完善高基数引擎下的各种聚合方法（计划2023年9月可完成）。
核心能力加持，场景应用更宽广
- 除上述差异化能力之外，openGemini的核心能力还包括: 完全兼容InfluxDB 1.x APIs、算子（函数）和数据行协议，可作为 Promethus 和 openTelemetry 的后端存储，支持数据可靠性（计划2023年9月份推出）、物化视图、数据分区分片（支持指定分区键）、数据保留策略等。
强大组件提升运维管理能力 (ts-monitor)
- 为提升openGemini的运维效率，社区开发了
ts-monitor组件，专门采集节点和内核指标，可搭配Grafana实现对openGemini运行状态的全面监控。
例如CPU和内存利用率、写入带宽、写时延、写并发、QPS等指标可以通过可视化界面一目了然。
拥抱生态，助力应用开发
- 由于openGemini对
InfluxDB的兼容。
因此，应用于InfluxDB的数据接入工具、SDK、数据洞察工具、大数据分析工具等都能直接应用在openGemini之上。
- 操作系统方面，openGemini目前已经对主流Linux系统、X86和ARM64的CPU架构支持，下个版本上可支持MAC和Windows；
- 云原生方面，openGemini支持Docker、K8s、KubeEdge等平台的部署，为方便在K8s部署，社区创建了openGemini-operator项目；
- 数据迁移方面，提供了InfluxDB向openGemini的数据迁移工具，ES迁移数据到openGemini的工具正在开发中，预计8月份可提供；
- 管理工具方面，数据导出已支持，备份恢复和GUI管理工具正在社区开发中，9月份可以和大家见面。
总结起来，openGemini支持多种主流开发语言和操作系统平台、与InfluxDB的第三方工具无缝衔接、支持多形态的部署及应用。
openGemini 优势
Q：时序数据库相比传统数据库有哪些核心特性，什么情况下有必要选择openGemini？
-
相比传统数据库，openGemini的核心特性有：针对时序业务特点和时序数据特点做了垂直优化，在架构上：采用
MPP架构，支持大规模横向扩展，满足更大的业务负载要求。在数据存储上：提供数据批量写入、时间范围分片、冷热分级存储、列式存储、数据压缩、LSM等能力，解决海量数据持续写入性能问题；在数据分析方面：提供数据预聚合、滑窗聚合、降采样、流式聚合、时序异常检测/预测、日志检索等功能，解决数据分析效率问题。总的来说，openGemini具备高性能、高扩展、低存储成本等优势。 -
什么情况下有必要选择openGemini？前提是处理时序业务的情况下。
首先：如果使用了关系数据库存储时序数据，即使还未出现性能问题，也建议换到openGemini，因为迟早会出现性能问题。
其次：当你使用其他时序数据库时，比如InfluxDB、openTSDB等，如果已经出现性能问题，可以考虑openGemini。如果预期业务会有大的增长，接入的时间线/设备数量大幅增多，可以考虑openGemini。
再次：如果使用了NoSQL数据库，出现查询语言表达弱、存储成本较高、计算和内存资源长期消耗大，这种情况有必要选择使用openGemini。
Q：openGemini的成本如何？比如，相比其他时序数据库是否更具有成本优势。
- 测试结果来看，TSBS生产的测试数据，共计25亿条，纯文本800GB，压缩后88GB，写入到openGemini后只有14GB，数据压缩比在60:1左右。
从实际生产环境来看，华为云SRE业务中，压缩比是15:1。
相比其他时序数据库（比如TD），相同数据集，openGemini数据压缩率更高，最终数据量比TD还少70%-200%不等。
Q：openGemini是否支持数据的加密和安全性控制？
比如可以对数据进行加密以保证数据的安全性。
- openGemini支持数据传输加密，可以在配置文件中打开https，配置安全证书即可。
节点之间数据传输也支持数据加密。
另外，openGemini支持用户权限控制，并且普通用户只能看到自己创建的库和表。
参考文档：
Q：openGemini相比其他时序数据库有什么具体的差异化竞争力？
- 大的方面有两个：性能和功能
性能方面，当前在Devops场景下，性能处于领先优势。
6大功能，提高差异化竞争力，包括高基数引擎（解决了高基数问题），基于AI的异常检测和预测（解决数据分析问题），多级降采样（进一步降低存储成本），日志存储于检索，流计算等。
Q：时序数据库灾备和恢复有什么解决方案吗
- 进程级的灾备可以通过数据多副本和看门狗实时监测进程状态并拉起进程的办法解决。
- 跨机房可以通过数据双写、数据订阅的方式解决。
- 跨地域的情况，通常不要求数据实时同步，可以定期通过全量/增量备份的方式解决。
Q：针对不同时序业务场景，openGemini扩展性能怎么样？是否支持组件单独扩展？
- openGemini在华为云SRE业务中共部署有25套集群，最大集群规模是70节点，openGemini实际可以支持100+节点规模。支持openGemini的组件单独扩展。
Q：openGemini是否支持数据的分区和分片？例如，可以将数据分散存储在多个节点或服务器上以提高性能和可扩展性。
- openGemini支持数据的分区和分片，默认按时间线分区，也可以按指定分区键分区。
默认按时间分片，创建database时设定分片的时间范围。
参考文档：
Q：如果发生故障，有哪些协议可以避免数据不一致的问题？
- 首先，时序数据库一般没有数据更新的操作，所以并发写入不会造成数据不一致的情况。
- 即使有更新操作，也是做历史数据的修正，不太可能出现并发修正同一条数据的情况。
- 其次，
raft协议主要用于主从节点数据同步，应用非常广泛，但它仍无法避免数据不一致问题，一旦出现问题，还需要人工干预。
openGemini 未来发展
openGemini的发展规划和未来展望如何，计划是怎么样的向那个方向发展？openGemini未来的发展规划主要分为三个方面：
-
性能方面：在运维监控和物联网场景上持续进行内核性能优化，很多优化的点可以做。
-
功能方面：功能需求的来源有两个方面，一个是社区用户，另一个是社区伙伴。
未来还将在日志数据存储和检索方面新增更多的功能，还会支持调用链数据存储，打造可观测性领域统一的数据存储底座。
在物联网方面，将会联合伙伴开发更适合工业场景的功能。
- 生态方面：社区会在生态工具上持续投入，打通数据采集-存储-分析全链路上的主流生态。
包括但不限于数据迁移工具、数据接入中间件、大数据生态集成工具、AI分析平台、可视化、报表、数据湖、数据集市等。
2 工作原理与架构
集群架构
-
openGemini整体上由ts-sql、ts-meta、ts-stores三个组件组成
-
ts-sql
对外提供统一的读写接口。在数据写入方面，校验接收到的数据格式，再根据时间线名称进行hash打散，转发数据到对应的ts-store节点进行存储；在数据查询方面，根据请求生成分布式查询计划，分发各子查询计划到每个ts-store节点，最后汇总数据并返回Client。
ts-sql是无状态的，可以根据业务负载进行横向扩展。
- ts-meta
管理数据库系统中的数据库、表、数据分区、数据保留策略、集群等元数据信息。
- ts-store
数据存储和查询。采用类LSM Tree结构，数据追加写入；数据查询时，执行子查询计划，从倒排索引中检索查询涉及的时间线，数据读取后，根据查询条件过滤数据，再返回数据到ts-sql。
同样可以根据业务负载进行ts-store节点的横向扩展，暂不支持缩容。
ts-server: 单机版 open gemini
多用于做监控库
WAL文件 vs. TSSP文件
OpenGemini是一款面向物联网、车联网、工业互联网、运维监控等领域的开源分布式时序数据库。在openGemini中，
WAL（Write-Ahead Logging）文件和TSSP（Time Series Storage Protocol）文件扮演着重要的角色，以下是关于它们的用途及关系的详细解释：
WAL文件
用途
- WAL文件主要用于记录数据库中的所有写操作，确保数据的一致性和持久性。
- 在数据写入内存的同时，这些操作会被记录到WAL文件中。
- 如果数据库系统发生故障或崩溃，重启后可以通过重新执行WAL文件中的操作来恢复数据，从而保证数据的可靠性。
TSSP文件
用途
- TSSP文件是openGemini用于存储时序数据的主要文件格式。
- 在数据写入openGemini后，系统会按照自己定义的数据格式重新组织数据，并压缩存储到后缀名为tssp的数据文件中。
- 这些文件不仅包含了实际的数据值，还可能包含数据的元数据（如时间戳、标签等）以及数据的压缩和编码信息。
- TSSP文件的设计旨在优化时序数据的存储和查询性能。
WAL文件与TSSP文件的关系
- 数据写入流程：在openGemini中，数据首先被写入内存，并同时记录到
WAL文件中。随后，这些数据会经过一系列的处理和压缩，最终存储到TSSP文件中。
因此，
WAL文件可以看作是数据写入过程中的一个临时记录，而TSSP文件才是数据的最终存储形式。
-
故障恢复：在数据库系统发生故障或崩溃时，WAL文件可以用于恢复数据。通过重新执行WAL文件中的写操作，可以确保内存中的数据与TSSP文件中的数据保持一致，从而避免数据丢失或不一致的情况。
-
性能优化：
- 虽然
WAL文件在数据写入过程中增加了额外的写操作，但这一机制对于确保数据的可靠性和持久性至关重要；- 同时，通过优化
TSSP文件的存储和查询性能，OpenGemini 可以在保证数据可靠性的同时，提供高效的数据处理能力。
综上所述，WAL文件和TSSP文件在openGemini中各自扮演着重要的角色，它们共同确保了数据的可靠性、持久性和高效处理能力。
数据多副本机制
- 参考文献
- 数据多副本机制 - OpenGemini 2023.8.4
这是一个实验特性，当前解决了多副本的稳定性问题，但还存在性能问题暂未解决
数据多副本机制
- openGemini的数据副本能力，可以满足工业、能源、物联网、运维监控等领域对数据可靠性的要求。
- 当前版本的数据副本主要基于
raft协议实现，在大量数据密集写入的场景下，副本能力对写性能有一定的影响。
- 后续版本会不断迭代，进一步优化数据副本分布，并推出新的数据副本协议：
- 解决写性能损伤的问题（当前版本多副本写性能劣化比较严重）
- 支持2数据副本，当前主要受raft协议限制，必须3个数据副本起
适用范围与局限性
- 特别说明
- 单机版本(ts-server)不支持数据副本
- 当前为【DB级】数据副本，不支持【表级】数据副本
- 集群中
ts-store节点数量必须是副本数量的倍数。换句话说，如果是3副本，ts-store节点数量至少是3个，可以是6个或者9个
v1.2.0及以下版本的集群不能平滑升级到多副本集群，需要做数据迁移。社区提供数据导入导出工具以支撑数据迁移
- 建议多副本集群的
ts-store节点规格更大一些。因为副本数据同样会消耗存储和计算资源。尤其是出现故障时，其中一些节点因为需要业务接管，从而导致的压力会比原来更大，要为突发情况预留一些空间
配置/使用
- 修改配置文件 openGemini.conf
[common]
ha-policy = "replication"
[meta]
ptnum-pernode = 2 # 每个节点的PT数量，推荐设置为2
- 创建数据库，指定副本数量为3，目前副本数仅支持大于0的奇数。
CREATE DATABASE db0 WITH REPLICATION 3
PT是单词Partition的缩写，是openGemini数据管理的一个逻辑概念。
举个例子，假设有100台设备数据，如果数据库下面仅有一个PT，那么数据全部存到该PT下。如果有2个PT，那么每个PT会各自管理50台设备数据。
PT之间是可以并发处理数据，理论上如果资源充足的情况下，多PT性能会更优。
DB、PT、RP、SHARD、MEASUREMENT之间的关系
副本数据分布
示例1： ptnum-pernode = 1，ts-store 3个
每个节点仅有一个PT，数据会写入PT leader节点，其他两个节点只能作为被动的数据同步节点，无法分担业务压力，类似一主两从。
示例2： ptnum-pernode = 2，ts-store 3个
每个节点仅有2个PT，3个节点可以组成2个raft组，每个组一个pt leader，落在不同节点上，可以分担业务压力。
示例3： ptnum-pernode = 3，ts-store 3个
每个节点有3个PT，3个节点可以组成3个raft组，每个组一个pt leader，落在不同节点上，可以分担业务压力。由于每个节点都有2个副本PT会同步写入数据，因此会占用部分计算和存储资源。建议适当扩大节点规格。
示例4： ptnum-pernode = 3，ts-store 4个
每个节点有3个PT，4个节点依然只能组成3个raft组，剩余ts-store-4节点由于无法找到更多节点与其组成raft组，因此该节点上的PT是离线的，无法工作。
示例5： ptnum-pernode = 3，ts-store 6个
每个节点有3个PT，6个节点组成6个raft组，数据按时间线hash打散分布在节点上。
读写策略与节点故障
- 每个副本组会选出一个【主pt】，读写请求只会路由到 leader pt上，通过ts-meta来统一管理所有副本组主pt的选举使其在节点间尽量均匀分布。
如下图所示，若ts-store-1节点故障，则原来raft group 1在ts-store-2上的pt follower会被选为新主，承接业务数据。
多AZ部署进阶
- 前提条件是: 集群跨AZ部署。修改配置文件openGemini.conf
[data]
availability-zone = "az1"
[meta]
rep-dis-policy = 1
- 配置文件修改后启动，配置项 availability-zone 标识ts-store节点所属AZ，rep-dis-policy标识副本pt的分布策略，默认为0表示会尽量在节点间均匀分布，1表示会尽量在AZ间均匀分布，AZ间均衡分布是比节点间均匀分布更严格的分布策略。
端口规划与用途
占用端口的分布与用途 | 图源: https://zhuanlan.zhihu.com/p/582321361
| 组件 | 端口 | 说明 |
|---|---|---|
| ts-sql | 8086 | 端口可变更，openGemini对外提供服务的统一入口 |
| 6061 | 不可变更，若被其他程序占用，则pprof功能不可用 | |
| ts-meta | 8092 | 端口可变更，ts-meta与ts-sql、ts-store之间正常业务交互使用的端口 |
| 8091 | 端口可变更，ts-meta的运维接口 | |
| 8088 | 端口可变更，选举通信使用，三个ts-meta组成一个复制集，复制集之间通过raft协议进行选举 | |
| 8010 | 端口可变更，ts-store（新）加入集群时使用 | |
| ts-store | 8400 | 端口可变更，ts-sql通过该端口将数据写入ts-store |
| 8401 | 端口可变更，ts-sql通过该端口查询ts-store的数据 | |
| 8011 | 端口可变更，ts-meta监测ts-store心跳使用 | |
| 6060 | 不可变更，若被其他程序占用，则pprof功能不可用 |
伪集群中各组件的端口分布 | 图源: https://zhuanlan.zhihu.com/p/582321361
客户端
OpenGemini ts-cli
- 推荐文献
HTTP API(Curl/...)
- 设置curl请求的变量
# OPENGEMINI_HOST=192.168.101.102
# OPENGEMINI_USERNAME=admin
# OPENGEMINI_PASSWORD=xxxxxx
- 创建用户
curl -i -XPOST "http://$OPENGEMINI_HOST:8086/query" -k --insecure --data-urlencode "q=CREATE USER admin WITH PASSWORD 'xxxx' WITH ALL PRIVILEGES"
- 创建库
# curl -POST http://$OPENGEMINI_HOST:8086/query --data-urlencode "q=CREATE DATABASE bdp_test"
# curl -POST http://$OPENGEMINI_HOST:8086/query -u $OPENGEMINI_USERNAME:$OPENGEMINI_PASSWORD --data-urlencode "q=CREATE DATABASE bdp_test"
{"results":[{"statement_id":0}]}
- 查询数据库
# curl -POST http://$OPENGEMINI_HOST:8086/query -u $OPENGEMINI_USERNAME:$OPENGEMINI_PASSWORD --data-urlencode "db=bdp_test" --data-urlencode "q=show databases"
{"results":[{"statement_id":0,"series":[{"name":"databases","columns":["name"],"values":[["bdp_test2"]]}]}]}
- 删除库
# curl -POST http://$OPENGEMINI_HOST:8086/query -u $OPENGEMINI_USERNAME:$OPENGEMINI_PASSWORD --data-urlencode "q=DROP DATABASE bdp_test2"
{"results":[{"statement_id":0}]}
- 建表
# curl -POST http://$OPENGEMINI_HOST:8086/query -u $OPENGEMINI_USERNAME:$OPENGEMINI_PASSWORD --data-urlencode "db=bdp_test" --data-urlencode "q=create MEASUREMENT dwd_device_signal_ri_d"
{"results":[{"statement_id":0}]}
- 查表 on 指定库
# curl -POST http://$OPENGEMINI_HOST:8086/query -u $OPENGEMINI_USERNAME:$OPENGEMINI_PASSWORD --data-urlencode "db=bdp_test" --data-urlencode "q=SHOW MEASUREMENTS on bdp_test"
{"results":[{"statement_id":0,"series":[{"name":"measurements","columns":["name"],"values":[["dwd_device_signal_ri_d"]]}]}]}
- 删表
# curl -v -POST http://$OPENGEMINI_HOST:8086/query -u $OPENGEMINI_USERNAME:$OPENGEMINI_PASSWORD --data-urlencode "db=bdp_test" --data-urlencode "q=drop MEASUREMENT dwd_device_signal_ri_d"
{"results":[{"statement_id":0,"error":"measurement not found"}]}
# 注：表不存在时，删除失败
{"results":[{"statement_id":0}]}
# 注：表存在时，删除成功
- 新增数据
# curl -i -XPOST http://$OPENGEMINI_HOST:8086/write?db=bdp_test -u $OPENGEMINI_USERNAME:$OPENGEMINI_PASSWORD --data-binary 'dwd_device_signal_ri_d,host=device-001,region=us-west sg1=0.64,sg2=9.9,sg3=44 1735216290000000'
//插入1条 field 为: {"Name": "1#sg_xxx", "Type": "float"} 的 point
# curl -i -XPOST -u $OPENGEMINI_USERNAME:$OPENGEMINI_PASSWORD "http://$OPENGEMINI_HOST:8086/write?db=dwd&precision=ms" --data-binary 'dwd_xxx_device_signal_ri,deiceId=A001 1#sg_xxx=-1.1 1736701200000'
HTTP/1.1 204 No Content
Content-Type: application/json
Request-Id: cebb8e14-d1a4-11ef-8cd2-fa163e5ba0b7
X-Geminidb-Build: OSS
X-Geminidb-Version: v1.2.0
X-Request-Id: cebb8e14-d1a4-11ef-8cd2-fa163e5ba0b7
Date: Mon, 13 Jan 2025 11:52:04 GMT
- 上传文件数据集
- 创建文件 ： cpu_data.txt
cpu_load_short,host=server02 value=0.67
cpu_load_short,host=server02,region=us-west value=0.55 1422568543702900257
cpu_load_short,direction=in,host=server01,region=us-west value=2.0 1422568543702900257
- 上传文件
curl -i -XPOST http://$OPENGEMINI_HOST:8086/write?db=bdp_test --data-binary @cpu_data.txt
- 查询数据
# curl -POST http://$OPENGEMINI_HOST:8086/query -u $OPENGEMINI_USERNAME:$OPENGEMINI_PASSWORD --data-urlencode "db=bdp_test" --data-urlencode "q=select * from dwd_device_signal_ri_d"
{"results":[{"statement_id":0,"series":[{"name":"dwd_device_signal_ri_d","columns":["time","host","region","sg1","sg2","sg3"],"values":[["1970-01-21T02:00:16.29Z","device-001","us-west",0.64,9.9,44]]}]}]}
# curl -POST http://$OPENGEMINI_HOST:8086/query?db=bdp_test -u $OPENGEMINI_USERNAME:$OPENGEMINI_PASSWORD --data-urlencode "q=select * from bdp_test.autogen.dwd_device_signal_ri_d"
{"results":[{"statement_id":0,"series":[{"name":"dwd_device_signal_ri_d","columns":["time","host","region","sg1","sg2","sg3"],"values":[["1970-01-21T02:00:16.29Z","device-001","us-west",0.64,9.9,44]]}]}]}
Java for OpenGemini(JDBC)
<dependency>
<groupId>io.opengemini</groupId>
<artifactId>opengemini-client</artifactId>
<version>${latest.version}</version>
</dependency>
<!-- 引入influxdb依赖 -->
<dependency>
<groupId>org.influxdb</groupId>
<artifactId>influxdb-java</artifactId>
<version>2.22</version>
</dependency>
<dependency>
<groupId>com.influxdb</groupId>
<artifactId>influxdb-client-java</artifactId>
<version>6.3.0</version>
</dependency>
InfluxDBStudio(第三方开源)
Chronograf
Chronograf is an open-source web application written in Go and React.js that provides the tools to visualize your monitoring data and easily create alerting and automation rules.
3 Opengemini 静态结构(目录)及运行态(进程)
运行态/进程
- vmw-b
[root@vmw-b ~]# ps -ef | grep -i ts-
root 621 1 0 12月22 ? 00:00:01 /usr/libexec/accounts-daemon
root 1841 1 3 14:54 ? 00:00:02 bin/ts-meta --config=conf/ts-meta.toml
root 2521 1 0 14:54 ? 00:00:00 bin/ts-store --config=conf/ts-store.toml
root 2838 1 0 14:54 ? 00:00:00 bin/ts-sql --config=conf/ts-sql.toml
root 3661 1 0 14:55 ? 00:00:00 bin/ts-monitor --config=conf/ts-monitor.toml
root 8919 307 0 14:56 pts/2 00:00:00 grep --color=auto -i ts-
[root@vmw-b ~]# netstat -lntp | grep -i ts-
tcp 0 0 192.168.101.102:8011 0.0.0.0:* LISTEN 2521/bin/ts-store
tcp 0 0 192.168.101.102:6060 0.0.0.0:* LISTEN 2521/bin/ts-store
tcp 0 0 192.168.101.102:6061 0.0.0.0:* LISTEN 2838/bin/ts-sql
tcp 0 0 192.168.101.102:8400 0.0.0.0:* LISTEN 2521/bin/ts-store
tcp 0 0 192.168.101.102:8401 0.0.0.0:* LISTEN 2521/bin/ts-store
tcp 0 0 127.0.0.1:6066 0.0.0.0:* LISTEN 3661/bin/ts-monitor
tcp 0 0 192.168.101.102:8086 0.0.0.0:* LISTEN 2838/bin/ts-sql
tcp 0 0 192.168.101.102:8088 0.0.0.0:* LISTEN 1841/bin/ts-meta
tcp 0 0 192.168.101.102:8091 0.0.0.0:* LISTEN 1841/bin/ts-meta
tcp 0 0 192.168.101.102:8092 0.0.0.0:* LISTEN 1841/bin/ts-meta
tcp 0 0 192.168.101.102:8010 0.0.0.0:* LISTEN 1841/bin/ts-meta
[root@vmw-b ~]# pwdx 1841 2521 2838
1841: /usr/local/opengemini/gemini-deploy/ts-meta-8091
2521: /usr/local/opengemini/gemini-deploy/ts-store-8401
2838: /usr/local/opengemini/gemini-deploy/ts-sql-8086
- vmw-c
[root@vmw-c ~]# ps -ef | grep -i ts-
root 581 1 0 04:07 ? 00:00:01 /usr/libexec/accounts-daemon
root 939 76609 0 15:00 pts/1 00:00:00 grep --color=auto -i ts-
root 117790 1 1 14:54 ? 00:00:05 bin/ts-meta --config=conf/ts-meta.toml
root 117998 1 0 14:54 ? 00:00:02 bin/ts-store --config=conf/ts-store.toml
root 118234 1 0 14:54 ? 00:00:00 bin/ts-sql --config=conf/ts-sql.toml
root 118793 1 0 14:55 ? 00:00:01 bin/ts-monitor --config=conf/ts-monitor.toml
[root@vmw-c ~]# netstat -lntp | grep -i ts-
tcp 0 0 192.168.101.103:8400 0.0.0.0:* LISTEN 117998/bin/ts-store
tcp 0 0 192.168.101.103:8401 0.0.0.0:* LISTEN 117998/bin/ts-store
tcp 0 0 127.0.0.1:6066 0.0.0.0:* LISTEN 118793/bin/ts-monit
tcp 0 0 192.168.101.103:8086 0.0.0.0:* LISTEN 118234/bin/ts-sql
tcp 0 0 192.168.101.103:8088 0.0.0.0:* LISTEN 117790/bin/ts-meta
tcp 0 0 192.168.101.103:8091 0.0.0.0:* LISTEN 117790/bin/ts-meta
tcp 0 0 192.168.101.103:8092 0.0.0.0:* LISTEN 117790/bin/ts-meta
tcp 0 0 192.168.101.103:8010 0.0.0.0:* LISTEN 117790/bin/ts-meta
tcp 0 0 192.168.101.103:8011 0.0.0.0:* LISTEN 117998/bin/ts-store
tcp 0 0 192.168.101.103:6060 0.0.0.0:* LISTEN 117998/bin/ts-store
tcp 0 0 192.168.101.103:6061 0.0.0.0:* LISTEN 118234/bin/ts-sql
[root@vmw-c ~]# pwdx 117790 117998 118234 118793
117790: /usr/local/opengemini/gemini-deploy/ts-meta-8091
117998: /usr/local/opengemini/gemini-deploy/ts-store-8401
118234: /usr/local/opengemini/gemini-deploy/ts-sql-8086
118793: /usr/local/opengemini/gemini-deploy/ts-monitor
- vmw-d
[root@vmw-d ~]# ps -ef | grep -i ts-
root 652 1 0 12月21 ? 00:00:03 /usr/libexec/accounts-daemon
root 117865 1 1 14:54 ? 00:00:06 bin/ts-meta --config=conf/ts-meta.toml
root 118043 1 0 14:54 ? 00:00:03 bin/ts-store --config=conf/ts-store.toml
root 118167 1 0 14:54 ? 00:00:01 bin/ts-sql --config=conf/ts-sql.toml
root 118509 1 0 14:55 ? 00:00:01 bin/ts-monitor --config=conf/ts-monitor.toml
root 126943 130546 0 15:01 pts/1 00:00:00 grep --color=auto -i ts-
[root@vmw-d ~]# netstat -lntp | grep -i ts-
tcp 0 0 192.168.101.104:8010 0.0.0.0:* LISTEN 117865/bin/ts-meta
tcp 0 0 192.168.101.104:8011 0.0.0.0:* LISTEN 118043/bin/ts-store
tcp 0 0 192.168.101.104:6060 0.0.0.0:* LISTEN 118043/bin/ts-store
tcp 0 0 192.168.101.104:6061 0.0.0.0:* LISTEN 118167/bin/ts-sql
tcp 0 0 192.168.101.104:8400 0.0.0.0:* LISTEN 118043/bin/ts-store
tcp 0 0 192.168.101.104:8401 0.0.0.0:* LISTEN 118043/bin/ts-store
tcp 0 0 127.0.0.1:6066 0.0.0.0:* LISTEN 118509/bin/ts-monit
tcp 0 0 192.168.101.104:8086 0.0.0.0:* LISTEN 118167/bin/ts-sql
tcp 0 0 192.168.101.104:8088 0.0.0.0:* LISTEN 117865/bin/ts-meta
tcp 0 0 192.168.101.104:8091 0.0.0.0:* LISTEN 117865/bin/ts-meta
tcp 0 0 192.168.101.104:8092 0.0.0.0:* LISTEN 117865/bin/ts-meta
[root@vmw-d ~]# pwdx 117865 118043 118167 118509
117865: /usr/local/opengemini/gemini-deploy/ts-meta-8091
118043: /usr/local/opengemini/gemini-deploy/ts-store-8401
118167: /usr/local/opengemini/gemini-deploy/ts-sql-8086
118509: /usr/local/opengemini/gemini-deploy/ts-monitor
- vmw-e
[root@vmw-e ~]# ps -ef | grep -i ts-
root 582 1 0 12月21 ? 00:00:03 /usr/libexec/accounts-daemon
root 19858 1 0 14:54 ? 00:00:03 bin/ts-server --config=conf/ts-server.toml
root 20170 1 0 14:55 ? 00:00:00 bin/ts-monitor --config=conf/ts-monitor.toml
root 20564 20344 0 15:03 pts/1 00:00:00 grep --color=auto -i ts-
[root@vmw-e ~]# ps -ef | grep -i grafana
root 2528 1 0 19:48 ? 00:00:07 bin/grafana-7.5.17/bin/grafana-server --homepath=/usr/local/opengemini/gemini-deploy/grafana-3000/bin/grafana-7.5.17 --config=/usr/local/opengemini/gemini-deploy/grafana-3000/conf/grafana.ini
root 89035 88722 0 21:01 pts/2 00:00:00 grep --color=auto -i grafana
[root@vmw-e ~]# netstat -lntp | grep -i ts-
tcp 0 0 192.168.101.105:8186 0.0.0.0:* LISTEN 19858/bin/ts-server
tcp 0 0 192.168.101.105:8410 0.0.0.0:* LISTEN 19858/bin/ts-server
tcp 0 0 192.168.101.105:8411 0.0.0.0:* LISTEN 19858/bin/ts-server
tcp 0 0 192.168.101.105:8188 0.0.0.0:* LISTEN 19858/bin/ts-server
tcp 0 0 192.168.101.105:8191 0.0.0.0:* LISTEN 19858/bin/ts-server
tcp 0 0 192.168.101.105:8192 0.0.0.0:* LISTEN 19858/bin/ts-server
tcp 0 0 192.168.101.105:6060 0.0.0.0:* LISTEN 19858/bin/ts-server
tcp 0 0 192.168.101.105:6061 0.0.0.0:* LISTEN 19858/bin/ts-server
tcp 0 0 127.0.0.1:6066 0.0.0.0:* LISTEN 20170/bin/ts-monito
[root@vmw-e ~]# pwdx 19858 20170
19858: /usr/local/opengemini/gemini-deploy/ts-server-8186
20170: /usr/local/opengemini/gemini-deploy/ts-monitor
[root@vmw-e ~]# pwdx 2528
2528: /usr/local/opengemini/gemini-deploy/grafana-3000
静态结构(目录结构)
注：默认仅展示目标目录的前3层
[vmw-b] /root/.gemix
cluster-info
download
logs
gemix-cluster-debug-2024-12-19-15-11-04.log
...
gemix-cluster-debug-2024-12-20-21-21-29.log
...
gemix-cluster-debug-2024-12-23-10-25-44.log
gemix-cluster-debug-2024-12-23-14-35-18.log
gemix-cluster-debug-2024-12-23-14-38-12.log
storage
cluster
clusters
gemini-test
packages
checksums.txt
grafana-7.5.17.linux-amd64.tar.gz
grafana-7.5.17.linux-amd64.tar.gz.bak
grafana-enterprise-7.5.17.linux-amd64.tar.gz
openGemini-1.2.0-linux-amd64.tar.gz
openGemini-1.2.0-linux-amd64.tar.gz.bak
8 dictories,36 files
[vmw-b] /opt/go-projects/
opengemini/
bin/
gemix/
pkg/
mod/
cache
github.com
golang.org
gopkg.in
go.uber.org
sumdb/
sum.golang.org
[vmw-b] /usr/local/opengemini/
gemini-deploy/
ts-meta-8091/
bin/
ts-meta
conf/
ts-meta.toml
scripts/
run_ts-meta.sh
ts-monitor/
bin/
monitor.lock
ts-monitor
conf/
ts-monitor.toml
scripts/
run_ts-monitor.sh
ts-sql-8086/
bin/
ts-sql
conf/
ts-sql.toml
scripts/
run_ts-sql.sh
ts-store-8401/
bin/
ts-store
conf/
ts-store.toml
scripts/
run_ts-store.sh
gemini-log/
logs/
ts-meta-8091/
gossip.log
meta_extra.log
meta.log
metric
raft.log
ts-monitor/
monitor.error.log
monitor_extra.log
monitor.log
ts-sql-8086/
metric
sql_extra.log
sql.log
ts-store-8401/
gossip.log
metric
store_extra.log
store.log
gemix-cluster-install.log
[vmw-b] /data/gemini-data/
data
meta
raft.db
snapshots/
[vmw-e] /root/test
[root@vmw-e ~]# ll /root/test/usr/bin
总用量 30416
-rwx------. 1 root root 31142400 12月 20 19:36 ts-cli
[root@vmw-e ~]# ll /root/test/usr/bin/ts-cli
-rwx------. 1 root root 31142400 12月 20 19:36 /root/test/usr/bin/ts-cli
注：
ts-cli脚本
ln -s /root/test/usr/bin/ts-cli /usr/local/bin/ts-cli
# 帮助手册
ts-cli -h
ts-cli -host 192.168.101.102 -port 8086
[root@vmw-e ~]# ll /root/test/etc/
总用量 24
-rw-r--r--. 1 1001 docker 1704 2月 29 2024 monitor.conf
-rw-r--r--. 1 1001 docker 11087 2月 29 2024 openGemini.conf
-rw-r--r--. 1 1001 docker 1692 2月 29 2024 openGemini.singlenode.conf
-rw-r--r--. 1 1001 docker 3680 2月 29 2024 weakpasswd.properties
[vmw-e] /usr/local/opengemini/
gemini-deploy
grafana-3000
bin
grafana-7.5.17
conf
grafana.ini
dashboards
error_logs.json
inspection.json
overview.json
performance_read.json
performance_write.json
process_restarted.json
data
grafana.db
png
log
grafana.log
plugins
provisioning
dashboards
datasources
scripts
run_grafana.sh
ts-monitor
bin
monitor.lock
ts-monitor
conf
ts-monitor.toml
scripts
run_ts-monitor.sh
ts-server-8186
bin
ts-server
conf
ts-server.toml
data
meta
scripts
run_ts-server.sh
gemini-log
logs
ts-monitor
monitor.error.log
monitor_extra.log
monitor.log
ts-server-8186
raft.log
server_extra.log
single.error.log
single.log
Z FAQ for OpenGemini
Q：时序数据库是否支持与批处理系统的集成？？
- 可以与批处理系统集成，比如AI模型训练、报表生成、Spark/Flink数据分析等。
目前支持Spark和Flink，其他的比如AI分析框架或者报表工具暂时不能直接支持，需要开发对应的Connector或者基于SDK开发功能模块
Q：openGemini是否自动支持特定时间间隔的汇总？
- 支持，如果仅仅对某个时间范围内的数据（目标数据量不是很大）按特定时间间隔汇总，可以直接使用
select语句或者select into语句。 - 如果目标数据量太大，建议使用openGemini将要推出的
continue query(连续查询)功能；如果不需要保留历史数据明细，可以使用openGemini提供的多级降采样功能。
Q：如何优化时序数据库的存储和查询，以提高数据的处理效率？
-
- 如果可以接受部分数据丢失，可以设置不写
WAL;
- 如果可以接受部分数据丢失，可以设置不写
-
- 尽可能批量写;
-
- 增加
openGemini的缓存占比;
- 增加
-
Tag名字尽量简短；可以指定分区键，减少网络扇出度。
Q：openGemini对于CPU 资源有哪些要求？
- 部署节点的CPU至少4核起步
Q: 如何在应用程序中使用openGemini时序数据库进行事务处理和并发控制？
- openGemini不支持事务，数据一旦成功写入便不能回滚
Q: OpenGemini的应用开发流程是怎样的，下载sdk、配置文件、创建连接、创建表？比如，开发者如何利用openGemini进行数据的读写操作。
- openGemini的开发流程是：
- 下载openGemini二进制或者源码编译，修改配置文件并启动openGemini单机或者集群节点、创建库和表、下载SDK、基于SDK开发读写数据功能模块进行数据读写。
- 各语言的SDK下载地址可以参考社区主目录下README中给出的链接。
- 每种语言的SDK项目中都提供了DEMO
Q：企业如何建设时序数据库基准测试和标准？
- 基准测试有3个要素：数据、负载和度量体系。
简单来说，做时序数据库基准测试和标准，需要考虑测试的数据模型是什么样，测试模型和负载如何设计，设计哪些性能度量指标。
企业要做这方面的基准测试，需要注意标准的公正、公平和客观性，避免出现基准之争。
建议和开源社区以及典型企业共同来做，这是一件非常有意义的事情。openGemini表示支持。
Q：openGemini是否有详细的文档和教程或者案例？比如，是否有官方文档和教程以帮助开发者快速上手和解决问题。
- openGemini有快速上手的文档，参见： https://docs.opengemini.org/zh/guide/quick_start/get_started.html
目前还欠缺的内容包括内置函数和新特性的功能、示例介绍。
暂时可以先参考InfluxDB的文档： https://docs.influxdata.com/influxdb/v1.8/ ，所有算子用法是兼容的。
- openGemini自身运维监控参考：
Q：openGemini时序数据库是否支持数据可视化和报表生成？支持接入Grafana
- openGemini支持Grafana进行数据可视化展示，但不能生成表表，需要有额外的开发工作。
Q：openGemini是否支持多种操作系统和平台？比如，可以在docker、x86,鸿蒙、麒麟、Linux、Windows等不同操作系统上运行。
- 支持docker、K8s、KubeEdge、x86、ARM64、Linux（openEuler、Ubuntu、Centos、Redhat等），windows将于下个版本支持。
暂时还没有适配国产的其他操作系统，比如麒麟、鸿蒙。
Q：openGemini是否支持多种存储介质和存储引擎？
- 目前支持两种存储引擎（默认存储引擎和高基数存储引擎），openGemini采用
Go语言开发，操作系统和Go语言标准库屏蔽了底层存储介质，不管是SSD和HDD，对openGemini来说是无感知的。
Q：openGemini时序数据库能否用于数据仓库和数据湖的集成？
- 可以用于集成，主要存储时序类型的指标、日志等数据。
但目前没有开发集成工具来实现。
Q：写入数据页时发送断电数据文件和数据页是否会导致数据损坏？
- openGemini写数据时，会先写
WAL文件，再写缓存，缓存满了再刷磁盘文件存储。
如果数据在写WAL文件时断电，数据写失败，这部分数据会丢失，写
WAL成功后，再断电，数据不会丢失，通过WAL回放会重新找回数据。
Q：openGemini 时序数据库处理和分析结构化、非结构化和半结构化数据的方式有哪些不同？
- 结构化数据支持友好，半结构化数据需要进行数据各式转换后才能存储在openGemini中，比如XML、JSON, 或者把整个XML或者JSON内容按照string类型存储也可以，暂不支持对非结构化数据的处理。
具体使用场景，可以联系 OpenGemini 布道师-向宇 进行交流，这方面需求如果很普遍，社区可以考虑新增支持半结构化数据的数据类型。
Q：openGemini如何保证实时数据服务。提供数据的实时值的查询、修改？
- openGemini 并不是严格的实时系统，所有设备（时间线）的数据，写第一条数据时，由于要创建倒排索引，需要在写入成功后等待1s后查到，随后的数据可以即写即查。
没有单独的更命令，如果需要更新，可以重写，确保时间与待修改数据的时间保持一致
Q：openGemini时序数据库在华为云SRE中如何进行进行故障排除和性能调试？
- 使用openGemini自身提供的监控手段，在SRE中为openGemini集群搭建了监控面板，监控指标包括磁盘存储空间、CPU和内存利用率，写入带宽、查询时延、查询QPS、WAL时延等等，根据指标面板分析发现潜在问题，再进行问题排查。
举个例子，某一次SRE给openGemini做版本升级后，通过面板发现写入性能存在明显的毛刺。如下是排除和解决的过程：
- 求证业务是否平稳，是否因为业务流量原因导致，询问后排除。
- 查看内核其他指标面板是否正常，发现写memtable时延波动明显，写WAL以及流控令牌获取均有不等的毛刺，推测是GC导致。
- 求证，使用pprof抓取火焰图，重点分析火焰图上颜色较深的部分，通过内存池化或者减少这部分函数内的变量数量和内存申请次数进行优化，优化后再一次抓取火焰图，发现有明显的改善，毛刺消失了。
Q：openGemini数据容量取决于服务器存储的容量吗？在大容量下是否能保持较高的数据读取性能？
- openGemini中，数据按时间范围进行分区，理论上没有数据容量上限，取决于服务器存储的容量大小，openGemini的数据读取性能取决于目标数据量规模，规模越大，读取数据的时间相对更长，比如历史数据有1PB，但是每次查询1天内的数据，性能同样是很高效的。
Q：openGemini适用于哪些具体的场景？比如，适用于物联网、金融行业或其他需要处理大量时序数据的场景。
- 适用于物联网、车联网、运维监控、电力、能源、制造业、物流、智能建筑、金融等存在大量遥测数据存储和分析的场景
Q：openGemini时序数据库如何优化数据插入和存储问题？
- 数据插入优化建议：
- 尽量采用批量写入，减少网络交互次数
- 集群模式下，数据写入压力尽量分散到不同的
ts-sql上- 如果内存资源充足，可以开启Hot模式（对应配置文件：shard-tier= hot）
- 如果内存资源充足，可以适当调大缓存的占比，默认 10%（imm-table-max-memory-percentage）
Q：openGemini兼容现有哪些时序数据库工具链？
- 数据可视化工具：Grafana、Chronograf等
- 大数据分析工具：Flink、Spark等
- SDK驱动：兼容已有的C/C++, Java, Python, Javascript, Rust, Go等SDK
- 其他：支持InfluxDB的带界面的客户端
Q：openGemini支持信创操作系统吗？目前在行业内成熟的应用或者解决方案有哪些？
- 信创的操作系统中仅支持openEuler。目前openGemini整理的行业内成熟的解决方案有：
- 基于openGemini + EMQ + Kuiper + grafana的物联网数据可视化解决方案
- openGemini + ngix的集群负载均衡解决方案
- openGemini作为prometheus后端存储的解决方案
- openGemini + KubeEdge的边缘计算解决方案
- 等等，还有更多待挖掘
Q：如何评估和比较不同时序数据库的性能和功能？主要依据哪些项目测试和指标？
- 性能和功能评估这块，先说性能：
- 需要了解自己的业务，比如需要存储什么数据，有哪些字段，1分钟或者1秒钟需要写入的数据量大约是多大，单条数据长度，并发量多大，未来预期增长水平，能接受的最大查询时延，自己能提供的机器规格是多大，购买硬件设备的预算是多少等等。
- 依据上述类容，使用现有的测试工具（比如TSBS）进行多种数据库进行性能对比，同时还要自己写一些测试程序来完成和业务相关的性能和功能测试，包括稳定性
- 测试指标通常是写入平均速度、查询平均时延两大类，部分业务可能关注查询的P95、P99性能数据。
- 功能方面：了解自己业务痛点和现有的查询语句，对比其他时序数据库提供的能力。
Q：openGemini 单机和分布式的语法都是一样的吗？openGemini能否根据硬件情况自动调优
- 单机和集群的语法是一样的。
openGemini还不能根据硬件情况自动调整参数优化，这需要大量的应用案例学习。
而且这件事情很复杂，仅仅根据硬件情况只能优化一小分部参数，比如缓存、并发数量等。
硬件上运行的应用有可能读多写少，有可能写多读少，也有可能读写差不多，有可能时间线很少，但数据量很大，也有可能时间线很多，单条时间线数据量很少，这些情况有需要重新调整缓存和并发，以及其他参数。这也是一个值得研究的问题。
Q：新手小白如何参与openGemini开源项目贡献？
-
openGemini的贡献可分为代码和非代码贡献。
-
非代码贡献包括文档以及翻译、活动策划、社区运营、社区大使、技术文章分享、源码分享等。
-
代码贡献包括内核功能特性开发、Bug修复、测试用例编写、周边工具开发、生态集成工具开发等。
-
至于如何参与项目贡献，可以先联系社区，告知你的擅长领域和方向，根据你的情况，社区会提供相关的开发、运营、文档编写等方面的指导。
目前社区有很多事情可以做，但还没有全部都以
issue的方式发布出来。新手小白，可以从贡献文档、修复简单Bug、简单的小功能做起，也可以参与到社区运营、活动策划中。
Y 推荐文献
- opengemini
X 参考文献
- 华为云
- OpenGemini
git clone https://github.com/openGemini/openGemini.git
cd openGemini
python3 build.py --clean单机版的构建结果：
> ls build
> ts-cli ts-meta ts-monitor ts-server ts-sql ts-store
ts-server 是独立运行版
本文链接： https://www.cnblogs.com/johnnyzen
关于博文：评论和私信会在第一时间回复，或直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
日常交流：大数据与软件开发-QQ交流群: 774386015 【入群二维码】参见左下角。您的支持、鼓励是博主技术写作的重要动力！
浙公网安备 33010602011771号