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分钟。误差就大了一倍。