PipeLineDB数据库介绍和总结

PipelineDB 是开源的关系型数据库,可以在 streams 中持续运行 SQL 查询,逐渐将结果存储在表中。本文将对PipelineDB做相应的总结。

1、基于Postgre数据库, 可以使用数据库库的函数,表达式,存储过程等功能,自身功能就已经足够强大了。而且还支持proxy等分表分库插件。

2、所有的流必须以Stream开始,先创建stream然后才可以使用view或者transform来查询。stream中的数据必须通过insert插入。

3、view和transform的区别在于,view的计算结果会保存在pg数据库中,transform不会保存,只能定义触发器来将结果输出到其他地方。

4、可以在存储过程中调用view,但是 transform由于结果已经被重定向了,所以无法调用。

5、在没有transofrm或者view的情况下性能很高,在8U32G的虚拟机下性能接近10WTPS。如果使用view之后性能会急剧下降。即使将pg的data空间放在内存盘中,性能也会下降的很厉害,一个stream下挂了10个view,TPS大约在3000左右。可见,PipelineDB的性能消耗在于计算部分,即使数据不落盘,但是计算仍然还是比较消耗性能。

窗口:

PipelineDB中只支持滑窗。使用当前时间和到达时间做对比,来确定窗口范围。

Clock_Timestmap:当前时间,Arrival_timestamp到达pipelinedb的时间。

比如一个最近1分钟的滑动窗:

[sql] view plain copy

  1. CREATE CONTINUOUS VIEW recent_users WITH (sw = '1 minute') AS
  2. SELECT user_id::integer FROM stream;  

pipelinedb会将语句改写为:

[sql] view plain copy

  1. CREATE CONTINUOUS VIEW recent_users AS
  2. SELECT user_id::integer FROM stream  
  3. WHERE (arrival_timestamp > clock_timestamp() - interval '1 minute');  

多个不同大小的滑窗之间可以进行合并,比如5分钟,10分钟的滑窗,在pipelinedb中会进行合并,值创建一个10分钟的滑窗。这样可以有效减少数据量。

步长决定了窗口内数据更新的频率,pipelinedb使用一个1-50的范围数字用来描述更新粒度,单位为百分比,步长是数据更新的间隔,数据一个步长一个步长的过期

一个较小的步长,滑窗统计会更加精确,但是会占用更多的数据存储空间,比如1小时的滑窗,步长为5,也就是3分钟更新一次数据,那么物化视图的表中数量就会比步长为10的窗口数据多出一倍。

但是这样统计结果也会更加精确,统计精度在3分钟,而10的步长,统计进度就会在6分钟。误差就大了一倍。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

扫码关注云+社区