摘要：PipelineDB由Derek Nelson创立，是Y Combinator 2014年冬季班的一部分，于2015年4月发布测试版，2015年6月开源，最终于2019年5月被Confluent收购（收购价格未公开披露）。由于收购，该项目在1.0.0之后不再有
PipelineDB由Derek Nelson创立，是Y Combinator 2014年冬季班的一部分，于2015年4月发布测试版，2015年6月开源，最终于2019年5月被Confluent收购（收购价格未公开披露）。由于收购，该项目在1.0.0之后不再有新的版本发布，但管关键的错误修复仍会继续进行。
PipelineDB的根本创新是通过"连续视图"将连续SQL查询引入PostgreSQL——本质上是极高吞吐量、增量更新的物化视图，无需手动刷新，原始时间序列数据不会写入磁盘。
PipelineDB被设计为PostgreSQL扩展，使用外部表来表示数据流，连续查询实时处理数据并产生自己的输出流，这些输出流可以链接在一起。
与时序数据库TimescaleDB相比，PipelineDB专注于使用连续视图进行实时分析，而TimescaleDB则强调使用超表进行历史数据分析。PipelineDB被认为是最早的流式数据库解决方案之一（后面类似的项目还有Confluent的ksqlDB，Materialize，RisingWave和Timeplus的Proton）。
由于与PostgreSQL兼容性、内存效率（无原始数据存储）、实时处理能力和SQL熟悉度使传统数据库开发人员能够轻松使用。但是由于系统需要预定义的连续查询（无法对原始数据进行即席分析），仅限于SQL可表达的计算，在企业版推出之前存在扩展性挑战。
PipelineDB 的基本抽象被称为持续视图。持续视图非常类似于常规视图，但不同之处在于它从流和表的组合中选择作为其输入，并且随着新数据写入这些输入，它会实时增量更新。
主要特点：
吞吐量极高、增量更新的物化视图，无需手动刷新。一旦流中的行被必须读取它的持续视图读取后，该行就会被丢弃。原始的、细粒度的数据不会存储在任何地方。原始时间序列数据不会写入磁盘，这使得 PipelineDB 在聚合工作负载方面效率极高。流 (Streams)
流是允许客户端通过持续视图推送时间序列数据的抽象。流行，或简称为事件，看起来与常规表行完全相同，并且写入流的接口与写入表的接口相同。
流在 PipelineDB 中表示为由 pipelinedb 外部服务器管理的外部表。
输出流 (Output Streams)
输出流使得可以从对任何持续视图所做的增量更改流中读取，或者从持续转换选择的行中读取。对于持续视图，输出流中的每行始终包含一个旧元组和一个新元组，代表对底层持续视图所做的更改。
PipelineDB 的设计将实用性作为首要考虑，这就是其打包为 PostgreSQL 扩展的原因。所有数据存储和操作都委托给 PostgreSQL，这是一个极其稳定、成熟且无处不在的数据库。
基于 PostgreSQL 9.4，并与其协议兼容。兼容活跃的 PostgreSQL 生态系统中的所有工具。没有发明自己的专有语法，甚至没有 PipelineDB 客户端，因为它使用任何已有的PostgreSQL 客户端一起工作。聚合引擎 (Aggregation Engine)，持续聚合会随着新事件被其所属的持续视图读取而实时增量更新。对于计数和求和等简单聚合，很容易看出它们的结果如何能够增量更新——只需将新值添加到现有结果中即可。
还有其他的高级功能包括HyperLogLog 实现，用于在恒定空间和时间内进行去重计数，但会牺牲少量误差。根据经验，PipelineDB 的 HyperLogLog 实现的错误率大约为 0.81%。概率数据结构、滑动窗口和流-表连接等等。
创建流Stream
CREATE FOREIGN TABLE test_stream (key integer, value integer) SERVER pipelinedb;创建连续视图
CREATE VIEW test_view WITH (action=materialize) AS SELECT key, COUNT(*) FROM test_stream GROUP BY key;插入数据
INSERT INTO test_stream(key,value) VALUES (0,42);查询
PipelineDB作为早起使用数据库技术来解决流数据处理问题的项目，具备不少优点：
技术优势PostgreSQL 兼容性：与现有的 PostgreSQL 工具和生态系统完全兼容。内存效率：原始时间序列数据从不写入磁盘，使得 PipelineDB 在聚合工作负载方面效率极高。实时处理：确保低延迟，无需部署管理数据库的实时应用程序代码。增量计算：自动处理复杂聚合的复杂增量更新。SQL 熟悉度：任何熟悉 SQL 的工程师和开发人员都能构建可扩展、容错的分析应用程序。运营优势简化架构：无需外部数据集市或数据仓库来管理来自操作数据的分析数据。可链式查询：持续查询产生自己的输出流，因此可以链式组合成任意的持续 SQL 网络。易于设置：PipelineDB 提供简单的设置和使用。它的缺点和局限性包括：
架构局限性无即席查询（Adhoc Query）：鉴于持续查询必须是预先知道的，PipelineDB 不是一个即席数据仓库。虽然持续查询的输出可以以即席方式探索，但所有曾经通过 PipelineDB 的原始数据可能无法被探索，因为数据点在被读取后就会被丢弃。数据有丢失风险：一旦原始数据通过持续视图，它就会被永久丢弃，使得数据恢复变得不可能。仅限 SQL 处理：如果需要无法用 SQL 表示的流计算，PipelineDB 可能不是合适的工具。PipelineDB 通过将持续 SQL 查询直接引入 PostgreSQL 生态系统，代表了一种创新的流式分析方法。尽管该项目最终被收购并作为独立产品停止，但其架构概念和技术贡献影响了更广泛的流数据库领域。该项目展示了创建 PostgreSQL 原生流式分析解决方案的潜力与挑战，为后续更成熟的流数据库平台（ksqlDB，Materialize，RisingWave，Timeplus/Proton）铺平了道路。
Confluent 的收购显示了对 PipelineDB 技术方法和团队专业知识的价值肯定，但是这样的收购，有成功的例子，也有很多以失败告终，被收购的产品往往会从支持通用案例的解决方案，变成服务于收购企业特定需求的工具。产品和项目可能已经不在了，但是这些代码，换了一个方式，继续着它们的故事。真可谓 “落红不是无情物，化作春泥更护花”
来源：闻数起舞
