UGeek大咖说 | 直播回顾:可观测之超融合存储系统的应用与设计

UGeek大咖说 | 直播回顾:可观测之超融合存储系统的应用与设计

上周,UGeek大咖说第六期

「可观测之超融合存储系统的应用与设计」

专题分享活动完美落幕

此次直播由优维研发总监陈安礼Linus主讲

分享了优维对可观测的看法与实践

此次活动细数了可观测平台面临的高频问题,也针对性地提供了一些常规的解决方案,而优维首创性地提出了超融合存储系统的解决方案,重点介绍了融合存储系统在化解可观测平台难点问题上的创新技术。

那么,和优维亦菲一起回顾本场活动的精彩内容吧!

1

可观测平台需要解决的问题

| 需求场景

· 按用户实时查看高负载业务列表(高负载:近10分钟cpu使用率>80%)

· 按业务和所属机房查看主机实时网络流量

· CMDB拓扑中展示指定的实时监控指标、属性等信息

| 需求分析

· 用户、业务、主机、机房等信息存储在CMDB

· 监控指标存储在监控系统

· 需要将两边的数据查询整合

| 常规解决方案

· 先查CMDB,再查监控数据,然后过滤整合?

· 先查监控数据,再查CMDB,然后过滤整合?

· 将需要的CMDB信息作为Tag存到监控数据库?

· 将监控数据直接存储到CMDB?

2

优维解决方案-融合存储

| 优维的解决方案——融合存储。

UGeek大咖说 | 直播回顾:可观测之超融合存储系统的应用与设计

① 优维CMDB的实例数据。需要用户自定义属性,所以它适合文档类的,因为文档类可以灵活修改数据。

② 优维的关系数据。业务主机用户、机房、这些集群之间的关系其实是一个图的关系,多个实例之间可以建立多个多种关系。

③ 优维的监控指标数据,时间是完全相关的,所以是一个时序数据。把这三类数据融合起来,全放到一起统一查询,去实现这几个数据的融合。

UGeek大咖说 | 直播回顾:可观测之超融合存储系统的应用与设计

详细的解决步骤与建模过程,请观看直播回放哦

3

超融合数据库easy_core

· 同时支持文档、图、时序数据存储

· 做到了OLTP和OLAP的有机结合

· 强一致、高可用、自动容灾

· 容量可平行扩展

通过上述方案,优维在上层业务层有了更加丰富、广阔的空间和想象力去做各种上层的业务功能。还做到了OLTP和OLAP的一个有机结合,即TPT的数据和OAP的数据,通过我们的智能查询引擎。直接就结合起来。另外,通过高可用方案,做到了数据强一致,若某个节点坏了,可以自动做一个主层切换和数据的切换。

也做到了一个数据数据的可平行扩展,某个节点负载高了,直接把对应的数据分散出去即可。

4

融合存储的优势

| 产品功能

· 属性、关系、指标统一维护和使用

· 业务拓扑信息更加丰富

· 可以基于cmdb关系做指标的OLAP分析

| 后台实现

· 监控指标存储简洁高效

· 简化业务逻辑

· 一个查询语句即可完成大部分需求

· 接口性能提升10倍以上

UGeek大咖说 | 直播回顾:可观测之超融合存储系统的应用与设计

6

在线问答

直播过程中,我们的评论区出现了很多来自同学们的提问,小编已将问答部分整理成文字版,供大家温习。

问题1:图数据库和时序数据库是怎么关联的?图数据库关系怎么自动构建?

分为两个,我们的时序数据和图数据是分开存储的。结合的一个关键问题,就是查询引擎。图数据库里有文档数据以及图数据,相当于再加了一个时序数据。唯一不同是,时序数据是独立,是通过远程调用的。

比如一个请求过来之后,查询引擎会自动分析查询条件,是要去时序数据库查,还是到文档查,智能分析并分解成不同的算子。这里会牵扯到很多的细节。比如怎么保证查询是高效的?先查CMDB还是先查Easycore?查询的算子是怎么样的?如何组合查询算子下推。优化之后就整合起来了。这里的关系是,我们对外主要面向的都是Easycore,提供Easycore的产品入口,而时序数据库是不直接对外的。

问题2:Influxdb数据库对比怎么样?

我们研发的时候做了性能对比,有1.0版、2.0版,以及一个未发布的成版。我们的TSDB数据库架构是最新的,和未发布的成功版一样,与它们2.0数据库对比,在一些小数据量查询时比它稍微差一点,大数量查询比较好,比如几十个Tag的查询,数据量在上亿时,性能是比它强很多的,所以目前来看是各有优缺点,在小数据量查询这一块我们还会继续优化。目前的架构应该是未来的架构,因为它们未发布的那一版也是用这个架构的,它们还在积极开发的过程中,并且也是开源的。

问题3:数据库的性能怎么样?

企业成立之初,我们的数据库最早用的是CMDB是用MongoDB的。后面改用了OracleDB,但发现它的性能,稳定性等各方面都达不到我们的要求。所以我们才自研了图数据库。我们的图数据库里面图的引擎是直接传输在内存里的。所以这一块性能相比Oracle有很大提高。因为现在已经使用好多年,性能和稳定性也有了很大提升。

问题4:为什么要自研TSDB不用开源方案?

有两方面的考虑。

为了融合,首先时序数据库要能够解析查询引擎发出来的查询算子,给我做什么预算。如果是用传统的开源数据库,就相当于绕了一层,要转成你的查询语言,再返回,本来可以做一些更优化的查询,由于你的接口限制,导致没法做优化查询,这是最重要的一方面。另外一块,我们这里是可以针对的应用场景去做一些个性化的优化,比如我只需要监控,专存的数据。还可以把CMDB的一些核心的数据就比如我们的CMDB里的InstanceId,可以作为一个核心的标签拿过来,就可以针对这个标签去做特殊的优化了,之后只要按这个标查询,就会有性能极大的提高,这也是为什么说我们在数据量大的时候能够比InfluxDB查询效率高的原因,因为有了CMDB查询的场景,查询的时候必然会带某些Tag过来。那我就可以针对这些必然带的数据做一些个性化的优化,去提升整体的性能。

问题5:图数据库会开源吗?

我们有开源的计划。目前由于一些外部接口和内部的依赖都和CMDB强绑定,后续把更多东西处理好之后,我们会做成开源的,把成果让大家一起分享。

问题6:数据库是用什么语言实现的?

发表评论

相关文章