MongoDB 3.4.1 is out and is ready for production deployment. This release contains only fixes since 3.4.0, and is a recommended upgrade for all 3.4 users.
Fixed in this release:
- SERVER-27124 Disallow readConcern:majority reads on pv0
- SERVER-27201 $graphLookup triggers null pointer dereference
- SERVER-27207 Find on view with sort through mongos may incorrectly return empty result set
- SERVER-27213 Two $match stages combine incorrectly, yielding incorrect results.
- SERVER-27300 Disallow indexing of BSONType::Symbol with a non-simple collation
- SERVER-27210 3.4.0 mongo shell unable to connect using MongoURI with "ssl=true"
- SERVER-27271 rolesInfo command raises System.InvalidOperationException : Duplicate element name 'roles'.
- SERVER-26870 Sometimes collection data file is not removed even though collection is dropped
- TOOLS-1541 Support exporting views
As always, please let us know of any issues.
-- The MongoDB Team
What’s New in MongoDB 3.4, Part 1: Multimodel Done Right
MongoDB 3.4 is now Generally Available (GA) and ready for production deployment ! MongoDB 3.4 is the latest release of the industry’s fastest growing database. It offers a major evolution in capabilities and enhancements that enable you to address emerging opportunities and use cases. This 3-part blog series aims to help you navigate everything that is new, and provides the most important resources to get you started: Part 1 covers the extended multimodel capabilities of MongoDB 3.4, including native graph processing, faceted navigation, rich real-time analytics, and powerful connectors for BI and Apache Spark. Part 2 discusses enhanced capabilities to support mission-critical applications, including geo-distributed MongoDB zones, elastic clustering, tunable consistency, and enhanced security controls. Part 3 concludes with modernized DBA and Ops tooling available in the new release. If you want to get the detail now on everything the new release offers, download the What’s New in MongoDB 3.4 white paper . Why Multimodel? Rather than the monolithic codebases of the past, today’s applications are increasingly being decomposed into loosely coupled suites of microservices, each implementing specific functionality within an application. Different services can place very different demands on the database used – from simple key-value lookups to complex analytics, aggregations, and graph traversals, through to rich search queries. Some data may need to be stored only in-memory for predictable low latency, while other data sets may need to be encrypted on disk for regulatory compliance. Data sets may vary from billions of small records, each just several KBs in size, to the management of large, multi-MB objects. To try and tame the complexity that would come from using a multitude of storage technologies, the industry is moving towards the concept of “multimodel” databases. Such designs are based on the premise of presenting multiple data models within the same platform, thereby serving diverse application requirements. However, many self-described multimodel database are little more than a collection of discrete technologies for data storage, search, and analytics, each with its own domain specific language, API and deployment requirements, and working on its own copy of the data. This approach to multimodel fails to offer much of an improvement over just running multiple independent databases, imposing high complexity, overhead, friction, and cost for developers and operations teams. MongoDB Takes a Different Approach How does MongoDB differ? MongoDB’s flexible document data model presents a superset of other database models. It allows data be represented as simple key-value pairs and flat, table-like structures, through to rich documents and objects with deeply nested arrays and sub-documents. With an expressive query language, documents can be queried in many ways – from simple lookups to creating sophisticated processing pipelines for data analytics and transformations, through to faceted search, JOINs and graph traversals. With a flexible storage architecture, application owners can deploy storage engines optimized for different workload and operational requirements. MongoDB’s approach to delivering multimodel significantly reduces developer and operational complexity, compared to running multiple, separate technologies to satisfy diverse application requirements. Users can leverage the same MongoDB query language, data model, scaling, security, and operational tooling across different applications, all within a single, integrated database platform. MongoDB 3.4 introduces new native graph processing, faceted navigation, multi-language collations, additional aggregation pipeline operators, a new decimal data type, along with enhanced connectors for BI and Apache Spark integration. Native Graph Processing Applications storing data in MongoDB frequently contain data that represents graph or tree type hierarchies. These connections can be as simple as a management reporting chain in a HR application, or as complex as multi-directional, deeply nested relationships maintained by social networks, master data management, recommendation engines, disease taxonomy, fraud detection, and more. While special purpose graph databases are effective at storing and querying graph data, it’s often desirable to store and traverse graph data directly in MongoDB. Here it can be processed, queried, and analyzed alongside all other operational data in real time, without the complexity of duplicating data across two separate databases. Graph and hierarchical data is commonly queried to uncover indirect or transitive relationships. For example, if company “A” is owned by company “B”, and “B” is owned by company “C”, then “C” indirectly owns company “A”. MongoDB 3.4 offers this functionality via a new aggregation stage called $graphLookup to recursively lookup a set of documents with a specific defined relationship to a starting document. Developers can specify the maximum depth for the recursion, and apply additional filters to only search nodes that meet specific query predicates. $graphLookup can recursively query within a single collection, or across multiple collections. Review the documentation to learn more about the MongoDB $graphLookup operator for graph processing . Faceted Navigation Faceting is a popular analytics and search capability that allows an application to group information into related categories by applying multiple filters to query results. Facets allow users to narrow their search results by selecting a facet value as a filter criteria. Facets also provide an intuitive interface to exploring a data set, and allow convenient navigation to data that is of most interest. Most databases need to execute multiple GROUP_BY statements to render facets, resulting in long running queries and poor user experience. MongoDB 3.4 introduces new aggregation pipeline stages for the bucketing, grouping and counting of one or more facets in a single round trip to the database. As a result, developers can generate richer and intuitive experiences to help users navigate complex data sets. Review the documentation to learn more about MongoDB faceted navigation . Multi-Language Collations Applications addressing global audiences require handling content that spans many languages. Each language has different rules governing the comparison and sorting of data. In order to create intuitive, localized user experiences, applications must handle non-English text with the appropriate rules for that language. For example, French has detailed rules for sorting names with accents on them. German phonebooks order words differently than the German dictionary. MongoDB 3.4 significantly expands language support capabilities to allow users to build applications that adhere to language-specific comparison rules. Support for collations – the rules governing text comparisons and sorting – has been added throughout the MongoDB Query Language and indexes for over 100 different languages and locales. Each collation can also be further customized to provide precise control over case sensitivity, numeric ordering, whitespace handling, and more. Developers can specify collation for a collection, an index, a view, or for specific operations that support collation (i.e. find, aggregate, update). You can learn more about collation in MongoDB from the documentation . Aggregation Pipeline Enhancements MongoDB developers and data engineers rely on the aggregation pipeline due to its power and flexibility in enabling sophisticated processing and manipulation demanded by real-time analytics and data transformations. MongoDB 3.4 continues to extend the aggregation pipeline by adding new capabilities within the database that simplify application-side code, as well as optimizer enhancements that improve performance. In addition to the graph and facet features described earlier, many other expressions are added in MongoDB 3.4. These expressions address string manipulation, array handling, type handling, and schema detection and transformation: String handling includes expressions for splitting and manipulating strings either in bytes or code points (a code point can represent a single component of the string, e.g, a character, emoji, or formatting instruction). Array expressions allow more sophisticated manipulation and computations on arrays, including parallel array processing. New expressions allow determining types of fields Case/switch expressions for branching Support for ISO week expressions MongoDB 3.4 also brings additional performance optimizations to the aggregation pipeline. Where possible, the query optimizer automatically moves the $match stage earlier in the pipeline, and combines it with other stages, to increase cases where indexes can be used to filter results sets. In most cases, no modifications of existing queries need to be made. You can learn more about the many MongoDB 3.4 aggregation pipeline enhancements from the documentation . Decimal Data Type Decimal128 is a 16 byte decimal floating-point number format. It is intended for calculations on decimal numbers where high levels of precision are required, such as financial (i.e. tax calculations, currency conversions) and scientific computations. Decimal128 supports 34 decimal digits of significance and an exponent range of −6143 to +6144. MongoDB 3.4 adds support for the decimal data type which represents decimal128 values. Unlike the double data type, which only stores approximations of decimal values, the decimal data type stores the exact value. For example, a decimal type ("9.99") has a precise value of 9.99, while 9.99 represented as a double would have an actual value of 9.99000000000000021316282072803, thus creating the potential for rounding errors when it is used in calculations. Decimal type values are treated like any other numeric type, and compare and sort correctly with other types based on actual numeric value. Operations on decimals are implemented in accordance with the decimal128 standard, so a value of 0.10 will retain its trailing zeros while comparing equal to 0.1, 0.10000 and so on. Review the documentation to learn more about the new MongoDB decimal data type . Visualizing MongoDB Data The MongoDB Connector for BI was introduced in November 2015. For the first time analysts, data scientists, and business users were able to seamlessly visualize semi-structured and unstructured data managed in MongoDB, alongside traditional data from their SQL databases, using the same BI tools deployed within millions of enterprises. Building on its initial release, the Connector for BI has been reengineered to improve performance, simplify installation and configuration, and support Windows. Figure 1: Uncover new insights with powerful visualizations generated from MongoDB Performance and scalability has been improved by moving more query execution down to the MongoDB processes themselves. Queries and complex aggregations are executed natively within the database, thus reducing latency and bandwidth consumption. In addition, installation and authentication has been simplified. Users now authenticate as an existing user already declared within MongoDB, no longer needing to create separate username and password credentials within the connector. The Connector for BI is part of the Advanced Analytics suite available with MongoDB Enterprise Advanced . Review the MongoDB Connector for BI documentation to learn more. MongoDB Connector for Apache Spark Following general availability in June 2016, the MongoDB Connector for Apache Spark has been updated to support the latest Spark 2.0 release. Spark 2.0 support in the connector provides access to the new SparkSession entry point, the unified DataFrame and Dataset API, enhanced SparkSQL and SparkR functionality, and the experimental Structured Streaming feature. The connector exposes all of Spark’s libraries, including Scala, Java, Python, and R. MongoDB data is materialized as DataFrames and Datasets for analysis through machine learning, graph, streaming, and SQL APIs. Already powering sophisticated analytics at organizations including China Eastern Airlines , Black Swan, and x.ai, the MongoDB Connector for Apache Spark takes advantage of MongoDB’s aggregation framework, rich queries, and secondary indexes to extract, filter, and process only the range of data it needs – for example, all customers located in a specific geography. To maximize performance across large, distributed data sets, the connector can co-locate Resilient Distributed Datasets (RDDs) with the source MongoDB node, thereby minimizing data movement across the cluster and reducing latency. You can download the MongoDB Connector for Apache Spark from GitHub, and sign up for a free Spark course from MongoDB University. Next Steps That wraps up the first part of our 3-part blog series. Remember, you can get the detail now on everything packed into the new release by downloading the What’s New in MongoDB 3.4 white paper . Alternatively, if you’d had enough of reading about it and want to get started now, then: Download MongoDB 3.4 Alternatively, spin up your own MongoDB 3.4 cluster on the MongoDB Atlas database service Sign up for our free 3.4 training from the MongoDB University
How Thoughtful Illustration Is Setting MongoDB Apart: Meet Champa Lo
I sat down with Champa Lo, Technical Illustrator based in our New York headquarters, to learn more about her role as the first full-time illustrator at MongoDB. We talked about her passion for illustration, what she does, and how she’s shaping the future of design within the company. Ashley Perez: Welcome to the team! Can you tell me about your role? Champa Lo: Sure. I joined MongoDB right before COVID-19 hit. I came into the headquarters twice for an interview but ended up being one of the first new hires who had to start at home, on top of being the first person in a brand-new role. Technical Illustration is a first for MongoDB. The company has never had an illustrator on hand. Although we have talented designers who can illustrate within a design, that’s not their main focus: the overall design is. The difference with my role is that I work specifically on illustration. I also work to define the illustration style and help create a style guide. The most important aspect of my job is building good relationships with people throughout the company. I need to understand their goals and what they’re looking for so I can tell a purely visual story. AP: How did you get into illustration? CL: I guess you can say I fell into it (at least the illustration part). I always knew I wanted to be a graphic designer early on. I was a mentee for a graphic designer in high school and absolutely fell in love with the profession. I even have a cute clipping from my senior year high school paper where I talk about my dreams of being a designer. Interview excerpt from Champa's senior-year high school newspaper After high school, I studied graphic design at the University of Colorado Denver. When I was in the design program, I always found ways to incorporate fun illustrations in my projects. A year after I graduated, I moved to New York City because there were more jobs in design there and landed a job that allowed me to put my illustrating skills to good use. My first job was working with an incredible Creative Director at a small startup who built an amazing brand using illustrations to convey the company’s goals and messages. This was a part-time job: for four hours a day, I would concentrate on illustrating bespoke email banners for marketing prompts the team created that morning. With her guidance, I saw my illustration skills grow. It showed me the possibility of being a full-time illustrator. Here’s an example of a design I did while I was there: Email banner Champa created for ThinkEco during her first job as illustrator I love to illustrate (especially this type of illustration) because I’m a designer by trade, and the core of designing is to problem-solve. Illustration is no different. As a Technical Illustrator, I simplify and visualize complicated theories and concepts. Also, it’s fun! If I’m not having fun while illustrating, I’m very unmotivated. My creativity relies on avoiding boredom. I’m always working to improve my artistic skills. I’m a lover of learning, so I subscribe to tutorial sites such as Skillshare; follow artists on YouTube who share tutorials; and subscribe to a monthly art box that sends paints, brushes, pens, and so forth so I can try new mediums. Champa's illustration for a Google Local Guides social media post AP: How do you make your illustrations purposeful, engaging, and memorable? CL: Having thoughtful conversations about the subject matter is how you get good designs and illustration. If you don’t understand the subject to the best of your ability, how can you be successful at visualizing it? In school, I was taught to always research your subject matter and not design blindly. Putting in the extra work makes a huge difference. That’s also why 1:1 meetings are so important. It’s a time for me to learn, and it’s also a creative process for the stakeholders, because they find creative ways to help me understand. GIF Champa created for a MongoDB University Page We want to understand the goal. For example, should the illustration be futuristic or nostalgic? Recently, we had a conversation about cars and how we wanted to present them for a project. We decided to design the cars as compact or electric to show MongoDB as forward thinking and environmentally conscious, because those are the kinds of people we want to hire and work with. Or take COVID-19, for instance. The pandemic has changed the way people illustrate office environments. No longer do you have teams sitting in conference rooms. Instead, you have people working at home. So, I had to think of things to illustrate such as a sofa, home desk, and desk lamp. Maybe even a dog or a child. We thought about how we could incorporate this into the Zoom interface. Before, we didn’t have to think about it. Now, Zoom can be a way to add some personality to everyone’s digital space as we work remotely. That’s what I’m here for. To have those conversations and get deeper behind the meaning of everything we create. AP: Let’s talk a little more about your role at MongoDB. What projects do you work on? CL: I’m part of the Visual Design Team, which supports the whole company. It’s fun to meet and talk to many different people at MongoDB. It gives us a lot of diversity in the projects we work on. Along with illustrations, I also work on diagrams and small animations. Projects include campaigns, web illustrations, and events. Because I’ve joined the team, we’re able to have fuller discussions about illustration. Our designers work in a fast-paced world, but my process is slower because I make more bespoke illustrations and have to talk to people to understand the technicalities so we can go beyond generic illustrations. I have to be more thoughtful of what we’re presenting to the audience. Even though by having these conversations I slow down how quickly the designers move, I'm striving to build stronger relationships on the team through this practice. Top left: Champa’s illustration for MongoDB's new multi-cloud feature. Bottom right: An illustration for MongoDB's vendors page. I have found that by showing and explaining my illustration process and inviting them into it, people seem to trust me more. For example, I always share my sketches with stakeholders before digitizing the work. My sketches aren’t perfect, but by showing them not-so-perfect work, we can build the relationship and align on ideas. My hope is that the sketches allow people to see I’m open for collaboration and conversation. Example of a project working with MongoDB's Web Design team from initial sketch through final illustration AP: How does having these conversations help your design? CL: Great question! Working with such a diversity of people and projects helps me gain an immense amount of knowledge and insight. Past conversations and concerns help inform my design decisions. I’m almost like a liaison for all these different departments, and it's nice to transfer the information so we’re all aligned. For example, I’ve been working closely with Product Marketing on diagrams, and soon I’ll be working on diagrams with a member from the Docs team, too. Each team has taken its own paths for diagrams, but I would love to eventually create a holistic style that works for all teams beyond just these two. I believe having a good process to follow leads to meaningful and engaging illustrations. However, it’s important to find balance. You can’t overengineer it, because that can easily turn unproductive and formulaic. I always want an open dialogue and strive to show there’s room to collaborate. The process we have created has been successful so far, but it’s not set in stone. Further along we can add another step, or we may find certain things aren’t needed. AP: What’s your creative vision for MongoDB? CL: My goal for illustration is that we are inclusive, diverse, and thoughtful. What I’ve seen here is a global company full of people who are very passionate and kind. As designers, we have the power to show who and what MongoDB is. For me, that’s showing off who we are. One of our company’s values is “Own What You Do.” I think it’s such an important one for designers, because we should always add our personal experiences and perspectives to our work and translate the rest of the company’s perspectives and experiences, too. For the team, my goal is to continue streamlining a process so we’re transparent and support a collaborative spirit when it comes to working with us. Champa’s illustration for the MongoDB Atlas onboarding experience My goal is to create a unified vision between our two audiences: developer and enterprise customers. My hope is the illustrations bring joy and delight, and that our audiences see MongoDB has a personality. A really effective illustration system is memorable, and our research is starting to show that our audiences are beginning to remember our visuals. This is a huge brand lift, creating a personal experience versus the cold one people may experience with other tech brands. Interested in pursuing a career at MongoDB? We have several open roles on our teams across the globe , and would love for you to build your career with us!