I have a really complex aggregation query, so I thought to use view as below:
db.createView("weNeed","Master",
[
{$project:
{
_id:"$_id",
documents:{
$concatArrays:[
{$ifNull:
[{$map:{
input:"$documents.COMPLETED",
as:"document",
in:{
entity:"$name",
status:"COMPLETED",
name:"$$document.name",
category:"$$document.category",
description:"$$document.description",
submittedDate:"$$document.submittedDate",
expirationDate:"$$document.expirationDate",
uri:"$$document.uri"
}
}},[]]},
{$ifNull:
[{$map:{
input:"$documents.REQUIRED",
as:"document",
in:{ entity:"$name",
status:"REQUIRED",
name:"$$document.name",
category:"$$document.category",
description:"$$document.description",
submittedDate:"$$document.submittedDate",
expirationDate:"$$document.expirationDate",
uri:"$$document.uri"
}
}},[]]},
{$ifNull:
[{$map:{
input:"$documents.DEFERRED",
as:"document",
in:{ entity:"$name",
status:"DEFERRED",
name:"$$document.name",
category:"$$document.category",
description:"$$document.description",
submittedDate:"$$document.submittedDate",
expirationDate:"$$document.expirationDate",
"uri":"$$document.uri"
}
}},[]]}
]
}
}
}
]
)
Now, I could easily use aggregation on it. Also, In java-springdata
I could easily create a matching Repository and access the data easily.Same applies to any other language or framework. This also gives a good view of what I need.
See Below query which is very concise in size:-
db.weNeed.aggregate([
{
$project:{
documents:"$documents"
}
},
{$unwind:"$documents"},
{$sort:{
"documents.entity":1,
"documents.category":1,
"documents.status":1,
"documents.name":1
}}
]
)
I tried to find if there are any performance fall backs of using views over single aggregation query. Haven't got any.
Below are some advantages of view as per me:-
Disadvantages:- This i am not sure much about. Still I think 1. Could not be good with Clustreing. 2. Could be good for people who have less knowledge of mongo and want to use any wrapper framework.
Also, there is no official documentation mentioning any advantages and disadvantages.
Please help!
A MongoDB view is a read-only queryable object whose contents are defined by an aggregation pipeline on other collections or views. MongoDB does not persist the view contents to disk. A view's content is computed on-demand when a client queries the view.
Cons: Data size in MongoDB is typically higher due to e.g. each document has field names stored it. less flexibity with querying (e.g. no JOINs) no support for transactions - certain atomic operations are supported, at a single document level.
MongoDB is a document-oriented database. It is easy to access documents by indexing. Hence, it provides fast query response. The speed of MongoDB is 100 times faster than the relational database.
I am finding views quite useless for work with any larger collection, and unfortunately that is where I live. Looks to me that the view find()
execution does not have an intelligence to integrate find()
filter object into the view, but rather runs the view by scanning the whole collection, and then attempts to filter the resulting list, resulting in slow performance.
Example:
db.createView(myView,myCol,[{stage1}..{stageN}]);
db.myView.find({myFilter});
...is MUCH slower on large myCol than:
db.myCol.aggregate([{"$match":{myFilter}},{stage1}..{stageN}])
(provided that {"$match":{myFilter}
} is a valid aggregation stage)
Dynamically integrating filter into views aggregation would actually make the view concept workable.
In terms of performance, I believe you don't get any benefit as view does not store any data. It only stores the query in system.views
. So every time you are going to access the views it will actually execute the aggregation query if you do not have a proper index on your collection then you can expect a slow response. As views don't store any data, so it can't be indexed
.
Take a look at this for some information.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With