Why does MongoDB show slower performance than MySQL? - mongodb

Question

My system config : OSx RAM:-8GB ,2.5 Gz i5
Both database table has 1 mill rows and same data . I am executing same aggregate query at both database.
db.temp.aggregate([
{ "$match": { ITEMTYPE: 'like' } },
{ "$group" : {_id :{ cust_id2: "$ActorID", cust_id: "$ITEMTYPE"}, numberofActorID : {"$sum" : 1}}},
{ "$sort": { numberofActorID: -1 } },
{ "$limit" : 5 }
]);
I had created covering index
db.temp.ensureIndex( { "ITEMTYPE": 1, "ActorID": 1 } );
and selectivity of "like" is 80%
Time Results are
sqlWithout sqlWithIndex mongoWithout mongoWithIndex
958 644 3043 4243
I didn't upgrade system parameter(not even sharding) of MongoDB
Please suggest me why mongoDB is slow and how i can improve this problem.
{
"stages" : [
{
"$cursor" : {
"query" : {
"ITEMTYPE" : "like"
},
"fields" : {
"ActorID" : 1,
"ITEMTYPE" : 1,
"_id" : 0
},
"plan" : {
"cursor" : "BtreeCursor ",
"isMultiKey" : false,
"scanAndOrder" : false,
"indexBounds" : {
"ITEMTYPE" : [
[
"like",
"like"
]
],
"ActorID" : [
[
{
"$minElement" : 1
},
{
"$maxElement" : 1
}
]
]
},
"allPlans" : [
{
"cursor" : "BtreeCursor ",
"isMultiKey" : false,
"scanAndOrder" : false,
"indexBounds" : {
"ITEMTYPE" : [
[
"like",
"like"
]
],
"ActorID" : [
[
{
"$minElement" : 1
},
{
"$maxElement" : 1
}
]
]
}
}
]
}
}
},
{
"$group" : {
"_id" : {
"cust_id2" : "$ActorID",
"cust_id" : "$ITEMTYPE"
},
"numberofActorID" : {
"$sum" : {
"$const" : 1
}
}
}
},
{
"$sort" : {
"sortKey" : {
"numberofActorID" : -1
},
"limit" : NumberLong(5)
}
}
],
"ok" : 1
}
Structure of JSON
{ "_id" : ObjectId("5492ba51ff16cd9391a2c02d"), "POSTDBID" : 231041, "ITEMID" : 231041, "ITEMTYPE" : "post", "ITEMCREATIONDATE" : ISODate("2009-02-28T20:37:02Z"), "POSVal" : 0.327282, "NEGVal" : 0.315738, "NEUVal" : 0.356981, "LabelSentiment" : "Neutral", "ActorID" : NumberLong(1179444542), "QuarterLabel" : "2009-1\r", "rowid" : 2 }

Answer 1

Note: Some of the things I mention are simplified for the sake of this answer. However, to the best of my knowledge, they can be applied as described.
Misconceptions
First of all: aggregations can't utilize covered queries:
Even when the pipeline uses an index, aggregation still requires access to the actual documents; i.e. indexes cannot fully cover an aggregation pipeline.
(see the Aggregation documentation for details.)
Second: Aggregations are not meant to be used as real time queries
The aggregation pipeline provides an alternative to map-reduce and may be the preferred solution for aggregation tasks where the complexity of map-reduce may be unwarranted.
You would not want to use map/reduce for real time processing, would you? ;) While sometimes aggregations can be so fast that they can be used as real time queries, it is not the intended purpose. Aggregations are meant for precalculation of statistics, if you will.
Improvements on the aggregation
You might want to use a $project phase right after the match to reduce the data passed into the group phase to that what is processed there:
{ $project: { 'ActorID':1, 'ITEMTYPE':1 } }
This might improve the processing.
Hardware impact
As for your description, I assume you use some sort of MacBook. OSX and the program's you have running require quite some RAM. MongoDB, on the other hand, tries to keep as much of it's indices and the so called working set (most recently accessed documents, to keep it simple) in RAM. It is designed that way. It is supposed to run on one or more dedicated instances. You might want to use MMS to check wether you have a high number of page faults – which I'd expect. MySQL is much more conservative and less dependent on free RAM, although it will be outperformed by MongoDB when a certain amount of ressources is available (conceptually, because the two DBMS are very hard to compare reasonably), simply because it is not optimized for dealing with situations when a lot of RAM is available. We don't even touch resource competition between various processes here, which is a known performance killer for MongoDB, too.
Second, in case you have a spinning disk: MongoDB has – for various reasons – sub par read performance on spinning disks, the main problem being seek latency. Usually, the disks in MacBooks do 5400rpm, which further increases seek latency, worsening the problem, and making it a real pain in the neck for aggregations, which – as shown - access a lot of documents. The way the MongoDB storage engine works, two documents which follow each other in an index might well be saved at two entirely different locations, even in different data files. ( This is because MongoDB is heavily write optimized, so documents are written at the first position providing enough space for the document and it's padding. ) So depending on the number of documents in your collection, you can have a lot of disk seeks.
MySQL, on the other hand, is rather read optimized.
Data modelling
You did not show us your data model, but sometimes small changes in the model have a huge impact on performance. I'd suggest doing a peer review of the data model.
Conclusion
You are comparing two DBMS, which are designed and optimized for diametrical use cases on an environment which is pretty much the opposite of that for what one of these systems was specifically designed in a use case for which it wasn't optimized, expecting real time results from a tool which isn't made for that. That's might be the reasons why MongoDB is outperformed by MySQL. Side note: you didn't show us the corresponding (My)SQL query.