Postgresql - PipelineDB - Sliding Windows
由于 Continuous Views 是随着时间连续地和增量地更新的，所以在更新 Continuous Views 的结果时，PipelineDB有能力考虑当前时间。包含WHERE子句和与当前时间相关的时间组件的查询称为sliding-window 查询。滑动WHERE子句筛选或接受的事件集会随着时间不断变化。
sliding WHERE子句 两个重要组成部分：
clock_timestamp ( )：一个内置函数，它总是返回当前的时间戳。
arrival_timestamp：所有传入事件的一个特殊属性，包含PipelineDB接收它们的时间，就像描述在Arrival Ordering的一样。
但是，没有必要显式地添加引用这些值的WHERE子句。PipelineDB在内部执行此操作，并且只需要在Continuous Views 的定义中指定sw存储参数。
尽管sliding windows 是SQL数据库的新概念，但是PipelineDB没有使用任何新的或专有的窗口语法。相反，PipelineDB 使用标准PostgreSQL 9.5语法。
PipelineDB允许用户在定义滑动窗口连续视图时手动构造滑动窗口WHERE子句。
这个连续视图上的SELECT结果只包含最后一分钟内看到的特定用户。也就是说，重复的SELECT将包含不同的行，即使连续视图没有显式更新。
每次计算clock_timestamp() - interval '1 minute' 时，它将返回与过去1分钟相对应的时间戳。如果给定事件的arrival_timestamp 在过去大于1分钟，则添加arrival_timestamp 和 > 意味着该谓词将计算为true。由于每次读取新事件时都会评估谓词，因此这有效地给了我们一个1分钟宽的 sliding window 。
实验：
CREATE FOREIGN TABLE stream (x integer, y integer) SERVER pipelinedb;
CREATE VIEW v_sw_test_01 WITH (sw = '1 minute') AS SELECT user_id::integer FROM stream;
写一个python脚本，向stream中插入数据。
import psycopg2
conn = psycopg2.connect("host=localhost user=mytest")
for i in xrange(51,100):
SQL = "INSERT INTO stream VALUES (%s,2);" % i
cur = conn.cursor()
cur.execute(SQL)
conn.commit()
time.sleep(23)
边执行脚本，边查看v_sw_test_01视图中的数据，发现当前存在的数据，只是最近一分钟插入的数据。
mytest=# select * from recent_users;
x
----
77
78
79
(3 rows)
过一会儿
mytest=# select * from recent_users;
x
----
78
79
(2 rows)
再过一会儿
mytest=# select * from recent_users;
x
----
78
79
80
(3 rows)
实际上，在内部，PipelineDB将将此查询重写为以下内容：
CREATE VIEW v_sw_test_01 AS
SELECT x::integer FROM stream
WHERE (arrival_timestamp > clock_timestamp() - interval '1 minute');
============================================================
Sliding Aggregates
Sliding-window 查询还与聚合函数一起工作。滑动聚合通过尽可能多地聚集它们的输入而工作，但不丢失需要知道如何随着时间的推移从窗口中移除信息的粒度。这种部分聚合对用户来说是透明的，只有完全聚集的结果才会在滑动窗口聚集中可见。
CREATE VIEW v_count_sw_test_ WITH (sw = '1 minute') AS SELECT COUNT(*) FROM stream;
每次在这个 Continuous Views 上运行SELECT时，它返回的计数将只是最后一分钟内看到的事件的计数。例如，如果事件停止进入，则每次在 Continuous Views 上运行SELECT时，计数都会减少。
CREATE VIEW sensor_temps WITH (sw = '5 minutes') AS SELECT sensor::integer, AVG(temp::numeric) FROM sensor_stream GROUP BY sensor;
5分钟平均温度是多少
CREATE VIEW uniques WITH (sw = '30 days') AS SELECT COUNT(DISTINCT user::integer) FROM user_stream;
在过去的30天里，我们看到了多少个不重复的用户
============================================================
Temporal Invalidation
显然， continuous views 中的滑动窗口行在一定时间之后变得无效，因为它们已经太老而不能包含在 continuous views 的结果中。这样的行必须是垃圾收集，这可能以两种方式发生：
Background invalidation：类似于PostgreSQL的自动清空器的后台进程定期运行并从sliding-window continuous views中物理删除任何过期的行。
Read-time invalidation：当使用SELECT读取 continuous view 时，在生成结果的同时动态地丢弃任何太旧而不能包括在结果中的数据。这确保即使仍然存在无效行，它们实际上也不包含在任何查询结果中。
============================================================
step_factor
在内部，尽可能聚合支持 sliding-window 查询的物化表。但是，不能将行聚合到与查询的最终输出相同的粒度级别，因为当数据超出窗口时，必须从聚合结果中删除数据。
例如，按小时聚合的 sliding-window 查询实际上可能具有磁盘上的分钟级聚合数据，因此只有最后60分钟包含在返回给读取器的最终聚合结果中。这些用于 sliding-window 查询的内部更细粒度的聚合级别称为“步骤”。“覆盖”视图被放置在这些步骤聚合之上，以便在读取时执行最终聚合。
步骤聚合是决定 sliding-window 查询读取性能的重要因素，因为每个最终滑动窗口聚合组在内部由多个步骤组成。每个滑动窗口聚合组将具有的步骤数量可以通过step_factor参数进行调整：
step_factor
一个介于1和50之间的整数，将 sliding-window 步长的大小指定为由sw给出的窗口大小的百分比。如果使用较小的step_factor，则在数据离开窗口时提供更大的粒度，代价是磁盘上的物化表更大。更大的step_factor将减少磁盘上的物化表大小，但代价是减少窗口外粒度。
CREATE VIEW v_sw_test_03 WITH (sw = '1 hour', step_factor = 50) AS SELECT COUNT(*) FROM stream;