Millis runtime is 0 - MongoDB

Question

I used two NOSQL databases, MongoDB and Neo4j , to process the same information. I want to compare performance using the first and second db. I discussed my problem with MongoDB on this issue : millis runtime was always 0. So I added about 250 documents to my collection, but without any success: / p>

> db.team.find({common_name:"Milan"},{_id:0, "stadium.name":1}).explain("executionStats") { "queryPlanner" : { "plannerVersion" : 1, "namespace" : "Progettino.team", "indexFilterSet" : false, "parsedQuery" : { "common_name" : { "$eq" : "Milan" } }, "winningPlan" : { "stage" : "PROJECTION", "transformBy" : { "_id" : 0, "stadium.name" : 1 }, "inputStage" : { "stage" : "COLLSCAN", "filter" : { "common_name" : { "$eq" : "Milan" } }, "direction" : "forward" } }, "rejectedPlans" : [ ] }, "executionStats" : { "executionSuccess" : true, "nReturned" : 1, "executionTimeMillis" : 0, "totalKeysExamined" : 0, "totalDocsExamined" : 253, "executionStages" : { "stage" : "PROJECTION", "nReturned" : 1, "executionTimeMillisEstimate" : 0, "works" : 255, "advanced" : 1, "needTime" : 253, "needFetch" : 0, "saveState" : 0, "restoreState" : 0, "isEOF" : 1, "invalidates" : 0, "transformBy" : { "_id" : 0, "stadium.name" : 1 }, "inputStage" : { "stage" : "COLLSCAN", "filter" : { "common_name" : { "$eq" : "Milan" } }, "nReturned" : 1, "executionTimeMillisEstimate" : 0, "works" : 255, "advanced" : 1, "needTime" : 253, "needFetch" : 0, "saveState" : 0, "restoreState" : 0, "isEOF" : 1, "invalidates" : 0, "direction" : "forward", "docsExamined" : 255 } } } 

For example, in MongoDB, this query will work better than in Neo4j, because I used a denormalized model to represent information about the stadium teams. In fact, in Neo4j this request takes 50 ms, as you can see:

So what can I do to have runtime information in MongoDB? I have some problems if the millis runtime is always 0, because I cannot show different performance on the same queries with two different NoSQL databases.

Answer 1

As stated in your other question I answered. Your collection is too small. here is the result that I get from a database with more than 3 thousand positions. Please note that my execution of TimeInMillis is only 2 milliseconds. You will need a lot more data to make the mango really a perversion. saying 10K plus records depending on the size of your device.

 { "queryPlanner" : { "plannerVersion" : 1, "namespace" : "arenas.arenas", "indexFilterSet" : false, "parsedQuery" : { "$and" : [] }, "winningPlan" : { "stage" : "COLLSCAN", "filter" : { "$and" : [] }, "direction" : "forward" }, "rejectedPlans" : [] }, "executionStats" : { "executionSuccess" : true, "nReturned" : 3718, "executionTimeMillis" : 2, "totalKeysExamined" : 0, "totalDocsExamined" : 3718, "executionStages" : { "stage" : "COLLSCAN", "filter" : { "$and" : [] }, "nReturned" : 3718, "executionTimeMillisEstimate" : 0, "works" : 3724, "advanced" : 3718, "needTime" : 1, "needFetch" : 4, "saveState" : 31, "restoreState" : 31, "isEOF" : 1, "invalidates" : 0, "direction" : "forward", "docsExamined" : 3718 }, "allPlansExecution" : [] } 

}

Answer 2

I'm not sure if comparing a denormalized Mongo DB is true unless you talk about creating a special use case where you will never create complexity on top of what you have.

However, you might want to familiarize yourself with the PROFILE and EXPLAIN commands in Neo4j cypher (assuming you are using version 2.2.x). This will help you understand what Neo4j does.

I expect that one thing you will want to do if you have not already done so is to create an index in the _id property of the _id label as follows:

 CREATE INDEX ON :Team(_id) 

If this is a unique property, you probably want to create a constraint (which automatically creates an index for you):

 CREATE CONSTRAINT ON (n:Team) ASSERT n._id IS UNIQUE 

If you do this, then the n1 node in your MATCH will be able to use the index to navigate to the node (s) on the disk that you care about, and then make several transitions between the PLAYS relationships to get these other nodes.

I also agreed that you should try to test with a lot of data;)