You can set profiling level to log slow queries, this will help you in narrowing down the queries that need improvement. You can set the profiler on and off, using setProfilingLevel, this will start logging query stats in system.profile collection which you can query to get various results.Ģ2. Range field: field on which queries perform a range test.Īnd this should be the order in your index:Ģ1. Sort field: field on which queries will specify a sort. Keep this in mind while building an index.Įquality field: field on which queries will perform an equality test. The explain feature of MongoDB will help you a lot with understanding how queries run. If you always sort your result-set by some field, then think of how you can include that field into the index, so that your queries become faster.Īn example: you are sorting a student record by grade, in such a case we can include the grade field in the index itself.
The better your indexes the better will be your queries. hint() function at end of a query to specify which index to use. As number of classes would be relatively less you should use the class_id index. If you do a query like – where student_id greater than 50 and class_id = 1, the query execution will take greate amount of time if it uses the student_id and class_id index. Selectivity of an index: Take an example of an index created by student_id and class_id and another index on only class_id.Īssuming students can be in large numbers. Make your indexes carefully, think through your query requirements.ĥ. But slows down the writes as the indexes have to be updated.Ĭ. It uses compression so takes up lesser space.ī.
An update is a new entry instead of an actual update.Ĭ. Based on memory management provided by OSī. There are two storage engines for MongoDB MMAP(Deprecated as of 4.0) and WiredTiger.Ī. Duplicate and redundant data is another concern depending on use case.Īs a side note, you can u se GridFS if you want to store blob data which is larger than 16mb. If your documents are large in number(and/or size) another way would be to keep an array of _ids in both the collections.Īdvantage of embedding data is low disk latency(faster reads) and atomicity.ĭisadvantage would be if the embedded data grows, you might hit the 16mb limit and might need to de-fragment data. If the collections are going to be smaller then you can choose to embed one into the other i.e both documents have embedded documents of related data.įor example: Books-Authors, would be a smaller data-set so could be embedded into both the documents.
So in this case put the city:_id in the people document.Ī Student/Teacher or Book/Author would be examples of such relationships. In such a case usually go for separate collections and put id of the smaller collection in larger one. Take example of a city having many people. – Embedded document isn’t updated/accessed or used frequently, As this will lead to fetching unnecessary data into memory. – The size of document may become greater than 16mb by embedding.
So in a way you can do without need of having transactions, as the data is already embedded in a single document instead of being in multiple tables like a relational DBMS. Operation on a single document is always atomic. Here is an example(image from MongoDB website):ģ.
From the relational DBMS world you can say, it is when you put a related entity(document) inside another. Only in special cases where the data size of a document may go over 16mb limit per document imposed by underlying engine, that you have to make separate collection for such data. MongoDB doesn’t have joins to you have to embed such data into the document itself. With MongoDB you think of what queries your application needs answer for, and build a schema around those queries.Ģ. Instead, with MongoDB, we do it based on the what type of queries or data would be related to each other according to our application’s needs. Unlike relational DB schema, we don’t build an agnostic schema, which is normalized so that any type of access pattern is usually supported(maybe after 20 joins, inner queries, co-related queries!). The schema design of MongoDB is based on the access pattern of the application. MongoDB is pitched as schema-less, but that doesn’t mean that there is no need to think through how data should be placed within the collections.įollowing pointers can assist you in building your next DB design:ġ. With any database management system, one of the crucial aspect is the architecture of the database. In continuation to MongoDB refresher, listing down the next major items to look into once you understand the operational aspects MongoDB.