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.
EventReduce: An algorithm to optimize database queries that run multiple times
81–87 of 87 posts
Re: EventReduce: An algorithm to optimize database queries that run multiple times
#82Re: EventReduce: An algorithm to optimize database queries that run multiple times
#83Earlier 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.
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
#84Re: EventReduce: An algorithm to optimize database queries that run multiple times
#85How 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…
Re: EventReduce: An algorithm to optimize database queries that run multiple times
#86Sooo...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…
Re: EventReduce: An algorithm to optimize database queries that run multiple times
#87Materialize exists to efficiently solve the view maintenance problem: https://materialize.io/
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.