3

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

 2 years ago
source link: https://studygolang.com/articles/35753
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

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

EASYOPS_youwei · 大约4小时之前 · 30 次点击 · 预计阅读时间 3 分钟 · 大约8小时之前 开始浏览    

21a43e26ef3b402ab1952e96e009740b~tplv-tt-shrink:640:0.image

上周，UGeek大咖说第六期

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

专题分享活动完美落幕

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

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

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

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

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

| 需求场景

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

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

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

| 需求分析

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

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

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

| 常规解决方案

· 先查CMDB，再查监控数据，然后过滤整合？

· 先查监控数据，再查CMDB，然后过滤整合？

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

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

优维解决方案-融合存储

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

e61a184dfae6491ab7ad5ff879903f48~tplv-tt-shrink:640:0.image

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

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

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

b716d82e08bd4bfdbe27db81d485b553~tplv-tt-shrink:640:0.image

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

超融合数据库easy_core

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

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

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

· 容量可平行扩展

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

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

融合存储的优势

| 产品功能

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

· 业务拓扑信息更加丰富

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

| 后台实现

· 监控指标存储简洁高效

· 简化业务逻辑

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

· 接口性能提升10倍以上

7f1a6f3d1b70432ba7496041d036fa86~tplv-tt-shrink:640:0.image

在线问答

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

问题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：数据库是用什么语言实现的？

我们用了Rust。Rust有个特点就是它的性能是和C/C++差不多的，具有高性能，而且在实现的时候能够从语言层面去解决一些数据竞争、数据安全的问题，所以用Rust来写可以达到高性能，用以实现数据库是非常合适的。

有疑问加站长微信联系（非本文作者）

280

入群交流（和以上内容无关）：加入Go大咖交流群，或添加微信：liuxiaoyan-s 备注：入群；或加QQ群：692541889


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK