M201 MongoDB Performance

In this lab you're going to use the equality, sort, range rule to determine which index best supports a given query. Given the following query: db.accounts.find( { accountBalance : { $gte : NumberDecimal(100000.00) }, city: "New York" } ) .sort( { lastName: 1, firstName: 1 } ) Which of the following indexes best supports this query with regards to the equality, sort, range rule. Choose the best answer. Answer: As per  the equality, sort, range rule below is the best option:

In this lab you're going to determine which index was used to satisfy a query given its explain output. The following query was ran: > var exp = db.restaurants.explain("executionStats") > exp.find({ "address.state": "NY", stars: { $gt: 3, $lt: 4 } }).sort({ name: 1 }).hint(REDACTED) Which resulted in the following output: { "queryPlanner": { "plannerVersion": 1, "namespace": "m201.restaurants", "indexFilterSet": false, "parsedQuery": "REDACTED", "winningPlan": { "stage": "SORT", "sortPattern": { "name": 1 }, "inputStage": { "stage": "SORT_KEY_GENERATOR", "inputStage": { "stage": "FETCH", "inputStage": { "stage": "IXSCAN", &

In this lab you're going to examine several example queries and determine which compound index will best service them. > db.people.find ({ "address.state" : "Nebraska" , "last_name" : /^G/, "job" : "Police officer" }) > db.people.find ({ "job" : /^P/, "first_name" : /^C/, "address.state" : "Indiana" }) .sort ({ "last_name" : 1 }) > db.people.find ({ "address.state" : "Connecticut" , "birthday" : { " $ gte" : ISODate ( "2010-01-01T00:00:00.000Z" ) , " $ lt" : ISODate ( "2011-01-01T00:00:00.000Z" ) } }) If you had to build one index on the people collection, which of the following indexes would best sevice all 3 queries? Choose the best answer. Answer: { "address.state": 1, "job": 1 } - No - As this can able t

In this lab you're going to determine which queries are able to successfully use a given index for both filtering and sorting. Given the following index: {"first_name": 1, "address.state": -1, "address.city": -1, "ssn": 1} Which of the following queries are able to use it for both filtering and sorting? Check all that apply: Answer: db.people.find({ "first_name": { $gt: "J" } }).sort({ "address.city": -1 }) - No - This query doesn't use equality on the index prefix. When using an index for filtering and sorting the query must include equality conditions on all the prefix keys that precede the sort keys. Moreover, on the sort predicate it skipped the next key in the prefix "address.state". db.people.find({ "first_name": "Jessica" }).sort({ "address.state": 1, "address.city": 1 }) - Yes . This query matches with equality on the query predicate wit

For this optional lab you're going to install MongoDB Compass 1.5. This lab is optional because Compass doesn't currently support all Linux distributions. While Compass, like MongoDB Enterprise, Compass is available as part of the MongoDB Enterprise Advanced subscription it's permitted to be ran outside of production environments. In order to install Compass you're going to need to head over to the MongoDB Download Center. From there the installation should be fairly straightforward. Once you've successfully installed Compass answer the question below: Did you download and install Compass? Answer: Yes Installed Compass.

Welcome to your first lab in M201! In this lab you're going to install MongoDB Enterprise 3.4 and import the people dataset. While MongoDB Enterprise is available as part of the MongoDB Enterprise Advanced subscription it's permitted to be ran outside of production environments. In order to install MongoDB you're going to need to head over to our online documentation and follow the instructions on installing MongoDB. After you've successfully installed MongoDB you should start a standalone server. Once your sever is up and running you should be able to download the people.json handout and import it with mongoimport. Make sure to import the documents into the m201 database and the people collection. To confirm that you've successfully completed these steps run the following query on the m201 database from the mongo shell and paste it's output into the submission area below: > db.people.count({ "email" : {"$exists": 1} }) Answer

Given the following indexes: { categories: 1, price: 1 } { in_stock: 1, price: 1, name: 1 } The following documents: { price: 2.99, name: "Soap", in_stock: true, categories: ['Beauty', 'Personal Care'] } { price: 7.99, name: "Knife", in_stock: false, categories: ['Outdoors'] } And the following queries: db.products.find({ in_stock: true, price: { $gt: 1, $lt: 5 }  }).sort({  name: 1 }) db.products.find({ in_stock: true }) db.products.find({ categories: 'Beauty'  }).sort({  price: 1 }) Whic h of  following is/are true? Answer: Index #1 would provide a sort to query #3. - True Index #2 properly uses the equality, sort, range rule for query #1. - False - If we were to build an index for query #1 using the equality, sort, range rule, then the index would be: { in_stock: 1, name: 1, price: 1 }. There would be a total of 4 index keys created across all of these documents and indexes. - False - As there would be 5 to

Whic h of  following statements  is/are true? Answer: An index doesn't become multikey until a document is inserted that has an array value - True Running performance tests from the mongo shell is an acceptable way to benchmark your database - False . Performance tests should be as close to production environment as possible. The mongo shell is designed for administrative tasks and ah-hoc queries, not performance benchmarks. You'd also be running in a single thread, which is unlikely how you'd be operating in production. You can use the --wiredTigerDirectoryForIndexes option to place your indexes on a different disk than your data - True Indexes can only be traversed forward - False - Indexes can traverse both forward as well as backward. The ideal ratio between nReturned and totalKeysExamined is 1 - True.

Whic h of  following statements  is/are true? Answer: Compound indexes can service queries that filter on any subset of the index keys - No , not all subsets of a index's keys can service a query. The prefix of an index's keys can service a query. Compound indexes can service queries that filter on a prefix of the index keys - Yes . If no indexes can be used then a collection scan will be necessary - Yes. Query plans are evicted from the plan cache on index creation, destruction, or server restart - Yes . By default, the explain() command will execute your query - No , by default explain() will not execute your query. This is useful to test queries that need to run on a server under heavy load. Passing "executionStats" or "allPlansExecution" will execute the query and collect execution statistics.

Whic h of  following statements  is/are true? Answer: Indexes can solve the problem of slow queries - True Indexes are fast to search because they're ordered such that you can find target values with few comparisons - True Under heavy write load you should scale your read throughput by reading from secondaries - Fals e  since writes are replicated to secondaries all members of the replica set have about the same write workload therefore sending reads to a secondary will not scale you read throughput. When you index on a field that is an array it creates a partial index - False since  when you index a field that is an array it creates a multikey index. On a sharded cluster, aggregation queries using $lookup will require a merge stage on a random shard - False .  $lookup, $graphLookup, $facet, and $out all require a merge stage on the primary shard, not a random shard like most other merged queries.

Which of the following statements is/are true? Answer: MongoDB indexes are markov trees. -  No as   MongoDB indexes are designed using B-trees. By default, all MongoDB user-created collections have an _id index. - Yes Background index builds block all reads and writes to the database that holds the collection being indexed - No ,  as foreground index builds block all reads and writes to the database that holds the collection being indexed. Background index builds don't have this limitation, but are generally slower than foreground index builds. It's common practice to co-locate your mongos on the same machine as your application to reduce latency -  Yes Collations can be used to create case insensitive indexes -  Yes

Which of the following statements is/are true? Answer: All of the following statements are true Indexes can decrease insert throughput. Partial indexes can be used to reduce the size requirements of the indexes. It's important to ensure that secondaries with indexes that differ from the primary not be eligible to become primary. Indexes can be walked backwards by inverting their keys in a sort predicate. It's important to ensure that your shard key has high cardinality.

M201 MongoDB Performance Chapter-1 Introduction to MongoDB Performance Lab 1.1: Install Course Dependencies Lab 1.2: Install MongoDB Compass Chapter – 2 MongoDB Indexes Lab 2.1: Using Indexes to Sort Lab 2.2: Optimizing Compound Indexes Chapter – 3 Index Operations Lab 3.1: Explain Output Chapter 4: CURD Optimization Lab 4.1 – Equality, Sort, Range Chapter 5: Performance on Clusters Final Exam Question 1 Question 2 Question 3 Question 4 Question 5 Question 6 Question 7

Which of these statements is/are true? Answer: You can index multiple array fields in a single document with a single compound index - False   Multikey indexes allow us to index on array fields, but they do not support indexes on multiple array fields on single documents. Covered queries can sometimes still require some of your documents to be examined - False A query is covered if and only if it can be satisfied using the keys of the index. Write concern has no impact on write latency - False Different write concerns can certainly impact your write latency. Write concerns that only need acknowledgment from a primary are generally faster than ones that need acknowledgment from a majority of replica set members. Creating an ascending index on a monotonically increasing value creates index keys on the right-hand side of the index tree - True A collection scan has a logarithmic search time - False No, collection scans have a  linear  search time.