EventReduce: An algorithm to optimize database queries that run multiple times

Re:EventReduce: An algorithm to optimize database queries th... by alecco on Thursday April 16, 2020 @08:19AM (#22888605)

The use case seems better fit for a streaming database.

[ Parent | on HN ]

Re:EventReduce: An algorithm to optimize database queries th... by eventreduce on Thursday April 16, 2020 @08:37AM (#22888728)

There is a big difference between a database with an event stream and a 'realtime query' that can be created with event reduce.

[ Parent | on HN ]

Re:EventReduce: An algorithm to optimize database queries th... by scott_s on Thursday April 16, 2020 @09:19AM (#22889028)

What is that difference?

[ Parent | on HN ]

Re:EventReduce: An algorithm to optimize database queries th... by eventreduce on Thursday April 16, 2020 @12:57PM (#22891310)

I recommend the video "Real-Time Databases Explained: Why Meteor, RethinkDB, Parse & Firebase Don't Scale" https://www.youtube.com/watch?v=HiQgQ88AdYo

[ Parent | on HN ]

Re:EventReduce: An algorithm to optimize database queries th... by scott_s on Thursday April 16, 2020 @01:14PM (#22891467)

That does not answer what differentiates your solution. I work on steaming systems. I am aware of the spectrum of online, latency aware data processing. But what I can tell from your solution is that the changes are coming from the database itself. Since, as I understand it, the database is the still the source of all data, I don’t see why your solution is any faster than continuous queries in a database.

[ Parent | on HN ]