PipelineDB 测试(一):实时计算效率测试 (基于PipelineDB做接口调用相关日志的运维监控)

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u012551524/article/details/87987269

背景:基于PipelineDB做接口调用相关日志的运维监控

数据流向:Web Server -> Log -> Td-agent -> PipelineDB

系统及相关组件版本:

系统版本:ubuntu 16.04

td-agent版本:2.1.0

postgresql版本:10.0

Postgresql版本:Postgresql10.0

PipelineDB版本:1 .0

PipelineDB安装参考:https://blog.csdn.net/u012551524/article/details/86705632

Td-agent数据采集到PipelineDB(即到Postgresql):https://blog.csdn.net/u012551524/article/details/86705452  


一、以前是什么样子的?现在是什么样子的?为什么?

原日志监控流程:Web Server -> Log -> Td-agent -> ElasticSearch

新的方案:Web Server -> Log -> Td-agent -> PipelineDB

原因:

1、PipelineDB是基于Postgresql的流式计算插件,在原有的Postgresql上装一个插件就能完成的事情为什么要再去维护一个ElasticSearch,降低了运维成本,一库搞定所有

2、开发成本低,对于开发者来说,都是在查PG,写sql

二、测试场景及流程

通过大批量造日志的方式,由Td-agent采集数据到PipelineDB,统计接口的平均响应时间,测试数据的聚合查询效率

1、创建一个PipelineDB stream

CREATE FOREIGN TABLE stream_df (remote text,time1 timestamp with time zone, method text, path text, code text, status boolean, req_size integer,res_size integer,traffic integer,request_time float,referer text,agent text,forwoad text,request text,response text,uuid text,app_id text)SERVER pipelinedb;

2、创建秒级Continue view,实时聚合

CREATE VIEW log_stream_second WITH (action=materialize ) AS  select cast(avg(request_time) as decimal(6,3)) as data_index,EXTRACT(epoch FROM CAST(st_time AS TIMESTAMPTZ)) as date_flag,path,st_time as time from log_stream  group by EXTRACT(epoch FROM CAST(st_time AS TIMESTAMPTZ)), path ,st_time;

3、创建分钟级Continue view,实时聚合

CREATE VIEW log_stream_minute WITH (action=materialize ) AS  select cast(avg(request_time) as decimal(6,3)) as data_index,EXTRACT(epoch FROM CAST(st_time AS TIMESTAMPTZ))::integer/60*60 as date_flag,path,TO_TIMESTAMP(EXTRACT(epoch FROM CAST(st_time AS TIMESTAMPTZ))::integer/60*60) as time from log_stream group by EXTRACT(epoch FROM CAST(st_time AS TIMESTAMPTZ))::integer/60*60, path,TO_TIMESTAMP(EXTRACT(epoch FROM CAST(st_time AS TIMESTAMPTZ))::integer/60*60);

三、测试结果

1、数据量

总数据量:一共造了600W数据

秒级聚合视图数据量(log_stream_second):350W

分钟级聚合视图数据量(log_stream_minute):10W

2、做二次聚合查询时间

查询秒级聚合视图的结果数据:

查询分钟级聚合视图,做全量二次聚合:

查询秒级聚合视图,做全量二次聚合:

3、结论

1、查询聚合过的结果,速度很快,并且可以通过建索引等方式进行优化,这也是用的最多的场景,我们通过pipelineDB,在数据以流的形式进来之后,实时聚合,得到我们想要的数据,直接以最简单的查询方式做到前端展现

2、基于已经计算过的数据,在此之上做二次聚合,基于分钟级视图的二次聚合效果依然很优秀,但是基于秒级视图的二次聚合需要3秒,这个聚合效率其实就是跟数据量有关了,所以有这种二次聚合的场景就需要更好的去设计实时聚合的一级视图,实时聚合的力度能否是10秒,20秒,1分钟?能否直接实时聚合出自己想要的结果,从而避免二次聚合?

3、实时聚合的速度上还是很快的,日志的并发量大概在每秒300(看德哥的博客可以到每秒100W,所以每秒几千感觉还是轻轻松松的,当然,需要后续测试)

四、总结

测试效果其实挺不错的,对于一些数据量不是很大日志进行实时计算其实是一种很好的方式!后续发现问题再做补充!

猜你喜欢

转载自blog.csdn.net/u012551524/article/details/87987269