×

Welcome to Knowledge Base!

KB at your finger tips

This is one stop global knowledge base where you can learn about all the products, solutions and support features.

Categories
All
Database-MongoDB
Avoid Unbounded Arrays — MongoDB Cloud Manager

Avoid Unbounded Arrays¶

On this page

  • Overview
  • Example
  • Learn More

Overview¶

One of the benefits of MongoDB’s rich schema model is the ability to store arrays as document field values. Storing arrays as field values allows you to model one-to-many or many-to-many relationships in a single document, instead of across separate collections as you might in a relational database.

However, you should exercise caution if you are consistently adding elements to arrays in your documents. If you do not limit the number of elements in an array, your documents may grow to an unpredictable size. As an array continues to grow, reading and building indexes on that array gradually decrease in performance. A large, growing array can strain application resources and put your documents at risk of exceeding the BSON Document Size limit.

Instead, consider bounding your arrays to improve performance and keep your documents a manageable size.

Example¶

Consider the following schema for a publishers collection:

// publishers collection
{
  "_id": "orielly"
  "name": "O'Reilly Media",
  "founded": 1980,
  "location": "CA",
  "books": [
    {
      "_id": 123456789,
      "title": "MongoDB: The Definitive Guide",
      "author": [ "Kristina Chodorow", "Mike Dirolf" ],
      "published_date": ISODate("2010-09-24"),
      "pages": 216,
      "language": "English"
    },
    {
      "_id": 234567890,
      "title": "50 Tips and Tricks for MongoDB Developer",
      "author": "Kristina Chodorow",
      "published_date": ISODate("2011-05-06"),
      "pages": 68,
      "language": "English"
    }
  ]
}

In this scenario, the books array is unbounded . Each new book released by this publishing company adds a new sub-document to the books array. As publishing companies continue to release books, the documents will eventually grow very large and cause a disproportionate amount of memory strain on the application.

To avoid mutable, unbounded arrays, separate the publishers collection into two collections, one for publishers and one for books . Instead of embedding the entire book document in the publishers document, include a reference to the publisher inside of the book document:

// publishers collection
{
  "_id": "oreilly"
  "name": "O'Reilly Media",
  "founded": 1980,
  "location": "CA"
}
// books collection
{
  "_id": 123456789,
  "title": "MongoDB: The Definitive Guide",
  "author": [ "Kristina Chodorow", "Mike Dirolf" ],
  "published_date": ISODate("2010-09-24"),
  "pages": 216,
  "language": "English",
  "publisher_id": "oreilly"
}

{
  "_id": 234567890,
  "title": "50 Tips and Tricks for MongoDB Developer",
  "author": "Kristina Chodorow",
  "published_date": ISODate("2011-05-06"),
  "pages": 68,
  "language": "English",
  "publisher_id": "oreilly"
}

This updated schema removes the unbounded array in the publishers collection and places a reference to the publisher in each book document using the publisher_id field. This ensures that each document has a manageable size, and there is no risk of a document field growing abnormally large.

Document References May Require $lookups

This approach works especially well if your application loads the book and publisher information separately. If your application requires the book and information together, it needs to perform a $lookup operation to join the data from the publishers and books collections. $lookup operations are not very performant, but in this scenario may be worth the trade off to avoid unbounded arrays.

Learn More¶

  • To learn more about Data Modeling in MongoDB and the flexible schema model, see Data Modeling Introduction.
  • To learn how to model relationships with document references, see Model One-to-Many Relationships with Document References
  • To learn how to query arrays in MongoDB, see Query an Array.
  • MongoDB also offers a free MongoDB University Course on Data Modeling: M320: Data Modeling.

MongoDB.live 2020 Presentations¶

To learn how to incorporate the flexible data model into your schema, see the following presentations from MongoDB.live 2020 :

  • Learn about entity relationships in MongoDB and examples of their implementations with Data Modeling with MongoDB.
  • Learn advanced data modeling design patterns you can incorporate into your schema with Advanced Schema Design Patterns.
Read article
Configure the Slow Query Threshold — MongoDB Cloud Manager

Configure the Slow Query Threshold¶

The Performance Advisor recognizes a query as slow if it takes longer to execute than the value of slowOpThresholdMs. By default, this value is 100 milliseconds. You can change the threshold with either the profile command or the db.setProfilingLevel() mongosh method.

Example

The following profile command example sets the threshold at 200 milliseconds:

db.runCommand({
  profile: 0,
  slowOpThresholdMs: 200
})

If you are running MongoDB 3.6 or later, you can customize the percentage of slow queries in your logs used by the Performance Advisor by specifying the sampleRate parameter.

Example

This sets the slow query threshold to a lower value of 100 milliseconds but also sets the sample rate to 10%.

db.runCommand({
  profile: 0,
  slowOpThresholdMs: 100,
  sampleRate: 0.1
})

Note

By default, the value of profile is 0 . MongoDB recommends leaving this value unchanged since other values can negatively impact database performance. To learn more, see the profile command.

Read article
Manage the MongoDB Agent Functions — MongoDB Cloud Manager

Manage the MongoDB Agent Functions¶

On this page

  • Manage Backup Function
    • Activate Backup
    • Deactivate Backup
  • Manage Monitoring Function
    • Activate Monitoring
    • Deactivate Monitoring
  • Manage Automation Function
    • Activate Automation

Manage Backup Function¶

Activate Backup¶

  1. From your Context menu, click the project that has the hosts you want to configure.

  2. Click Deployments .

  3. Click Servers .

  4. On the host where you want to activate Backup, click ellipsis icon .

  5. Click Activate Backup .

  6. From the banner, click Review & Deploy .

  7. If you want to activate Backup, click Confirm & Deploy . Otherwise click Cancel , then Discard Changes to cancel activating Backup.

    Note

    Only one host can backup a deployment at a time. On the Server tab, the host that is backing up the deployment displays Backup - active . Any other host with Backup activated displays Backup - standby .

Deactivate Backup¶

  1. From your Context menu, click the project that has the hosts you want to configure.
  2. Click Deployments .
  3. Click Servers .
  4. On the host where you want to deactivate Backup, click ellipsis icon .
  5. Click Deactivate Backup .
  6. From the banner, click Review & Deploy .
  7. If you want to activate Backup, click Confirm & Deploy . Otherwise click Cancel , then Discard Changes to cancel deactivating Backup.

Manage Monitoring Function¶

Activate Monitoring¶

  1. From your Context menu, click the project that has the hosts you want to configure.

  2. Click Deployments .

  3. Click Servers .

  4. On the host where you want to activate Monitoring, click ellipsis icon .

  5. Click Activate Monitoring .

  6. From the banner, click Review & Deploy .

  7. If you want to activate Monitoring, click Confirm & Deploy . Otherwise click Cancel , then Discard Changes to cancel activating Monitoring.

    Note

    Only one host can monitor a deployment at a time. On the Server tab, the host that is monitoring the deployment displays Monitoring - active . Any other host with Monitoring activated displays Monitoring - standby .

Multiple Monitoring Agents

You can activate Monitoring on multiple MongoDB Agents to distribute monitoring assignments and provide failover. Cloud Manager distributes monitoring assignments among up to 100 running MongoDB Agents. Each MongoDB Agent running active Monitoring monitors a different set of MongoDB processes. One MongoDB Agent running active Monitoring per project is the primary Monitor. The primary Monitor reports the cluster’s status to Cloud Manager. As MongoDB Agents have Monitoring enabled or disabled, Cloud Manager redistributes assignments. If the primary Monitor fails, Cloud Manager assigns another MongoDB Agent running active Monitoring to be the primary Monitor.

If you run more than 100 MongoDB Agents with active Monitoring, the additional MongoDB Agents run as standby MongoDB Agents. A standby MongoDB Agent is idle, except to log its status as a standby and periodically ask Cloud Manager if it should begin monitoring.

If you install multiple Monitoring Agents, ensure that all the MongoDB Agents with active Monitoring can reach all the mongod processes in the deployment.

To activate Monitoring on multiple MongoDB Agents, repeat the activation process on multiple MongoDB Agents.

Deactivate Monitoring¶

  1. From your Context menu, click the project that has the hosts you want to configure.
  2. Click Deployments .
  3. Click Servers .
  4. On the host where you want to deactivate Monitoring, click ellipsis icon .
  5. Click Deactivate Monitoring .
  6. From the banner, click Review & Deploy .
  7. If you want to deactivate Monitoring, click Confirm & Deploy . Otherwise click Cancel , then Discard Changes to cancel activating Monitoring.

Manage Automation Function¶

Activate Automation¶

Automation is activated when you:

  • Deploy a standalone MongoDB instance
  • Deploy a replica set
  • Deploy a sharded cluster
  • Import an existing MongoDB deployment into Cloud Manager.
Read article
Rotate Automation Password — MongoDB Cloud Manager

Rotate Automation Password¶

On this page

  • Prerequisites
  • Procedure

We recommend that you rotate the automation user’s password periodically. Cloud Manager provides an automated procedure for password rotation with no downtime.

Prerequisites¶

To enable password rotation for the automation user, you must meet the following requirement:

  • SCRAM-SHA-1 or SCRAM-SHA-256 set up as a supported authentication mechanism for the Automation.

Procedure¶

1
2

On the line for the automation user, click Rotate Password

3

Click Review & Deploy to review your changes.¶

4

Click Confirm & Deploy to deploy your changes.¶

Otherwise, click Cancel and you can make additional changes.

Read article
Aggregation Pipeline Builder — MongoDB Cloud Manager

Aggregation Pipeline Builder¶

On this page

  • Required Roles
  • Access the Aggregation Pipeline Builder
  • Create an Aggregation Pipeline
  • Export an Aggregation Pipeline to Driver Language
  • Aggregation Pipeline Settings

The Data Explorer provides an aggregation pipeline builder to process your data. Aggregation pipelines transform your documents into aggregated results based on selected pipeline stages.

The MongoDB Atlas aggregation pipeline builder is primarily designed for building pipelines, rather than executing them. The pipeline builder provides an easy way to export your pipeline to execute in a driver.

To interact with data in the Cloud Manager UI:

  1. Click Deployment in the left navigation.
  2. Select the desired MongoDB deployment.
  3. Select the Data tab.

Required Roles¶

To create and execute aggregation pipelines in the Data Explorer , you must have been granted at least the Project Data Access Read Only role.

To utilize the $out stage in your pipeline, you must have been granted at least the Project Data Access Read/Write role.

Access the Aggregation Pipeline Builder¶

1

Select the database for the collection.¶

The main panel and Namespaces on the left side list the collections in the database.

2

Select the collection on the left-hand side or in the main panel.¶

The main panel displays the Find , Indexes , and Aggregation views.

3

Select the Aggregation view.¶

When you first open the Aggregation view, the Data Explorer displays an empty aggregation pipeline.

Create an Aggregation Pipeline¶

1

Select an aggregation stage.¶

Select an aggregation stage from the Select dropdown in the bottom-left panel.

The toggle to the right of the dropdown dictates whether the stage is enabled.

2

Fill in your aggregation stage.¶

Fill in your stage with the appropriate values. If Comment Mode is enabled, the pipeline builder provides syntactic guidelines for your selected stage.

As you modify your stage, the Data Explorer updates the preview documents on the right based on the results of the current stage.

3

Add additional stages to your pipeline as desired.¶

There are two ways to add additional stages to your pipeline:

  • Click the Add Stage button at the bottom of the pipeline to add a new stage at the end of your pipeline:
  • Click the plus icon button on a stage to add a new stage directly after the stage where the button was clicked.
Screenshot highlighting add stage button.

To delete a pipeline stage, click the trash icon icon on the desired stage.

4

Repeat steps 1 and 2 for each additional stage.¶

Collation¶

Use collation to specify language-specific rules for string comparison, such as rules for lettercase and accent marks.

To specify a collation document, click Collation at the top of the pipeline builder.

A collation document has the following fields:

{
   locale: <string>,
   caseLevel: <boolean>,
   caseFirst: <string>,
   strength: <int>,
   numericOrdering: <boolean>,
   alternate: <string>,
   maxVariable: <string>,
   backwards: <boolean>
}

The locale field is mandatory; all other collation fields are optional. For descriptions of the fields, see Collation Document.

Import an Aggregation Pipeline from Text¶

You can import aggregation pipelines from plain text into the pipeline builder to easily modify and verify your pipelines.

To import a pipeline from plain text:

1

Open the New Pipeline from Text dialog.¶

  1. Click the arrow next to the plus icon at the top of the pipeline builder.

  2. Click New Pipeline from Text .

2

Type or paste your pipeline in the dialog.¶

Your pipeline must match the syntax of the pipeline parameter of the db.collection.aggregate() method.

3

Click Create New

4

Click Confirm in the ensuing dialog.¶

Reset Your Pipeline¶

To return your pipeline to the initial blank state, click the plus icon at the top of the pipeline builder.

Export an Aggregation Pipeline to Driver Language¶

You can use the aggregation pipeline builder to export your finished pipeline to one of the supported driver languages; Java, Node, C#, and Python 3. Use this feature to format and export pipelines for use in your applications.

To export your aggregation pipeline:

1

Construct an aggregation pipeline.¶

For instructions on creating an aggregation pipeline, see Create an Aggregation Pipeline .

2

Click Export to Language at the top of the pipeline builder.¶

3

Select your desired export language.¶

In the Export Pipeline To dropdown, select your desired language.

The My Pipeline pane on the left displays your pipeline in mongosh syntax.

The pane on the right displays your pipeline in the selected language.

4

Include import statements, if desired.¶

(Optional) : Check the Include Import Statements option to include the required import statements for the language selected.

5

Click the Copy button.¶

Click the Copy button at the top-right of the pipeline to copy the pipeline for the selected language to your clipboard. You can now integrate your pipeline into your application.

6

Click Close to return to the aggregation pipeline builder.¶

Aggregation Pipeline Settings¶

To modify the aggregation pipeline builder settings:

1

Click the settings icon icon at the top-right of the pipeline builder.¶

Screenshot highlighting pipeline settings button.
2

Modify pipeline settings as desired.¶

You can modify the following settings:

Setting Description Default
Comment Mode

When enabled, the Data Explorer adds helper comments to each stage.

Note

Changing this setting only affects new stages and does not modify stages which have already been added to your pipeline.

On
Number of Preview Documents Number of documents to show in the preview for each stage. 20
3

Click Apply to save your changes.¶

Read article
MongoDB Agent — MongoDB Cloud Manager

MongoDB Agent¶

Before the introduction of the MongoDB Agent, each function – Automation, Backup, and Monitoring – ran as a separate agent binary in your project.

The MongoDB Agent runs as a single binary that can perform any – or all – of the three functions depending upon what you need.

  • Activate the monitoring and/or backup functions using Cloud Manager UI.
  • Activate automation when you create a new cluster or import an existing one.
MongoDB Agent Prerequisites
Configure MongoDB Agent prerequisites.
Install MongoDB Agent
Install the MongoDB Agent.
Update to the MongoDB Agent
Update the MongoDB Agent.
Restart the MongoDB Agent
Restart the MongoDB Agent.
Manage the MongoDB Agent Functions
Activate or deactivate all functions of the MongoDB Agent.
MongoDB Agent Settings
Find all possible settings available in the MongoDB Agent configuration file.
Required Access for MongoDB Agent
Details the permissions required for MongoDB Agent to use with MongoDB instances that enforce access control.
Configure the MongoDB Agent for Access Control
If MongoDB uses Access Control, create a MongoDB user for the MongoDB Agent to use to authenticate and to determine the Agent’s access.
Configure MongoDB Agent to Use TLS
Configure the MongoDB Agent for TLS.
Configure How the MongoDB Agent Manages Config Files and Passwords
Configure how the MongoDB Agent stores its configuration and manages its passwords.
Remove Legacy Agents
Remove the legacy Backup and Monitoring Agents.
View Agent Status
View the status of a project’s agents.
Manage Agent API Keys
Manage project’s agent API keys.
Read article
Get All Projects in an Organization — MongoDB Cloud Manager

Get All Projects in an Organization¶

On this page

  • Resource
  • Request Parameters
    • Request Path Parameters
    • Request Query Parameters
    • Request Body Parameters
  • Response
    • Response Document
    • results Embedded Document
  • Example Request
  • Example Response
    • Response Header
    • Response Body

Base URL: https://cloud.mongodb.com/api/public/v1.0

Resource¶

GET /orgs/{ORG-ID}/groups

Request Parameters¶

Request Path Parameters¶

Path Element Type Description
ORG-ID Required. The unique identifier for the organization whose information you want to retrieve.

Request Query Parameters¶

The following query parameters are optional:

Name Type Description Default
pageNum integer Page number (1-based). 1
itemsPerPage integer Number of items to return per page, up to a maximum of 500. 100
pretty boolean Displays response in a prettyprint format. false
envelope boolean Specifies whether or not to wrap the response in an envelope . false
name string

Human-readable label of the project to use to filter the returned list. Performs a case-insensitive search for a project, which is prefixed by the specified name , within the organization.

Example

If you specify a name query parameter of project1 , Cloud Manager returns the project named project1 , but would not return a project named project123 .

None

Request Body Parameters¶

This endpoint doesn’t use HTTP request body parameters.

Response¶

Response Document¶

The response JSON document includes an array of result objects, an array of link objects and a count of the total number of result objects retrieved.

Name Type Description
results array Array includes one object for each item detailed in the results Embedded Document section.
links array Array includes one or more links to sub-resources and/or related resources. The relations between URL s are explained in the Web Linking Specification .
totalCount number Integer count of the total number of items in the result set. It may be greater than the number of objects in the results array if the entire result set is paginated.

results Embedded Document¶

Each result is one project.

Name Type Description
activeAgentCount integer The number of active monitoring, automation, and Backups in the project.
hostCounts Document Describes the host types and number of each host type for the cluster.
hostCounts.arbiter integer The number of arbiter hosts in the cluster.
hostCounts.config integer The number of sharded cluster configuration server hosts in the cluster.
hostCounts.master integer The number of master hosts in the cluster.
hostCounts.mongos integer The number of mongos hosts in the cluster.
hostCounts.primary integer The number of primary hosts in the cluster.
hostCounts.secondary integer The number of secondary hosts in the cluster.
hostCounts.slave integer The number of slave hosts in the cluster.
id string The unique identifier for the project.
links object array One or more links to sub-resources and/or related resources. All links arrays in responses include at least one link called self . The relationships between URL s are explained in the Web Linking Specification .
name string The name of the cluster.
orgId string The unique identifier for the parent organization of the project.
publicApiEnabled boolean The status of API access to the cluster.
replicaSetCount integer The number of replica sets in the cluster.
shardCount integer The number of shards in the cluster.

Example Request¶

curl --user "{username:apiKey}" \
  --include \
  --header "Content-Type: application/json" \
  --digest GET "https://cloud.mongodb.com/api/public/v1.0/orgs/{ORG-ID}/groups"

Example Response¶

Response Header¶

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=ISO-8859-1
Date: {dateInUnixFormat}
WWW-Authenticate: Digest realm="MMS Public API", domain="", nonce="{nonce}", algorithm=MD5, op="auth", stale=false
Content-Length: {requestLengthInBytes}
Connection: keep-alive
HTTP/1.1 200 OK
Vary: Accept-Encoding
Content-Type: application/json
Strict-Transport-Security: max-age=300
Date: {dateInUnixFormat}
Connection: keep-alive
Content-Length: {requestLengthInBytes}
X-MongoDB-Service-Version: gitHash={gitHash}; versionString={ApplicationVersion}

Response Body¶

{
  "links": [{

  }],
  "results": [{
      "activeAgentCount": 0,
      "hostCounts": {
        "arbiter": 0,
        "config": 0,
        "master": 0,
        "mongos": 0,
        "primary": 1,
        "secondary": 2,
        "slave": 0
      },
      "id": "{PROJECT-ID}",
      "links": [{

      }],
      "name": "Production Cluster",
      "orgId": "{ORG-ID}",
      "publicApiEnabled": true,
      "replicaSetCount": 1,
      "shardCount": 0
    },
    {
      "activeAgentCount": 0,
      "hostCounts": {
        "arbiter": 0,
        "config": 0,
        "master": 0,
        "mongos": 0,
        "primary": 1,
        "secondary": 2,
        "slave": 0
      },
      "id": "{PROJECT-ID}",
      "lastActiveAgent": "2017-10-26T02:39:59Z",
      "links": [{

      }],
      "name": "Staging Cluster",
      "orgId": "{ORG-ID}",
      "publicApiEnabled": true,
      "replicaSetCount": 1,
      "shardCount": 0
    }
  ],
  "totalCount": 2
}
Read article
Monitor and Improve Slow Queries — MongoDB Cloud Manager

Monitor and Improve Slow Queries¶

On this page

  • Enable or Disable Performance Advisor for a Project
  • Common Reasons for Slow Queries
  • Index Considerations
  • Access Performance Advisor
  • Index Suggestions
  • Create Suggested Indexes

Note

This feature is available only with Cloud Manager Premium, which comes with certain MongoDB subscriptions. Contact MongoDB for more information.

The Performance Advisor monitors any operation with a query predicate that MongoDB considers slow and suggests new indexes to improve query performance. For the selected host and time period, the Performance Advisor evaluates up to the 20,000 most recent slow queries found in the logs.

Recommended indexes are accompanied by sample queries, grouped by query shape , that were run against a collection that would benefit from the suggested index. The Performance Advisor does not negatively affect the performance of your Cloud Manager clusters.

Note

To view the Performance Advisor, you must:

  • Be a Cloud Premium user.
  • Run MongoDB version 3.2 or later on your cluster.

  • Manage your cluster with MongoDB Agent Automation.

    To learn more about the MongoDB Agent, see MongoDB Agent .

To view the field values in the example queries, you must be a Cloud Manager user with one or more of the following roles:

  • Project Owner
  • Project Data Access Admin
  • Project Data Access Read/Write
  • Project Data Access Read Only

Users without the aforementioned roles cannot see the field values.

Enable or Disable Performance Advisor for a Project¶

Required Privileges

To enable Performance Advisor for a project, you must have the Project Owner role for the project.

Performance Advisor is enabled by default. To disable or enable Performance Advisor:

1

In the left navigation, click Settings under the Project section.¶

2

Toggle the button next to Performance Advisor and Profiler

Common Reasons for Slow Queries¶

If a query is slow, common reasons include:

  • The query is unsupported by your current indexes.
  • Some documents in your collection have large array fields that are costly to search and index.
  • One query retrieves information from multiple collections with $lookup.

Index Considerations¶

Indexes improve read performance, but a large number of indexes can negatively impact write performance since indexes must be updated during writes. If your collection already has several indexes, consider this tradeoff of read and write performance when deciding whether to create new indexes. Examine whether a query for such a collection can be modified to take advantage of existing indexes, as well as whether a query occurs often enough to justify the cost of a new index.

The Performance Advisor can help identify and remove unnecessary indexes. To learn more, see Review Drop Index Recommendations .

Access Performance Advisor¶

To access the Performance Advisor :

1

Click Deployment

2

Click the replica set where the collection resides.¶

If the replica set resides in a sharded cluster, first click the sharded cluster containing the replica set.

3

Click Performance Advisor

4

Select a collection from the Collections dropdown.¶

5

Select a time period from the Time Range dropdown.¶

The Performance Advisor displays up to 20 query shapes across all collections in the cluster and suggested indexes for those shapes. The Performance Advisor ranks the indexes according to their Impact , which indicates High or Medium based on the total wasted bytes read. To learn more about index ranking, see Review Index Ranking .

Note

If the slow query log contains consecutive $match stages in the aggregation pipeline, the two stages can coalesce into the first $match stage and result in a single $match stage. As a result, the query shape in the Performance Advisor might differ from the actual query you ran.

Index Suggestions¶

The Performance Advisor ranks the indexes that it suggests according to their Impact , which indicates High or Medium based on the total wasted bytes read. To learn more about how the Performance Advisor ranks indexes, see Review Index Ranking .

To learn how to create indexes that the Performance Advisor suggests, see Create Suggested Indexes .

Index Metrics¶

Each index that the Performance Advisor suggests contains the following metrics. These metrics apply specifically to queries which would be improved by the index:

Metric Description
Execution Count Number of queries executed per hour which would be improved.
Average Execution Time Current average execution time in milliseconds for affected queries.
Average Query Targeting Average number of documents read per document returned by affected queries. A higher query targeting score indicates a greater degree of inefficiency. For more information on query targeting, see Query Targeting .
In Memory Sort Current number of affected queries per hour that needed to be sorted in memory.
Average Docs Scanned Average number of documents scanned.
Average Docs Returned Average number of documents returned.
Avgerage Object Size Average object size.

Sample Queries¶

For each suggested index, the Performance Advisor shows the most commonly executed query shapes that the index would improve. For each query shape, the Performance Advisor displays the following metrics:

Metric Description
Execution Count Number of queries executed per hour which match the query shape.
Average Execution Time Average execution time in milliseconds for queries which match the query shape.
Average Query Targeting Average number of documents read for every document returned by matching queries. A higher query targeting score indicates a greater degree of inefficiency. For more information on query targeting, see Query Targeting .
Average Docs Scanned Average number of documents scanned.
Average Docs Returned Average number of documents returned.

The Performance Advisor also shows each executed sample query that matches the query shape, with specific metrics for that query.

Query Targeting¶

Each index suggestion includes an Average Query Targeting score indicating how many documents were read for every document returned for the index’s corresponding query shapes. A score of 1 represents very efficient query shapes because every document read matched the query and was returned with the query results. All suggested indexes represent an opportunity to improve query performance.

Filter Index Suggestions¶

By default, the Performance Advisor suggests indexes for all clusters in the deployment. To only show suggested indexes from a specific collection, use the Collection dropdown at the top of the Performance Advisor.

You can also adjust the time range the Performance Advisor takes into account when suggesting indexes by using the Time Range dropdown at the top of the Performance Advisor.

Limitations of Index Suggestions¶

Timestamp Format for Indexes¶

The Performance Advisor can’t suggest indexes for MongoDB databases configured to use the ctime timestamp format. As a workaround, set the timestamp format for such databases to either iso8601-utc or iso8601-local.

Log Size¶

The Performance Advisor analyzes up to 200,000 of your cluster’s most recent log lines.

Create Suggested Indexes¶

You can create indexes suggested by the Performance Advisor directly within the Performance Advisor itself. When you create indexes, keep the ratio of reads to writes on the target collection in mind. Indexes come with a performance cost, but are more than worth the cost for frequent queries on large data sets. To learn more about indexing strategies, see Indexing Strategies.

Behavior¶

  • You can only create one index at a time through the Performance Advisor. If you want to create more simultaneously, you can do so using Data Explorer or the shell
  • Cloud Manager always creates indexes at the top level of the deployment. If you create an index while viewing the Performance Advisor for a single shard in a sharded cluster, Cloud Manager creates that index for the entire sharded cluster.

Procedure¶

To create a suggested index:

1

For the index you want to create, click Create Index

The Performance Advisor opens the Create Index dialog and prepopulates the Fields based on the index you selected.

2

(Optional) Specify the index options.¶

{ <option1>: <value1>, ... }

Example

The following options document specifies the unique option and the name for the index:

{ unique: true, name: "myUniqueIndex" }
3

(Optional) Set the Collation options.¶

Use collation to specify language-specific rules for string comparison, such as rules for lettercase and accent marks. The collation document contains a locale field which indicates the ICU Locale code, and may contain other fields to define collation behavior.

Example

The following collation option document specifies a locale value of fr for a French language collation:

{ "locale": "fr" }

To review the list of locales that MongoDB collation supports, see the list of languages and locales . To learn more about collation options, including which are enabled by default for each locale, see Collation in the MongoDB manual.

4

(Optional) Enable building indexes in a rolling fashion.¶

Warning

Due to critical issue SERVER-68925, Cloud Manager deployments using certain versions of the MongoDB Agent should not perform automated rolling index builds on clusters running the following MongoDB versions:

  • MongoDB 4.2.19-4.2.22
  • MongoDB 4.4.13-4.4.16
  • MongoDB 5.0.6-5.0.11
  • MongoDB 6.0.0-6.0.1

You can continue to perform manual rolling index builds safely on your clusters. To perform automated rolling index builds safely, upgrade the MongoDB Agent to 12.4.0.7703 or later or upgrade your clusters to:

  • MongoDB 4.2.23 or later
  • MongoDB 4.4.17 or later
  • MongoDB 5.0.12 or later
  • MongoDB 6.0.2 or later

Important

Rolling index builds succeed only when they meet certain conditions. To ensure your index build succeeds, avoid the following design patterns that commonly trigger a restart loop:

  • Index key exceeds the index key limit
  • Index name already exists
  • Index on more than one array field
  • Index on collection that has the maximum number of text indexes
  • Text index on collection that has the maximum number of text indexes

Note

Data Explorer doesn’t support building indexes in a rolling fashion for standalone deployments.

Building indexes in a rolling fashion reduces the performance impact of building indexes on replica sets and sharded clusters . To maintain cluster availability, Cloud Manager removes one node from the cluster at a time starting with a secondary .

After you build an index in a rolling fashion, if your MongoDB database runs with an FCV less than 4.2 , resync the head database to ensure that the head database takes the new index into account.

Cloud Manager automatically cancels rolling index builds that don’t succeed on all nodes. When a rolling index build completes on some nodes, but fails on others, Cloud Manager cancels the build and removes the index from any nodes that it was successfully built on.

In the event of a rolling index build cancellation, Cloud Manager generates an activity feed event and sends a notification email to the project owner with the following information:

  • Name of the cluster on which the rolling index build failed
  • Namespace on which the rolling index build failed
  • Project that contains the cluster and namespace
  • Organization that contains the project
  • Link to the activity feed event

To learn more about rebuilding indexes, see Build Indexes on Replica Sets .

Note

The following index options are incompatible with building indexes in a rolling fashion:

  • unique
  • storageEngine
  • textIndexVersion
  • 2dsphereIndexVersion

Cloud Manager ignores these options if you specify them in the Options pane.

5

Click Review

6

In the Confirm Operation dialog, confirm your index.¶

Important

When an index build completes, Cloud Manager generates an activity feed event and sends a notification email to the project owner with the following information:

  • Completion date of the index build
  • Name of the cluster on which the index build completed
  • Namespace on which the index build completed
  • Project containing the cluster and namespace
  • Organization containing the project
  • Link to the activity feed event
Read article
Frequently Asked Questions — MongoDB Cloud Manager

Frequently Asked Questions¶

This document addresses common questions about Cloud Manager and its use.

Project Administration
Find answers to common questions about how to administer Cloud Manager users, organizations, and projects.
Automation
Find answers to common questions about automating the deployment of MongoDB instances.
Backup and Restore
Find answers to common questions about backing up and restoring MongoDB databases and collections with Cloud Manager.
Billing
Find answers to common questions about Cloud Manager billing.
Monitoring and Alerts
Find answers to common questions about monitoring your MongoDB instances with Cloud Manager and how Cloud Manager alerts you about issues.
MongoDB Agent
Find answers to common questions about how Cloud Manager uses a new, single Agent.
MongoDB 3.2 Automation End of Life
Find answers to common questions about how you can mitigate the impact of the end Cloud Manager Automation support for MongoDB 3.2.
MongoDB 3.4 Automation End of Life
Find answers to common questions about the end of Cloud Manager Automation support for MongoDB 3.4.
Read article
Provision Servers for Automation — MongoDB Cloud Manager

Provision Servers for Automation¶

On this page

  • Overview
  • Procedure
  • Next Steps

Overview¶

Cloud Manager can automate operations for the MongoDB processes running on your hosts. Cloud Manager can both discover existing processes and deploy new ones.

Cloud Manager Automation relies on an Automation Agent, which must be installed on every server that runs a monitored MongoDB deployment. The Automation Agents periodically poll Cloud Manager to determine the goal configuration, deploy changes as needed, and report deployment status back to Cloud Manager.

Procedure¶

Install the MongoDB Agent on each host that you want Cloud Manager to manage. The following procedure applies to all operating systems.

Instructions for a specific operating system can be read on Install MongoDB Agent .

On Linux hosts, if you installed MongoDB with a package manager, use the same package manager to install the MongoDB Agent. If you installed MongoDB without a package manager, use an archive to install the MongoDB Agent.

Next Steps¶

Once you have installed the MongoDB Agent to all your hosts, you can deploy your first replica set , cluster , or standalone .

Read article

Still Thinking?
Give us a try!

We embrace agility in everything we do.
Our onboarding process is both simple and meaningful.
We can't wait to welcome you on AiDOOS!