Visualizing your data with MongoDB Compass

Jason Ma
July 19, 2016 | Updated: August 4, 2020

Introduction

Since the inception of MongoDB, the primary interface to the database has been the mongo shell. While the shell is incredibly powerful, it can be intimidating for new users, and let's face it — there are lots of things about managing data and a database that are easier to do with a GUI.

In MongoDB 3.2 we introduced MongoDB Compass — our GUI for MongoDB. Our goal with Compass is to provide all the power of the mongo shell through an intuitive, easy to use GUI.

In this post, we'll take a closer look at MongoDB Compass and our latest release, which adds CRUD capabilities and a long list of other exciting features.

MongoDB 3.2 Introduces Compass v1.0

At MongoDB our user community is extremely important to us. Through meetups, community events, surveys, conferences — just to name a few — we collect user feedback to ensure we continue to build products that address and solve the needs of our users. Over the past couple of years, we have received an overwhelming number of requests for a schema visualizer and query builder.

With MongoDB 3.2, we answered our users with MongoDB Compass v1.0 — a GUI schema visualization tool and query builder. MongoDB Compass provides a native GUI to analyze collections and beautifully visualize your schema.

Evolution of Compass

During our beta program for Compass, we received a lot of great feedback. The three most requested features were: edit/insert/delete operations, visualization of indexes, and visualization of query performance.

In Compass v1.2, which is now in GA, we added the ability to visualize indexes and query performance.

The figure below highlights the details of indexes in a collection. Users are not only able to determine which fields are indexed, but also their type, size, usage, and properties of their indexes.

Introducing Compass v1.3

Today, we are very excited to introduce Compass v1.3, currently available in beta.

Compass v1.3 contains many new features, including:

  • Insert/edit/delete/clone documents through the GUI
  • Build and visually interact with geo/coordinate data to construct queries in a few clicks of a button
  • Visual explain plans to understand the performance of a query
  • SSH tunnels to allow users to connect securely from outside of a datacenter firewall
Let’s take a closer look at these features in a little more detail.

Edit/Insert/Delete/Clone Documents

The most requested feature in our beta program was the ability to edit/insert/delete documents. With Compass v1.3, users will be able to:
  • Modify existing documents
  • Insert new documents
  • Delete existing documents
  • Clone the schema and values of an existing document
Editing a document is simple - documents are modified through a powerful editing visualizer.

Clicking on the pencil icon puts the document in edit mode.

Once in edit mode, users can freely edit any value, field, or data type.

Deleted fields are marked in red, while new fields are highlighted in green.

Any changes made will not be sent to the server until the user confirms the edits by clicking UPDATE.

Documents can also be easily inserted into MongoDB by clicking the + INSERT button at the top of the document list.

Clicking + INSERT will open up a new window where a user can modify the contents of the document to be inserted.

Deleting documents is straightforward as well – users can click the trash icon at the top right corner of the document in the document list to delete a document.

A document can be cloned by clicking on the clone icon within the document. Compass will clone all the elements of the document, except for _id where a new _id will be generated.

A new window will appear with the cloned document that contains the same values and fields as the original. You can edit any fields or types before inserting the document.

Introducing Map and Geo Query Features

Another powerful feature for Compass v1.3 is the ability to see and understand geographical data. Geo data can be displayed on an interactive map, and drawing on the map creates a geo-query with resulting coordinate pairs displayed on the map. The map can be zoomed and panned with a click and hold of the mouse. Holding the shift key enables a circle to appear and the circle can be moved, expanded, or retracted.

The example below represents a database of Yelp restaurant reviews in Silicon Valley. Here, restaurants with 4 stars (or greater) and within a 5 mile radius of San Jose Airport are selected. Expanding or retracting the radius of the circle automatically builds a new query in the Compass command bar. In this example, applying the query returns all restaurants with 4 stars (or greater) and within a 5 mile radius of San Jose Airport.


Visualize Query Execution Performance (Explain Plans)

Compass also provides the ability to visualize explain plans. To access this feature, users navigate to the EXPLAIN PLAN tab.

Key information about the query execution plan are highlighted.

Explain plans are easier to understand in a new query plan visualization. Here a tree structure presents information on how the query performed — # documents returned, query execution time, index usage, etc. Each stage of the pipeline is shown as a node in the tree. This makes viewing explain plans in sharded clusters extremely simple.

Details of each stage of the query plan can be investigated in further detail by clicking on the DETAILS button, which provides more information about that particular stage.

Comprehensive Security

MongoDB Compass provides comprehensive enterprise grade security. Compass supports Kerberos, MongoDB-CR, SCRAM-SHA-1, LDAP based authentication, as well as x.509 certificates. SSL/TLS encrypts data transferred “over the wire” between MongoDB and the clients. Users are also now able to connect to deployments via ssh tunnel — this is useful for connecting to production clusters when outside of the data center firewall.

Connecting Compass with MongoDB Atlas

At MongoDB World 2016, we announced MongoDB Atlas, which is a database as a service. MongoDB Atlas provides all the features of the database without the heavy operational lifting. Developers no longer need to worry about provisioning, configuration, patching, upgrades, backups, and failure recovery of the database. In addition, Atlas offers elastic scalability, either by scaling up on a range of instance sizes or scaling out with automatic sharding, all with no application downtime.

Connecting Compass to Atlas is simple. You first need to find your MongoDB Atlas connection string.

From the connection string, take the hostnames, as well as your credentials and enter in the information into the Compass login screen, and just click CONNECT to login.

Benefits of Compass

MongoDB Compass addresses an important aspect in application development today as new software development trends and practices emerge. Microservices and continuous delivery continue to become more pervasive, resulting in shifts in operational culture and organizational thinking. Developer and operation teams can no longer operate in silos but must be more tightly coupled to successfully deploy new features.

MongoDB Compass addresses these evolving organizational requirements and provides many benefits ideal for modern app development:

Faster Time To Market: Modern software practices, such as DevOps, use a wide variety of different components that require teams to be well versed in many technologies. Shared insight between teams is critical to ensure multiple technologies integrate seamlessly and function as expected. Compass provides valuable insight into your data so that teams can efficiently integrate MongoDB into their IT stack, resulting in quicker prototyping and faster time to market.

Easier Project Handoffs: MongoDB’s flexible schema and and rich document structure make it easy to build applications with any data model. Though this is empowering for developers, it may be unfamiliar for new teams picking up the project. This problem can be compounded when teams are distributed. With Compass, teams can quickly visualize and understand the organization of their data and share that with other teams to minimize uncertainty during project handoffs.

Increased Productivity: GUIs provide a natural visualization tool that resonate with many users. With Compass, new users can quickly visualize the data model so they spend more time deriving value from their data, instead of working with their data.

Availability

MongoDB Compass is included with both MongoDB Professional and MongoDB Enterprise Advanced subscriptions. MongoDB Compass is free to use for evaluation and in development environments.

Next Steps:

Try it now


← Previous

Succeeding With ClangFormat, Part 2: The Big Reformat

When properly integrated into a toolchain, ClangFormat can entirely do away with time wasted on discussion and enforcement of code formatting. In part 1 of this series , I laid out the case for doing so, the factors that doomed our prior attempt, and the approach we took to get it right the next time. In this part I’ll walk through all the details that have to be considered before drawing up a functional specification and reaching the next milestone: codebase conversion. Setting the format Landing on a format was surprisingly easy, considering how contentious formatting choices can be . In this area, MongoDB has the benefit of being towards the larger end of team size. In a large shop, developers seem more understanding that "there is a way of doing things" that might not be their personal preference. But regardless of your team's size, everyone has to agree on the fundamental principle that a standard is more important that which standard. Start your initiative with obtaining buy-in, and demonstrate your commitment to solving disputes fairly, and you will find this step is not as fraught as you might expect. Assembling the bikeshed squad In most organizations, and certainly at MongoDB, the whole team cannot be involved in this decision, it is simply a waste of time and can be an emotional drain to have everyone debate the format rules. Given the almost religious fervor people have for this topic, having a large discussion group may lead to a standoff between zealots over a particularly divisive formatting topic. These standoffs can be avoided by setting ground rules for the decision-making process and conflict resolution beforehand. This can be simple as saying any disputes will be put to a vote. But whatever the rules, people must understand them ahead of time. Your format-setting squad should be composed entirely of people who are either a) implementing the formatting tool (which was my role in our ClangFormat project), or b) managing developers. We decided that some of our managers would be used as the decision committee (a total of 6 people), and we made sure they could all fit in a room if an in-person discussion was needed. Setting the tip of the spear There are a lot of presets and knobs to play with in ClangFormat, and it should fall to a single individual person to take a first pass. In our project, that was my job, so I put together a file of sample code that demonstrated various options, and sent it for code review to the bikeshed team. This allowed them to comment about aspects of the code layout they did not like, and I could then adjust the rules accordingly. For us, we were left with only two options that no clear agreement were reached on (AllowShortFunctionsOnASingleLine, and BreakConstructorInitializersBeforeComma) . For these final options, we simply put it to a formatting team-wide vote by email (and decided on Empty , and false respectively). Coping with your tool's limitations While ClangFormat has a rich set of configuration options, you may find you cannot configure it to match your existing code format. Our previous style was one such case, a hybrid of what ClangFormat calls the Google and Stroustrup styles. In particular, we had two unusual rules for formatting code that ClangFormat did not support. First, inside namespaces, we required a fixed 4-space indentation for code regardless of the number of levels of namespace nesting: namespace mongo { namespace repl { void main() { } } // namespace repl } // namespace mongo Second, we required the opening curly brace to be attached to the function definition, but the else to always start on a new line separate from the closing curly bracket: if (foo()) { } else { } Then there are the special cases where your team's unique specializations conflict with your tools assumptions about what your tokens mean. Yeah, I'm talking about macros. When are macros ever hassle-free? In our case, we have a macro named BSON that is used to build BSON documents, which uses the operator <<.(Think data-preserve-html-node="true" std::strstream paired with str() in a single macro). The << data-preserve-html-node="true" operator will be consumed by the macro pre-processor, and because we use it to delineate JSON field and value pairs, we want each line to read << "field" << "value" . But ClangFormat expects the << data-preserve-html-node="true" operator to be used in an iostreams context, and so tends to join lines such that there is only one << data-preserve-html-node="true" operator per line... which does not suit our intentions. A good example of this is found in this bug report : +++ @@ -921,10 +921,14 @@ /** A complex _id expression. */ class ComplexId : public CheckResultsBase { std::deque<Document> inputData() { - return {DOC("a" << "de" - << "b" << "ad" - << "c" << "beef" - << "d" << ""), + return {DOC("a" + << "de" + << "b" + << "ad" + << "c" + << "beef" + << "d" + << ""), DOC("a" << "d" << "b" We experimented with customizing ClangFormat to match our existing rules. The ClangFormat code was easy to work with, but ultimately, the ongoing cost of maintaining a fork is not worth the effort to match our old format. Instead, we adapted our existing rules to match what ClangFormat was already capable of. We strongly recommend that you do the same. There are several other examples of this mismatch between automated tooling and developer expectation; see SERVER-19670 and SERVER-19184 . If a developer is truly unhappy with the final formatting done by ClangFormat, the tool provides a way to disable formatting , but in practice, we find developers would rather let ClangFormat format the code, even when they don’t love the results. As of today, there are only 11 cases in our code base ( here’s one example ) where we stepped in and disabled formatting for small blocks of code. Given there are thousands of files in our codebase, I’d call that a strong endorsement of ClangFormat’s capabilities. ClangFormat pragmatics ClangFormat ships with several defaults for format including ones based on the Google C++ Style Guide, the Linux kernel, and Stroustrup’s style. (BSD’s Kernel Normal Form is not available in 3.6, but will be available in 3.8.) Using a base style is far easier than deciding on each option one by one, but if you have an existing style to match, as we did, you’ll need to start tuning. For that, .clang-format and ClangFormat configurator are your friends. These tools allow you to tune options one by one while observing how they affect your code. The wrapper script In any non-trivial use of clang-format , you will want a wrapper around it. Our script, clang_format.py : Fetches clang-format binaries, from LLVM when it can, and from a MongoDB cache when it cannot Validates clang-format is at the right version when binaries are already present Skips files that we shouldn’t bother formatting, i.e. 3rd party library code, like boost Offers modes for both validating and updating Manages parallel invocations of clang-format to increase throughput Existing code The next big decision is what to do about the existing code: Do you leave it as is? If you reformat it, do you do it all in one fell swoop? Format-only changes The majority of developers I know believe that the best practice, in day-to-day development, is not to make format-only changes to existing code. They clutter the repository log, and can be disruptive to the use of tools like “git blame” and “hg annotate”, which cannot reliably differentiate between changes to a file that only involve formatting changes versus substantive changes to the code. While these tools can be told to ignore some whitespace changes, they are confused by other changes (like joining or splitting lines). The downside to this policy is it inevitably creates a code base with different styles across and even within files, as the code formatting style for a code base evolves, and as multiple people work in a code base. And if a tool is rolled out, then to prevent every subsequent checkin from containing a ton of format-only changes, there must be some rule or rules for which files the tool should be applied to and which ones to exclude. This partial application just creates more work without delivering the full benefit, and we decided to just do one big reformat of the code base. While useful code history is an important issue, a big reformat is not very disruptive to history if it occurs infrequently (e.g. once a year or less), and is applied to the entire code base at that time. If you do it that way, users can easy navigate over these reformat changes in their history navigating tool. The func spec The end product of all of this work should be a document every bit as polished and binding as any artifact your team produces for the development of features. For us, this is a functional spec . In it, we detailed the goals and non-goals of the project, the changes to the official formatting guidelines that resulted from the planning phases, and our implementation plan for the big reformat. It also included everything a developer would need to obtain the tools, and instructions for following the new development workflow using them. Flag day Once you decide to reformat all the code (and we strongly recommend this), the next step is to plan for the actual big commit of the reformat. We call this “flag day” -- the day you plant a flag in the ground. It is best to do this on a weekend if you can, when freezing the entire codebase will be the least disruptive. Tell your entire team about this weeks in advance, and keep reminding them about it! (We planned ours for the weekend just after the beginning of a sprint iteration.) Of course, flag day isn’t the first time you reformat the entire codebase, it’s just the first time you commit the results back. During the exploration phase of this project, you will doubtless reformat your codebase many times over as you fine tune, and as you converge on a func spec, you should also be validating that the results are passing tests. By the time flag day arrives, you should have already done a full reformat and completely validated the results for shipping code, at least once. All the preparation proved itself worth the effort for us, and our flag day reformat went smoothly and without incident.. With that said, there were things we could have done better. And as I said in part 1, the difference between success and failure in this endeavor isn’t doing it once, but building it into your workflow so that rot does not set in.. I’ll talk more about those in the concluding part of this series , so stay tuned.

July 15, 2016
Next →

MongoDB and Partners: Building the AI Future, Together

If you’re like me, over the past year you’ve closely watched AI’s developments—and the world’s reactions to them. From infectious excitement about AI’s capabilities, to impatience with its cost and return on investment, every day has been filled with AI twists and turns. It’s been quite the roller coaster. During the ride, from time to time I’ve wondered where AI falls on the Gartner hype cycle, which gives "a view of how a technology or application will evolve over time." Have we hit the "peak of inflated expectations" only to fall into the "trough of disillusionment?" Or is the hype cycle an imperfect guide, as The Economist argues? The reality is that it takes time for any new technology—even transformative ones like AI—to take hold. And every advance, no matter how big, has had its detractors. A famous example is that of Picasso (!), who in 1968 said, “Computers are useless. They can only give you answers.” (!!) For our part, MongoDB is convinced that AI is a once-in-a-generation technology that will enhance every future application—a belief that has been reinforced by the incredible work our partners have shared at MongoDB’s 2024 events. Speeding AI development MongoDB is committed to helping organizations of all sizes succeed with AI, and one way we’re doing that is by collaborating with the MongoDB partner ecosystem to create powerful, user-friendly AI development tools and solutions. For example, Fireworks.ai —which is a member of the MongoDB AI Applications Program ecosystem —created an inference solution that hosts gen AI models and supports containerized deployments. This tool makes it easier for developers to build and deploy powerful applications with a range of easy-to-use tools and customization options. They can choose to use state-of-the-art, open-source language, image, and multimodal foundation models off the shelf, or they can customize and fine-tune models to their needs. Jointly, Fireworks.ai and MongoDB provide a solution for developers who want to leverage highly curated and optimized open-source models and combine these with their organization’s own proprietary data—and to do so with unparalleled speed and security. “MongoDB is one of the most sophisticated database providers, and it’s very easy to use,” said Benny Chen , cofounder of Fireworks.ai. "We want developers to be able to use these tools, and we want to work with providers who enable and empower developers." Nomic , another MAAP ecosystem member, also enables developers with best-in-class solutions across the entire unstructured data workflow. Their Embed offering, available through the Nomic API , allows users to vectorize large-scale datasets for use in text, image, and multimodal retrieval applications, including retrieval-augmented generation (RAG), using only their web browser. The Nomic-MongoDB solution is a highly efficient, open-weight model that developers can use to visualize the unstructured datasets they store in MongoDB Atlas . These insights help users quickly discover trends and articulate data-driven value propositions. Nomic also supported the recently announced vector quantization in MongoDB Atlas Vector Search , which reduces vector sizes while preserving performance. Last—but hardly least!—there’s our new reference architecture with MAAP partners AWS and Anthropic. Announced at MongoDB.local London , the reference architecture supports building memory-enhanced AI agents, and is designed to streamline complex processes and develop smarter, more responsive applications. For more—including a link to the code on Github— check out the MongoDB Developer Center . Making AI work for anyone and everyone The companies MongoDB partners with aren’t just making gen AI easier for developers—they’re building tools for everyone. For example, Capgemini has invested $2 billion in gen AI and is training 100,000 of its employees in the technology. GenYoda, a solution that helps insurance professionals with their daily work, is a product of this investment. GenYoda leverages MongoDB Atlas Vector Search to analyze large amounts of customer data, like policy statements, premiums, claims history, and health information. Using GenYoda, insurance professionals can quickly analyze underwriters’ reports to make informed decisions, create longitudinal health summaries, and streamline customer interactions to improve contact center efficiency. GenYoda can ingest 100,000 documents in just a few hours and respond to users’ queries in two to three seconds—a metric on par with the most widely used gen AI models. And it produces results: in one example, by using Capgemini’s solution an insurer was able to increase productivity by 15%, add new reports 25% faster (thus speeding decision-making), and reduce the manual effort of searching PDFs, increasing efficiency by 10%. Building the future of AI together So, what’s next? Honestly, I’m as curious as you are. But I’m also incredibly excited. At MongoDB, we’re active participants in the AI revolution, working to embrace the possibilities that lie ahead. The future of gen AI is bright, and I can’t wait to see what we’ll build together. To learn more about how MongoDB can accelerate your AI journey, explore the MongoDB AI Applications Program .

November 4, 2024