I was facing a problem where I had to run queries on MongoDB joins at many places in my code. Instead of writing joins in my code I thought of using MongoDB joins.
MongoDB views are virtual collections that allow you to use any aggregate pipeline or query as a readable structure.
For example, we can create a view on this query
db.createView("high_value_orders", "orders", [
{
$match: {
total: { $gt: 500 }
}
}
]);
Now, any developer in the code can just query this view and the filter will be applied to the result of this query.
db.getCollection("high_value_orders").find({"status": "active"});
// this query will run on result of the view, i.e. it
// will all the active orders greater than 500
This is a very easy query, but with a complex aggregated pipeline it becomes really helpful when all the complexity is removed from the code.
Initially, we witnessed impressive performance with our views. However, as our data grew, the complexity of our aggregate pipeline led to painfully slow results. To address this, we turned to materialized views.
With MongoDB, use of joins should be avoided by modelling data correctly. Inseatd of creating references embedding document should be preferred.
Materialized views, stored on disk, revolutionized our querying experience. No longer did we endure sluggish responses; instead, results were efficiently fetched from the disk. However, a problem emerged: these views weren't self-refreshing.
When any document is updated or new documents are added, materialized views need to be refreshed. This can either be done by using triggers or having refresh logic in the application logic itself.
In the end, we chose a different path, altering application logic and data modeling to abandon views entirely.
Happy Coding 🎃