News for hackers. Stuff that matters.

A comment on Scalable Stream Processing: A Survey of Storm, Samza, Spark and Flink. Parent comment

Re:Scalable Stream Processing: A Survey of Storm, Samza, Spa... by wolle on Sunday September 18, 2016 @04:29PM (#12527082)
Depending on your requirements, a single-node solution like PipelineDB may suffice; it's a PostgreSQL extension that lets you write streaming SQL queries.
[ Parent | on HN ]
Re:Scalable Stream Processing: A Survey of Storm, Samza, Spa... by Fergi on Sunday September 18, 2016 @09:02PM (#12528111)
Jeff from PipelineDB here. We are also rolling out a SaaS product based on PipelineDB called Stride (stride.io) that enables this type of computation via an API with little to no overhead.
[ Parent | on HN ]
Re:Scalable Stream Processing: A Survey of Storm, Samza, Spa... by justinsaccount on Sunday September 18, 2016 @04:45PM (#12527139)
That is definitely along the lines of what I'm looking for..

the esper stuff was on my radar, but something that works with existing postgresql tools is a huge plus.

[ Parent | on HN ]
Re:Scalable Stream Processing: A Survey of Storm, Samza, Spa... by avifreedman on Sunday September 18, 2016 @05:55PM (#12527397)
PipelineDB can scale out to multiple nodes (for $).
[ Parent | on HN ]
Re:Scalable Stream Processing: A Survey of Storm, Samza, Spa... by wolle on Monday September 19, 2016 @05:26AM (#12530029)
Is there a reference regarding the number of nodes that can be deployed in the cluster, and are feasible to maintain? From the docs, I gather that "[a]ll DDL/non-stream DML statements are executed in a distributed transaction on all nodes in the cluster and committed via two-phase commit." [1]

Doesn't that get in the way of low latency and availability?

[1] http://enterprise.pipelinedb.com/docs/two-phase.html#two-pha...

[ Parent | on HN ]