从 Elasticsearch 到 SelectDB,观测云实现日志存储与分析的 10 倍性价比提升

作者:蒋硕淼,观察云& CEO;飞轮技术团队

随着云计算的逐渐成熟,越来越多的企业开始将业务迁移到云上,传统的监控和故障排查方式已经不能满足企业的需求。在可观测性概念逐渐深入人心的当下,人们越来越意识到通过多层次、多维度、多视角的数据来观察应用系统,以提高故障定位效率和业务分析能力。本质上,观测云是一个综合的、可观测的解决方案,可以提供整体数据分析、洞察、可视化、自动化、监控报警、智能巡检、安检等服务。

为了更好地提供上述服务,要求观测云具备观测基础对象、网络性能、日志、应用性能、用户体验、可用性甚至CI的能力。这些能力需要观测云整合多场景、多结构的海量数据,提供全面的日志检索和分析能力,快速实现数据查询、筛选和分析。

为了解决观察云在日志存储和场景分析方面的挑战,飞轮技术与观察云进行了全面合作。通过SelectDB的倒排索引能力、变体数据类型、冷热数据分层存储等特性,为观测云日志存储和场景分析服务注入强大动力,降低存储成本70%,提升查询性能2-4倍,最终提升整体性价比10倍!

GuanceDB原始架构

观测云具有强大的数据访问能力。通过自主开发的All In One采集工具DataKit,可以从不同的端侧、业务层、中间件、基础设施等不同层面获取数据,同时进行预处理和元信息关联。除了广泛支持日志数据,Datakit还支持在APP端或浏览器端收集和处理基础设施时序指标、链接跟踪、安全事件和用户行为数据。为了满足多样化的多场景需求,DataKit不仅完全兼容开源探头和采集器,还支持访问自定义格式的数据源。

DataKit采集的数据经过核心计算层处理后,会存储在GuanceDB中。GuanceDB是由观测云自主研发的多种数据库技术组成的多模态数据库。

GuanceDB的内部架构如上图所示,主要包括两层:查询引擎和存储引擎。在逻辑结构上,查询引擎和存储引擎通过抽象实现解耦,整体架构可插拔、可替换。

观察云基于VictoriaMetrics存储模块开发了时间序列存储引擎MetreStore,在泛日志场景下集成了Elasticsearch/OpenSearch。这种设计使得GuanceDB具有统一的编写和查询接口,可以适应不同类型的数据格式和业务需求。在当前的实现中,MetricStore已经具有出色的性能。但是,对于日志数据和用户行为数据的处理,Elasticsearch有很多缺点,具体如下:

选择目标和调查

原有架构中弹性搜索的问题促使我们对架构进行升级。在升级之前,我们调查了包括SelectDB在内的几个数据库。结合实际可观测性场景,我们的选择目标如下:

综合来看,SelectDB可以满足观测云的大部分需求,与同类产品相比表现不错。我们还将在后面的章节中详细介绍基于SelectDB的转换实践。特别值得一提的是,在之前的研究中,以下特征是吸引我们的重要特征:

基于SelectDB的存储架构升级

因此,我们引入SelectDB来升级GuanceDB的内部架构。为了更好地介绍SelectDB如何在GunaceDB中扮演存储引擎的角色,我们将首先介绍DQL查询语言。

在可观测性场景下,几乎所有的查询都涉及到时间过滤,大部分的聚合都需要按照时间窗口进行,而对于时间序列,还需要支持按照单个序列进行时间窗口前后的滚动。在这些场景中,使用SQL来表达相同的语义需要嵌套多级子查询,这使得表达过程和编写极其复杂。

因此,我们尝试简化语法元素,并在此基础上设计了新的查询语言DQL,增强了可观测场景下的常用计算功能。通过DQL,我们可以查询所有可观察的数据,如指标,日志,链接跟踪和对象。

根据GuanceDB的内部结构,我们在本次升级中使用SelectDB替代Elasticsearch/OpenSearch,原有的查询架构不变。

接下来,我们介绍引入SelectDB后DQL查询的工作方式:

如上图所示,Guance-Insert是一个数据写入组件,Guance-Select是一个DQL查询引擎。

当前的查询体系结构是一种混合计算体系结构,它集成了FE和BE的能力。DQL不仅可以利用SelectDB完全优化的查询功能,还可以使语法扩展不受SelectDB本身SQL功能的限制。

架构升级的好处

存储成本降低70%左右,查询性能提高3倍。

SelectDB的引入大大降低了综合成本。之前我们使用了由20台1664G云主机组成的Elasticsearch集群,在云上的一个可用区域提供查询服务,并采用了独立的索引写入服务(相当于使用了20台云主机)。替换为SelectDB后,只需要13台相同配置的云主机,总成本降低67%。成本的大幅降低主要归因于两个因素:

SelectDB的引入显著提高了查询性能。在减少机器数量后,我们比较了两个集群中相同查询的性能。实践表明,SelectDB的点检查和列表查询速度比Elasticsearch快近2倍,在聚集查询不抽样的情况下比Elasticsearch快近4倍。

综上所述,用SelectDB替代Elasticsearch后,只用了elastic search 1/3的成本,实现了2 ~ 4倍的性能提升,整体性价比提升近10倍!

02倒排索引满足日志场景的全文检索要求

倒排索引可以显著提高全文检索的性能,降低查询的资源开销,是实现高效日志分析的必备能力。SelectDB支持倒排索引。以下是对我们从Elasticsearch迁移到SelectDB过程中的关键功能的介绍:

除了满足日志全文检索的需求,SelectDB倒排索引还支持按需在线增减索引。Elasticsearch索引在创建时是固定的,以后不能再添加索引字段。所以需要提前规划哪些字段需要索引,如果将来需要更改索引,就需要重写,更改成本很高。SelectDB支持在运行过程中根据需要添加索引,新写入的数据索引会立即生效。同时,SelectDB可以控制索引哪些分区,使用起来非常灵活。

03变体数据类型,解决数据模式频繁变化的痛点

在可观测的场景中,数据种类繁多,变化频繁。例如,我们可能会在收集用户的行为(如网页上的每次点击和每次导入)时添加新的业务指标。这种场景对数据库的实时模式变化提出了更高的要求。

在常见的数据库中,大部分数据表的模式是静态的,有些数据库如Elasticsearch可以通过映射实现动态模式。但是,动态模式可能会遇到字段类型冲突或字段数量达到上限的问题,因为历史字段不是无效的。引入SelectDB后,我们使用最新的特性变体动态数据类型(将在Apache Doris版中正式发布)来很好地支持这类场景。

SelectDB为半结构化数据设计了Variant数据类型,它具有以下特征:

Variant type和Elasticsearch动态映射最显著的区别在于,动态映射的范围是当前表的完整生命周期,而Variant的范围只在当前动态分区内。这种差异化的设计使得Variant列能够随着业务数据写入的变化而周期性失效,从而降低了类型冲突的概率。例如,当我们今天更改业务逻辑代码并重命名一些业务字段时,明天旧的字段名称将不会出现在Variant列中。所以我们可以认为Variant只维护最新数据的类型数据。

此外,当单个分区中的字段类型发生冲突时,将升级为JSON数据类型,从而避免了数据错误和数据丢失的问题。比如业务系统中有两个地方用到status字段,一个是字符串,一个是数字,那么我们在查询的时候就可以根据实际的语义来选择当前查询是需要字符串,数字还是两者都需要。(假设您在筛选条件中写入status = & quot好的& quot在这种情况下,将只过滤状态类型为字符串的数据。)

使用Variant数据类型后,用户在实际的编写和查询中不需要知道Variant的存在。用户可以根据自己的业务需要添加或删除字段,就像使用普通的列一样。在进行查询时,不需要额外的语法或注释,只需将其作为普通列计算即可。

在当前版本中,Variant数据类型在使用时需要额外的类型断言,自动类型断言将在后续版本中更新。目前,在DQL的查询中,我们已经实现了Variant列的自动类型断言。在大多数情况下,可以根据变量的实际数据类型直接进行断言。只有在少数类型冲突的情况下,Variant列才会升级到JSON数据类型。此时,我们将根据DQL查询中的聚合运算符或运算符关联语义进行实际断言。

设计采样逻辑以提高聚合查询性能

在适配的过程中,我们发现虽然SelectDB的性能很强大,但是在需要聚合大数据集的时候,还是会占用较多的系统资源,计算开销比较高。在可观测的场景中,大部分计算都是定性分析,不是定量绝对值精确分析。

基于这样的业务背景,我们在GunaceDB中设计了以下采样逻辑:

在这样的采样逻辑下,可以显著降低超大规模计算所需的计算开销和用户等待时间,性能比之前提升数十倍,极大地改善了用户体验。

结束语

SelectDB的引入满足了我们Schema Free的需求,解决了数据模式频繁变化的痛点。提高了数据写入的性能,保证了数据写入和实时查询的及时性;提高了全文检索的性能,降低了查询的资源成本……总之,SelectDB的应用可以降低70%的观测云存储成本,提高查询性能2-4倍,最终提高整体性价比10倍!未来,我们将继续与飞轮科技合作,为用户打造更多受欢迎的解决方案,同时共同推动Apache Doris社区的发展壮大!

未经允许不得转载:科技让生活更美好 » 从 Elasticsearch 到 SelectDB,观测云实现日志存储与分析的 10 倍性价比提升