【DTSE Tech Talk 精选问答】NO.48丨openGemini全新列存引擎，为您解决时序数据高基数难题

在数据库中，基数是指一列数据中唯一值的个数，高基数即表示该列中唯一值的数量非常大，常见的比如IP地址、电子邮件等。高基数问题长期困扰着众多时序数据库产品，主要表现为索引膨胀，内存资源消耗增加，读写性能下降等，openGemini 全新列存引擎，旨为解决高基数问题，性能表现出色。
直播链接：https://bbs.huaweicloud.com/live/DTT_live/202311151630.html

Q：openGemini的Arrow Flight是什么？

A:Arrow Flight 是一种支持列存格式的数据传输RPC框架，使用该框架，在不同系统间应用该框架，可以减少数据转换、拷贝的开销。

Q：openGemini的Compaction是什么？

A:Compaction 是 LSM-Tree 结构用于后台合并文件的一个操作，可以将小文件合并成大文件，获得更大范围的数据有序性。

Q：openGemini的OTEL是什么？

A:OTEL 即 open Telemetry，是一种可观测数据的采集标准，支持包括日志、指标、索引等在内的数据采集、数据传输协议等。

Q：openGemini的查询优化引擎是什么？

A:查询优化是指对业务下发的查询需求进行解析之后，根据查询涉及的数据、索引、过滤等条件的分析，生成最佳查询计划的过程。

Q：openGemini的分布式是什么？

A:openGemini 提供了分布式集群能力，支持动态扩容或者索引。

Q：openGemini的列式布局（以键排列）是什么？

A:列式布局，指的时数据在存储时，按列进行存储，同一列数据存储到一起，在存储前，会按照排序键进行排序，使得相关的数据存储到一起。

Q：openGemini的数据分区是什么？

A:openGemini 目前数据分区按照时间范围、时间线/分区键做两级分区。

Q：openGemini的索引和查询优化是如何工作的？

A:openGemini 的索引与数据排序方法相关，时序引擎构建了倒排索引，列存引擎构建了稀疏索引，查询优化提供 RBO、CBO 两种优化方式。

Q：openGemini的统一化执行引擎是什么？

A:统一化查询引擎是指构建于时序引擎、列存引擎之上的查询引擎，提供对外查询的统一入口。

Q：openGemini多表引擎如何做数据隔离的？

A:openGemini底层数据存储按表隔离，存储引擎是表级的，因此不同表的数据也会分布在不同的目录中。

Q：openGemini高基数引擎相对于业界时序引擎或OLAP分析引擎有哪些优势？ 从设计上来说，在时序数据领域，openGemini高基数引擎是不是没有时间线约束了？新增了哪些约束呢？ openGemini高基数引擎面向的应用领域有哪些呢？

A:高基数引擎相比时序引擎去除了时间线的约束，相比 OLAP 系统对时序场景提供了特定的优化；在时序场景下，高基数引擎目前没有时间线约束，但需要用户指定合适的排序键与索引，才能获得更好的查询性能；高基数引擎可更好解决如网流业务监控这类高基数场景。

Q：openGemini高基维引擎支持多存储介质吗？比如说EVS，HDFS，OBS？

A:支持。

Q：openGemini列存引擎的设计思路是什么？有哪些特点？

A:核心思路是改变现有时序引擎的数据排序方式与索引方式，去掉时间线的影响，更适用于高基数场景。

Q：openGemini列存引擎的最佳实践是什么？有哪些使用技巧？

A:列存引擎在使用时，需要结合业务特点，包括数据分布、查询范式等选择合适的排序键、索引等，通常可以考虑将常用的查询列、低基列等作为排序键、构建索引，其他高基列可以等待后续社区发布新的索引特性。

Q：openGemini列存引擎如何处理大量唯一值的存储和检索?

A:通过 mergeset 进行唯一值存储。

Q：openGemini列存引擎是否支持并行查询和并行计算？

A:支持。

Q：openGemini列存引擎是如何解决高基数问题的，它的设计理念是什么，有哪些特点和优势？

A:基本的设计理念是底层数据的存储、索引等不再依赖于基数。

Q：openGemini列存引擎是如何解决高基数问题的？

A:引入新的数据布局与索引，使得数据存储、索引构建过程都不依赖与基数。

Q：openGemini列存引擎与传统解决方案在性能上的对比是怎样的？在不同场景下的效果评估如何？

A:列存引擎与传统解决方案相比，在高基数场景下有大幅性能提升。

Q：openGemini列存引擎与时序引擎查询有什么区别吗？

A:核心差异在于数据排序与索引不同。

Q：openGemini列存引擎在高并发读写场景下的表现如何？

A:性能相比其他产品有较大幅度提升。

Q：openGemini列存引擎在解决索引膨胀问题上有何创新？

A:引入新的数据布局与索引。

Q：openGemini如何保证数据的一致性和完整性？

A:openGemini 通过 WAL、数据副本等保证数据的一致性、完整性。

Q：openGemini如何优化存储空间的使用和管理，以减少存储成本和提高性能？

A:针对不同的数据类型提供了针对性的压缩方法。

Q：openGemini如何优化读写性能？

A:通过不同的存储引擎、查询优化、MPP架构等优化不同场景的读写性能，具体细节可关注官方文档。

Q：openGemini如何支持搭建运维监控平台或系统？

A:openGemini 可以作为运维监控平台或者系统的数据存储底座。

Q：openGemini如何支持大规模数据的存储和查询？

A:openGemini 通过数据压缩、不同的数据排序、索引方法，以及 MPP 架构来应对大规模数据的存储和查询。

Q：openGemini如何支持多种云服务和部署环境？

A:目前部署工具还在开发中，可以关注openGemini公众号，关注社区进展。

Q：openGemini如何支持构建物联网、车联网、工业物联网平台？

A:openGemini 可以作为物联网、车联网、工业物联网平台的数据存储底座。

Q：openGemini在构建商业版本时有哪些特殊的需求或考虑？

A:openGemini 是一款开源数据库，外部开发者可以基于社区版本构建不同的商业发行版，解决商业痛点。

Q：openGemini支持哪些索引？

A:目前支持倒排索引，文本索引，稀疏索引等。

Q：openGemini中count.txt文件有什么作用？

A:count 预聚合，用于快速响应 count 聚合查询。

Q：Pandas、Drill、Impala、Parquet、Cassandra、Kudu和HBase这些工具或系统与Arrow Flight有什么关系？

A:这些系统都可以采用列存格式处理数据，可以利用 Arrow Flight 去除系统间数据传输时的解析与转换开销。

Q：PRIMARYKEY和SORTKEY的作用是什么？

A:用于定义主键索引、排序键。

Q：Sort和Merge之间是什么关系？

A:sort 对数据进行排序， Merge 对数据进行整合。

Q：备份恢复功能在openGemini中如何实现？

A:目前备份恢复功能还在开发中，可以关注openGemini公众号、社区动态进展。

Q：查询计划构建在适配列存引擎时面临哪些挑战？

A:主要挑战在于如何有效发挥不同存储引擎的能力。

Q：除了Cache和MergeSet等技术，还有哪些方法可以提高查询效率？

A:提升查询效率有很多不同的方法，包括调整存储数据布局、索引、查询并发、弹性扩容、优化查询计划等等，具体需要具体场景，识别关键瓶颈，再进行优化。

Q：导入导出功能在openGemini中如何实现？

A:目前导入导出功能还在开发中，可以关注openGemini公众号、社区动态进展。

Q：对比时序引擎，openGemini高基数引擎有哪些关键技术？

A:引入新的数据布局与索引。

Q：多副本功能在openGemini中如何实现？

A:目前多副本功能在还在开发中，可以关注openGemini公众号、社区动态进展。

Q：分组聚合这块儿，一般分组越多，查询越慢，想了解下高基数引擎在这方面是如何处理的？

A:对于精确查询，可以通过更大的并发提升查询效率，同时 openGemini 也在进行近似查询的开发，可以关注openGemini公众号、社区动态进展。

Q：高基数问题的具体表现和影响有哪些？

A:使用时序引擎时，高基数可能导致内存使用增加，读写性能下降。

Q：后台compaction采用何种策略？

A:后台 compaction 策略影响的是数据整体的有序性，因此需要考虑实际业务场景考虑不同的 compaction 策略。

Q：哪些应用场景适合使用open Gemini,哪些情况下不适合?

A:openGemini 适合于运维监控、物联网等海量邀测数据的存储与分析场景。

Q：哪些原因会导致索引膨胀？

A:高基数可能导致时序引擎的倒排索引膨胀。

Q：您好，我要部署openGemini的集群进行测试，我应该如何规划我的集群，如几台服务器,CPU核数，内存大小，硬盘大小，等相关信息我应该如何去设置或者购买，有指导案例吗？比如什么场景下的内存需要配置的高一些，最小配置是多少？

A:部署openGemini，规划集群时，主要考虑三个因素： 1. 时间线规模（不是点位），比如 region=“shanghai”，service=“mysql” cpu=0.4，mem=0.6，这是一条时间线，带两个点位数据。时间线规模对应节点规格参考：https://docs.opengemini.org/zh/guide/reference/specification.html 2. 大致确定了规格之后，接下来要确定集群需要几台服务器，openGemini集群推荐最小规模是3个节点，部署ts-meta(3x),ts-sql(1-3x),ts-store(2-3)。具体组件数量，需要根据业务负载来看。最终选择几台服务器，要结合写入和查询来看，目前单节点（32U128G）可以30万时间线，一条数据包含10个标签和10个点位数据这种数据模型，写入性能是近40万条/秒，换算成点位是400万点位/s，如果业务数据负载是1000万点位/s，可以简单计算 3*400*0.8 = 960万点位/s，也就差不多3-4台服务器即可满足。 3. 再看查询场景，如果有分组聚合查询的场景，且分组数量偏大，比如一次查询产生几十万甚至上百万个分组，那么建议cpu和内存规格要大一点。 什么场景下内存需要配置高一些？ 我的建议是 a. 复杂查询比较多的场景，比如分组聚合，大量分组数据都将缓存在内存做计算（ts-store的内存要大一些）。 b. 要做降采样，包括流式降采样，以及历史数据降采样（流式降采样，ts-sql内存大一些） c. 要使用数据订阅功能（ts-sql内存要求大一些） d. ts-meta主要用于元数据管理，一般4U8G基本够用。

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

A:在数据插入方面，openGemini 兼容了 Arrow Flight，可以去除数据解析、拷贝开销，大幅提升插入性能。 在数据查询方面，openGemini 在底层数据布局与索引都针对监控场景的典型查询做了优化，上层的查询引擎也基于 MPP 架构构建了分布式计算能力，同时也提供了 RBO、CBO 等不同的查询优化器。

Q：请问是否可以使用openGemini时序数据库进行模型训练和优化？

A:openGemini 可以用于时序数据模型训练和优化的数据源；openGemini 也内置了部分时序分析算法，具体可查看 openGemini-castor 项目：https://github.com/openGemini/openGemini-castor。

Q：如果我一开始使用的是openGemini默认的存储引擎，想换为高基数引擎，怎么办？

A:由于底层数据排序方式、索引不同，不支持从默认的时序引擎直接升级到高基数引擎。

Q：如何创建测量（Measurement）并指定引擎类型为ColumnStore？

A:通过 enginetype = columnstore 进行指定。

Q：如何基于openGemini构建商业版本？

A:可以在社区版本的基础上，根据不同的商业需求，如数据隐私保护、运维增强等进行相关特性开发。

Q：什么是数据有序性，openGemini如何提升数据有序性？

A:数据有序性是指数据按照特定的顺序进行排序，在 openGemini 的时序引擎中，数据按照时间线进行聚簇后，再按照时间排序，在列存引擎中，数据按照预定义的排序键进行排序。

Q：什么是相对有限的时间线数量？

A:如单节点数据的时间线上限为 1000 万。

Q：时间线聚簇存储的优势是什么？

A:时间线聚簇存储的优势是将相同时间线的数据存储到一起，结合倒排索引，可以同时提供面向点查、聚合查询的极致性能。

Q：使用Arrow Flight进行数据传输的效率如何？

A:使用 Arrow Flight 可以去除数据解析、转换开销。

Q：数据查询以聚合查询为主，通常指定了时间范围音询响应速度要求高，openGemini如何满足这种需求？

A:

Q：时序引擎、列存引擎的数据布局与索引都考虑了聚合查询的需求，使得聚合查询的效率更高。

A:

Q：为什么构建索引的开销不会随时间线的增加而增加？

A:列存引擎构建过程中，没有资源依赖于时间线的数量。

Q：为什么使用LSM结构可以增强数据有序性并提升查询性能？

A:LSM 结构会在后台对小文件进行合并，使得数据在更大范围内有序。

Q：新的引擎支持数十万分组的查询吗？有什么最佳实践吗？

A:支持。需要选择合适的排序键，使得分组的数据聚簇存储。

Q：业务特点数据都是插入，几乎没有更新和删除近期数据关注度高，如何处理这种情况？

A:监控领域基本上都是这种场景，目前 openGemini 通过时间、分区键两级分区，分级存储等技术来处理这一问题。

Q：在openGemini中，如何配置和使用Arrow Flight？

A:具体使用可参考官方文档：https://docs.opengemini.org/zh/guide/features/high_series_cardinality.html

Q：在处理海量遥测数据时，openGemini如何保证数据的安全性和隐私保护？

A:目前提供鉴权保证访问安全，更多保护措施可以关注openGemini公众号，关注社区进展。

Q：在创表语句中，SHARDKEY和TYPE HASH| RANGE分别表示什么含义？

A:用于定义 shard key，以及 shard 打散方式。

Q：在分布式环境中，如何实现高效的氏基数列唯一值高效查询？

A:存储时直接存储唯一值。

Q：在高基数场景下，现有方式是如何解决索引膨胀、内存资源消耗增加、读写性能下降等问题？openGemini列存引擎又是如何解决这些问题的？openGemini列存引擎相比现有方式，有什么新的特点？

A:时序引擎的存储方式是按照时间线聚簇数据，再构建倒排索引，因此在高基数场景下，会导致内存开销增加，读写性能下降，新增的列存引擎在底层数据存储、索引构造时都不依赖于时间线或者是某一列的基数，因此不会有内存膨胀、读写性能下降的问题，列存引擎与时序引擎的核心差异在于数据排序方式、索引方式不同。

Q：在哪些场景下，使用Arrow Flight比其他解决方案更优？

A:使用列存引擎时，可以考虑使用 Arrow Flight 去除数据解析与转换开销。

Q：在实际应用中，如何使用OpenGemini列存引擎来优化数据库性能？可以列举一些最佳实践和使用案例。

A:列存引擎在使用时，需要结合业务特点，包括数据分布、查询范式等选择合适的排序键、索引等，通常可以考虑将常用的查询列、低基列等作为排序键、构建索引，具体的案例可以关注社区公众号，关注社区文档更新

Q：在使用openGemini列存引擎时，如何提高数据的导入速度？

A:可以通过 Arrow Flight 。

Q：在使用列式存储、排序键和聚簇索引的方案时，如何支持大规模数据的存储和查询？

A:结合 LSM-Tree 结构，支持数据的快速导入，同时再后台对数据进行合并，保证数据的整体有序，进而支持高效查询。

Q：在相对有限的时间线数量下，openGemini如何提供极致的写入与查询性能？

A:在这种情况下，可以使用时序引擎，通过时间线聚簇、时间排序、倒排索引，可以同时提供面向点查、聚合查询的极致性能。

Q：“HashAggTransfon”、“lumnStoreReade”、“HashAggTransform”和“olumnStoreRead”这几个术语是什么意思？

A:这几个术语都是指查询过程中的某一个数据处理环节，包括数据扫描、聚合计算等。

Q：“RPCSenderTransform”在查询计划中有什么作用？

A:用于传输数据。

Q：“StoreNode2”和“RPCReaderTransform”在数据存储和读取方面的作用是什么？

A:StoreNode2 指的是服务器节点，RPCReaderTransform 是指查询过程中的一个流程。

Q：“通过Arrow格式，不同系统间不再需要数据转换”的具体含义是什么？

A:不同系统之间如果都采用 Arrow 数据格式，那么进行数据传输时，就不需要数据解析与转换。

Q：Arrow Flight如何支持实时数据处理？Arrow Flight支持哪些类型的数据接口?

A:使用 Arrow Flight 需要用户在客户端，将数据组装成列存的 Arrow 格式。Arrow Flight包括整形、浮点型、字符串、bool 类型等，具体可关注 Arrow Flight 官方文档。

Q：flight-address的格式是什么？

A:ip地址+端口。

Q：flight-ch-factor是什么，如何使用它？

A:flight-ch-factor 是 arrow-flight 并发写 channel 的缓存数，可以根据服务端规格进行合理的设置。

Q：flight-enabled和flight-auth-enabled分别表示什么含义？

A:flight-enabled 表示是否开启 flight 端口，支持 flight 格式的数据写入，flight-auth-enabled 表示是否开启 flight 协议的鉴权。

Q：Gemix工具的主要功能是什么？

A:用于 openGemini 的自动化部署与升级。

Q：LSM结构如何用于后台数据整理？

A:通过 compaction 进行数据合并。

Q：MergeSet的主要功能是什么？

A:MergeSet的主要功能是 kv 存储，支持数据排序、合并、去除等。

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