【DTSE Tech Talk 精选问答】NO.48丨openGemini全新列存引擎,为您解决时序数据高基数难题
【摘要】 在数据库中,基数是指一列数据中唯一值的个数,高基数即表示该列中唯一值的数量非常大,常见的比如IP地址、电子邮件等。高基数问题长期困扰着众多时序数据库产品,主要表现为索引膨胀,内存资源消耗增加,读写性能下降等,openGemini 全新列存引擎,旨为解决高基数问题,性能表现出色。
在数据库中,基数是指一列数据中唯一值的个数,高基数即表示该列中唯一值的数量非常大,常见的比如IP地址、电子邮件等。高基数问题长期困扰着众多时序数据库产品,主要表现为索引膨胀,内存资源消耗增加,读写性能下降等,openGemini 全新列存引擎,旨为解决高基数问题,性能表现出色。
直播链接:https://bbs.huaweicloud.cn/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.htmlQ:在处理海量遥测数据时,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 系列技术直播
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论(0)