Live data from Hacker News

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

github.com

81–87 of 87 posts

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

#81

Many applications solve this by using memory caching (e.g. Redid, memcached, etc.) of performance sensitive datasets. There are a lot of drawbacks to the approach, to the point that I would avoid it altogether.

The difference is that with simple caching you have to run full queries again when the cache becomes invalidated. This is often expensive especially on write intensive data usages.

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

#83

Earlier quoted context omitted.

The writes are not tunneled somehow through this algorithm. You still use the database like your normally would do. So the consistency is not affected. Also this is an open source project, not something I want to sell you. Feel free to make a PR/issue with any open topics that are not mentioned in the docs.

>The writes are not tunneled somehow through this algorithm Then I fail to understand how it works. How Event-Reduce becomes aware of these "write events"? >this is an open source project, not something I want to sell you You made it open source so others can use it, right? They better be making an informed decision whether your solution suits their needs.

> How Event-Reduce becomes aware of these "write events"?

Some DBs expose an event stream, for example, PG:

https://www.postgresql.org/docs/current/logicaldecoding-expl...

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

#85

How does this work for complex queries with sub-queries, LEFT OUTER JOINs, LATERAL JOINs, aggregation (DISTINCT/GROUP BY), window functions, CTEs, RECURSIVE CTEs? I've a radically different approach: can the queries in question as VIEWs, materialize them, use triggers to update materializations where you can write those triggers easily and the updates are quick, or schedule an update where they're not. If your RDBMS…

It sounds like you did not read the READme. What you are describing is something that does scale up with more data but not with more requests. When you have an application where 1000s of users subscribe to different queries, your view-maintainance would kill the write performance while EventReduce does not.

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

#86
post #6

Sooo...Materialized/Indexed Views?

No, see the FAQ in the readme: Materialized views solve a similar problem but in a different way with different trade-offs. When you have many users, all subscribing to different queries, you cannot create that many views because they are all recalculated on each write access to the database. EventReduce however has a better scalability because I does not affect write performance and the calculation is done when the…

Others have pointed this out already: This is wholly dependent on the RDBMS used, and Oracle offers incremental refresh on demand. I have to admit though that I mistakenly thought that MSSQL would as well...

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

#87
post #2

Materialize exists to efficiently solve the view maintenance problem: https://materialize.io/

It seems to me that I want heterogeneous replicas of my databases. Partial indexes on this copy, full indexed on this one, no deletes on this one.

But a simpler solution might be to have a standard WAL format, and use that as a basis for having replicas of the system of record be a first class citizen in my data center instead of something we all cobble together or pay for.

Post reply on HN