We’re excited to announce MongoDB.local Seattle! Join us on February 15 for a one-day educational conference to learn best practices for building and deploying your giant ideas.
With 20+ technical sessions, jumpstarts, and tutorials, you’ll be able to customize your agenda based on interest and experience level. Our engineers will cover topics including application architecture, schema design, microservices, analytics, performance, and more. Check out top sessions like Using Change Streams to Keep Up with Your Data and Spark and Machine Learning.
Curious about what’s new in MongoDB 3.6? Want to get the details on MongoDB Stitch? You won’t want to miss the keynote from MongoDB’s CTO & Co-Founder Eliot Horowitz. You can also get your specific questions answered by scheduling one-on-one consulting with a MongoDB engineer.
We’ll have breakfast, lunch, and coffee to keep you fueled throughout the day. And the swag. . .it wouldn’t be a MongoDB event without swag.
MongoDB.local Seattle is our biggest Pacific Northwest event this year. Register today to learn MongoDB best practices from the experts and connect with the fastest growing database community.
Date: February 15, 2018
Time: 8:00am - 5:00pm
Location: Bell Harbor International Conference Center
2211 Alaskan Way Seattle, WA
What’s New in MongoDB 3.6. Part 1 – Speed to Develop
MongoDB 3.6 is now Generally Available (GA), and ready for production deployment. In this short blog series, I’ll be taking you on a whirlwind tour of what’s new in this latest release: Today, we’ll take a look at the new capabilities designed specifically to help developers build apps faster. We’ll take a look at change streams, retryable writes, developer tools, and fully expressive array manipulation In part 2 , we’ll dive into the world of DevOps and distributed systems management, exploring Ops Manager, schema governance, and compression Part 3 will cover what’s new for developers, data scientists, and business analysts with the new SQL-based Connector for BI, richer in-database analytics and aggregations, and the new recommended driver for R In our final part 4 , we’ll look at all of the new goodness in our MongoDB Atlas fully managed database service available on AWS, Azure, and GCP, including cross-region replication for globally distributed clusters, auto-scaling, and more. If you want to get the detail now on everything the new release offers, download the Guide to what’s New in MongoDB 3.6 . Developer-First MongoDB has always been a developer-first technology. Its document data model maps naturally to objects in application code, making it simple for developers to learn and use. A document’s schema can be dynamically created and modified without downtime, making it fast to build and evolve applications. Native, idiomatic drivers are provided for 10+ languages – and the community has built dozens more – enabling ad-hoc queries, real-time aggregation and rich indexing to provide powerful programmatic ways to access and analyze data of any structure. MongoDB 3.6 builds upon these core capabilities to allow developers to create rich apps and customer experiences, all with less code. Change Streams Change streams enable developers to build reactive, real-time, web, mobile, and IoT apps that can view, filter, and act on data changes as they occur in the database. Change streams enable seamless data movement across distributed database and application estates, making it simple to stream data changes and trigger actions wherever they are needed, using a fully reactive programming style. Implemented as an API on top of MongoDB’s operation log ( oplog ), consumers can open change streams against collections and filter on relevant events using the $match, $project, and $redact aggregation pipeline stages . The application can register for notifications whenever a document or collection is modified, enabling downstream applications and consumers to act on new data in real time, without constantly querying the entire collection to identify changes. Applications can consume change streams directly, via a message queue, or through a backend service such as MongoDB Stitch (coming soon). Use cases enabled by MongoDB change streams include: Powering trading applications that need to be updated in real time as stock prices rise and fall. Synchronizing updates across serverless and microservices architectures by triggering an API call when a document is inserted or modified. For example, new customer orders written to the database may automatically trigger functions to generate invoices and delivery schedules. Updating dashboards, analytics systems, and search engines as operational data changes. Creating powerful IoT data pipelines that can react whenever the state of physical objects change. For example, generating alarms whenever a connected vehicle moves outside of a geo-fenced area. Pushing new credit card transactions into machine learning training models to re-score fraud classifications. Refreshing scoreboards in multiplayer games. Figure 1: MongoDB change streams enable consumers to react to data changes in real time Some MongoDB users requiring real-time notifications have built their own change data capture processes that “tail” the oplog. By migrating to change streams, these users can reduce development and operational overhead, improve usability, and increase data reliability. When compared to both oplog tailing and change notifications implemented by alternative databases, MongoDB change streams offer a number of advantages: Change streams are flexible – users can register to receive just the individual deltas from changes to a document, or receive a copy of the full document. Change streams are consistent – by utilizing a global logical clock, change streams ensure a total ordering of event notifications across shards. As a result, MongoDB guarantees the order of changes will be preserved, and can be safely processed by the consuming application in the order received from the stream. Change streams are secure – users are able to create change streams only on collections to which they have been granted read access. Change streams are reliable – notifications are only sent on majority committed write operations, and are durable when nodes or the network fails. Change streams are resumable – when nodes recover after a failure, change streams can be automatically resumed, assuming that the last event received by the application has not rolled off the oplog. Change streams are familiar – the API syntax takes advantage of the established MongoDB drivers and query language, and are independent of the underlying oplog format. Change streams are highly concurrent – up to 1,000 change streams can be opened against each MongoDB instance with minimal performance degradation. Review the MongoDB change streams documentation to learn more. Retryable Writes The addition of retryable writes to MongoDB moves the complexity of handling temporary system failures from the application to the database. Now, rather than the developer having to implement custom, client-side code, the MongoDB driver can automatically retry writes in the event of transient network failures or a primary replica election, while the MongoDB server enforces exactly-once processing semantics. By assigning a unique transaction identifier to each write operation, the driver re-sends that ID to enable the server to evaluate success of the previous write attempt, or retry the write operation as needed. This implementation of retryable writes offers a number of benefits over approaches taken by other databases: Retryable writes are not limited to idempotent operations only. They can also be applied to operations such as incrementing or decrementing a counter, or processing orders against stock inventory. Retryable writes are safe for operations that failed to acknowledge success back to the application due to timeout exceptions, for example due to a transient network failure. Retryable writes do not require developers to add any extra code to their applications, such as retry logic or savepoints. Applications that cannot afford any loss of write availability, such as e-commerce applications, trading exchanges, and IoT sensor data ingestion, immediately benefit from retryable writes. When coupled with self-healing node recovery – typically within 2-seconds or less – MongoDB’s retryable writes enable developers to deliver always-on, global availability of write operations, without the risks of data loss and stale reads imposed by eventually consistent, multi-master systems. Tunable Consistency With tunable consistency, MongoDB affords developers precise control over routing queries across a distributed cluster, balancing data consistency guarantees with performance requirements. MongoDB 3.4 added linearizable reads, which were central to MongoDB passing Jepsen – some of the most stringent data safety and correctness tests in the database industry. Now the MongoDB 3.6 release introduces support for causal consistency – guaranteeing that every read operation within a client session will always see the previous write operation, regardless of which replica is serving the request. By enforcing strict, causal ordering of operations within a session, causal consistency ensures every read is always logically consistent, enabling monotonic reads from a distributed system – guarantees that cannot be met by most multi-node databases. Causal consistency allows developers to maintain the benefits of strict data consistency enforced by legacy single node relational databases, while modernizing their infrastructure to take advantage of the scalability and availability benefits of modern distributed data platforms. Developer Tooling: MongoDB Compass As the GUI for MongoDB, Compass has become an indispensable tool for developers and DBAs, enabling graphical schema discovery and query optimization. Compass now offers several new features: Auto-complete : Enables developers to simplify query development with Compass providing suggestions for field names and MongoDB operators, in addition to matching braces and quotes as they code. Query History : Allows developers to re-run their most recently executed queries, and save common queries to run on-demand. Table View : Now developers can view documents as conventional tables, as well as JSON documents. MongoDB Compass is not just a single tool – it’s a framework built to allow for the addition of modular components. Compass now exposes this as the Compass Plugin Framework , making Compass extensible by any user with the same methods used by MongoDB’s software engineers. Using the plugin API, users can build plugins to add new features to Compass. Examples include a GridFS viewer, a sample data generator, a hardware stats viewer, a log collector/analyzer, and more. You can learn more about these new features in the MongoDB Compass documentation . MongoDB Compass Community With the MongoDB 3.6 release, the Compass family has expanded to now include the new, no-cost Compass Community edition. Compass Community provides developers an intuitive visual interface to use alongside the MongoDB shell. It includes the core features of Compass, enabling users to review the hierarchy and size of databases and collections, inspect documents, and insert / update / delete documents. Developers can use the GUI to build queries, examine how they’re executed, and add or drop indexes to improve performance. Compass Community also supports the latest Compass functionality available with MongoDB 3.6, making developers even more productive. Figure 2: MongoDB Compass Community, new no-cost GUI for MongoDB developers MongoDB Compass Community is available from the MongoDB download center . Fully Expressive Array Updates Arrays are a powerful construct in MongoDB’s document data model, allowing developers to represent complex objects in a single document that can be efficiently retrieved in one call to the database. Before MongoDB 3.6, however, it was only possible to atomically update the first matching array element in a single update command. With fully expressive array updates, developers can now perform complex array manipulations against matching elements of an array – including elements embedded in nested arrays – all in a single atomic update operation. MongoDB 3.6 adds a new arrayFilters option, allowing the update to specify which elements to modify in the array field. This enhancement allows even more flexibility in data modeling. It also delivers higher performance than alternative databases supporting JSON data as entire documents do not need to be rewritten when only selective array elements are updated. Learn more from the array update documentation . Next Steps That wraps up the first part of our what’s new blog series. Remember, if you want to get the detail now on everything the new release offers, download the Guide to what’s New in MongoDB 3.6 . Alternatively, if you’d had enough of reading about it and want to get started now, then: Spin up MongoDB 3.6 on the MongoDB Atlas database service . Download MongoDB 3.6 to evaluate the new release in your own environment. Sign up for our free 3.6 training from the MongoDB University.
Transitioning from Teacher to MongoDB’s New Enterprise Modernization Team: Meet Gabriela Preiss
As a global company, MongoDB has amazing employees with interesting backgrounds and stories. I recently sat down with Gabriela Preiss, an Enterprise Modernization Consultant, to learn more about her journey across the globe from the U.S. to Barcelona, Spain, and her experience transitioning from teaching to becoming the first hire for MongoDB’s brand-new Enterprise Modernization Team, shifting enterprises toward innovation and generating a ton of compelling content along the way. Andrew Bell: Thank you for sharing your story, Gabriela. I’d love to know how you got to where you are today in your role. What skills are important for someone on your team to be successful? Gabriela Priess: My career journey has been from one end of the spectrum to the other. Originally, I studied English and education, and I was a high school teacher for four years. I loved teaching, and I encourage anyone who wants to pursue it to do just that, but eventually, I hit a block and craved more mobility. So I moved from the U.S. to Portugal and studied web and mobile development. Finding myself back as a junior in a new industry, I worked my way up by freelancing as a web developer, building a curriculum for a coding school, and then quickly finding my way into a lead tech support role with a popular web application organization, where I also led the QA process. So, how does all of this add up to working in and with data? I truly believe every professional experience is the chance to extract something positive — a learning takeaway. This diverse background has challenged me and shaped me, as well as helped me to be confident in my choices, to trust I’m taking steps in the right direction, because ultimately each career move has been better than the last and has led me to where I am now, with MongoDB, as an Enterprise Modernization Consultant. Ultimately a career risk led me to a job that didn’t even exist a year ago on a new team. So, we can never truly say what the future holds for us; we may be headed toward a killer career that hasn’t even been invented yet. When it comes to being successful on my team, I think this role is open to so much diversity. I’m trying to narrow down any specific skills, but I think anyone who is ambitious, independent, takes ownership with what they produce, and is curious will succeed here. Curiosity is a huge asset — someone who is open to learning and diving deep into what they don’t yet understand, eager to keep growing, and tech-curious. A big part of what we do involves us keeping our finger on the pulse of tech and data innovation, so we can confidently discuss, debate, or write about it. This means feeding ourselves with the right tech news content. AB: I’d love to know more about the modernization team. What’s your role and your day-to-day like? GP: Our reach is quite broad, but if I had to define it, I’d say the Enterprise Modernization Team (EMT) assists, educates, and helps inspire large enterprises to move toward modernization and innovation. Often, large enterprises have the most complex, costly legacies in their systems and need macro and micro aid and insights to not only modernize but also to visualize and tally the endpoint. EMT Principles and Consultants have the industry expertise and capability to translate our value proposition to senior executives and engineering management. This includes generating training content for internal teams; meeting with other teams for potential and ongoing accounts; delivering webinars, published content, and interactive exposition presentations; and meeting with clients so they have a stronger understanding of how MongoDB helps them to modernize from the most basic format, such as adopting the document model, to truly leading in innovation, such as data science, machine learning, and real-time analytics. So, EMT is a bridge between sales, technical sales, and marketing for complex industry use cases and solutions. These are the teams we collaborate most often with, working closely with sales reps and solutions architects, collaborating with solution providers, and closely aligning with the marketing team producing diverse content and product alignments. So, if you ask me what exactly is my role, I’d say it’s all of the above. Our team is small, although it’s growing quickly, and we have big plans to expand exponentially in the near future. That said, we have a democratic way of dividing the work. We’re made up of our Global Head, Boris Bialek, our Principal, Steve Dalby, and the two Consultants, including myself and Vanda Friedrichs. And we’re all expected to bring equally to the table, despite who has more seniority. This lets us all have an idea of what everyone is working on, and we frequently dip into each other’s projects either to help out or request aid. Each project is free roaming for all: as long as we’re aware of the objective and deadline, we can get creative with how we reach the endpoint. My projects are constantly evolving and regenerating, and I could joke that the only thing they have in common with each other is they all have to do with MongoDB. However, when I was hired, Boris was very clear and direct that each day would be different, and his promise has held true. I don’t have a day-to-day like most others might in regard to consistent projects, but the objective is always the same for each: how can we showcase MongoDB’s value in modernization and innovation in regards to data and tech? Because my projects are so diverse, and often more creative-oriented than anything else, I make up for what some may call a “lack of structure” by being very structured in how I plan my day. Before each day, I predetermine how my next day is going to be divided hourly by projects, tasks, and follow-ups, and I reserve some time for “self-learning,” where I take time to continue my training curriculum, since that’s an ongoing track. AB: Since this is a new role, what tools and resources (e.g., Sales Bootcamp) were you given to help you ramp up? GP: True, this was a new role when I first stepped in, so I didn’t totally know what to expect. There was a running joke I was learning by a fire hose, just having everything blasted at me, and something was bound to stick. MongoDB sets all employees up with boundless learning resources, so I created a curriculum for myself. I prioritized from the top down, based on what I needed to understand ASAP, such as MongoDB’s services and functions, and from there I had freedom to roam based on what interested me the most and what my weak spots were, and was given time to dive in deep technically. For example, I ran POVs to see the data in action from a locally set up database. I know other teams within the company have established curriculums for onboarding, but because this was a new role, I used the resources available and that worked for me. I was given a lot of liberty with my learning because it was mostly autonomous and self-driven, but that’s not to say my learning is over. The company really promotes a learning culture, and every week there are new resources with webinars, learning materials, training materials, and so on. Early into my onboarding, I participated in what’s called our Sales Bootcamp. It’s a two-week intensive training that dives deep into MongoDB’s services as a whole and lays a strong foundation to build on. It’s usually something that’s done in person at MongoDB’s headquarters in New York City, but since this is the COVID-19 era, it was done virtually, with a big cohort of new hires included from Europe and the Americas. This was a cool experience, because I got to meet a lot of new faces. Professionally, my background is originally in education, so I used to write my own curricula for my students, and I’ve been impressed with what I find the MongoDB enablement and Learning & Development teams generating. AB: What content have you and will you create? What is the purpose of this content? How is it leveraged? GP: Among many other roles, the EMT is a content-generating team, so we’re constantly working on creating something new, or collaborating with other teams to create new content. As of today, I’ve been with MongoDB for four months, and in that short time, I’ve been able to generate a lot of interesting, challenging pieces. Each project I’m given is a chance to dive deeper into that subject and expand my understanding of it — like data science or fintech, for example. One of the first projects I had was the chance to write a blog about MongoDB’s partnership with Iguazio , and how our data platform is the ideal persistence layer for Iguazio’s data science and MLOps platform, which is used to develop, deploy, and manage AI applications. Clearly, each project is a team effort, but this gave me the opportunity to dive into a topic I find personally interesting, while building connections with some of our most innovative partners. My first or second week I was introduced to an internal deck created by one of our Solutions Architects, Pascal Jensen. It was a sort of think piece on how data is being driven by the growing uncertainties of the world, in a political, social, and economic sense, and how the most innovative leading companies are responding. We decided to turn this into a more holistic, complete white paper to reach a wider audience. With that, after really digesting the deck that was available and multiple interviews with the Solutions Architects that contributed to it, I built an extensive paper around it, giving breath to the expression “digital by default.” This was something I was quite proud of, because it was so early on in my time with MongoDB, and it let me dive into truly interesting topics. I was able to build on the holistic elements of data and how it’s reshaping even the most mundane elements of the world, propelling us into the future with innovative technologies and solutions for some of the most crucial global concerns, such as hunger or healthcare. Last month, I presented my first corporate webinar with MongoDB, discussing transitioning from a relational database to MongoDB’s document model. It was a huge opportunity, because we were focusing on Spanish-speaking countries in Latin America. For me, this was almost a beta project, because I didn’t know what to expect in regard to reception. In the end, it was a massive success: overall, we had more than 6,500 registrants. That was a really exciting experience, because I knew as a team and a company we were clearly doing something right, engaging with the right audience, and connecting with the right people. There is a really positive response still outpouring from that webinar, and I was happy to be a part of it, especially as a rookie. Again, it just speaks to how much autonomy and freedom to create I’ve been given. My manager never holds me back from any opportunity and really encourages our success. In the spring, we’ll repeat the same endeavor with another webinar, covering a different topic I’m currently preparing in Spanish. AB: What was it like starting in a new role on a new team, especially during the pandemic? How do you stay connected to the team despite living in different countries? GP: Despite the pandemic, there was a lot to dive into because the company was running full speed ahead. It can be slightly intimidating being the new person on a fast-paced team, but I felt very included and seen from day one, and there was more than enough work and training to keep me busy. I haven’t really considered what it would’ve been like to work with MongoDB prepandemic, because at this point, this is all I’ve known. Staying connected with my direct team, though, has been the easiest part for me. I’ve never once felt disconnected despite never having met them in person. As of now, we’re dispersed across Dublin, London, Zurich, and Barcelona, and we’re growing. Plus, our backgrounds are even more diverse considering where we’ve lived, where we’re from, and the languages we speak. It’s refreshing to be part of a team that doesn’t feel limited to one geographic region, because it opens our minds and team discussions to diverse views and ideas. AB: How would you describe the team’s culture? And how do you maintain this culture during COVID-19? GP: The team culture is really positive, inclusive, and ambitious. Every team meeting feels like a brainstorming session, because part of our job is innovation. We’re all given a voice and are expected to use it as we shuffle through ideas and ongoing projects. But overall, our team culture is casual, in the sense that we engage with each other informally, but we all recognize what we need to be working on and by when. We’re each expected to take ownership of our work, and we’re given a lot of creative and structured autonomy. This means independently owning whatever it is we’re working on, and this goes for professional learning too. MongoDB creates a lot of resources internally that I take advantage of, from guided training and courses to reading material, interactive training, webinars, and so forth. I was paired up with one of our Solutions Architects, Benjamin Schubert, and he patiently made himself available to help guide me through some of the more technical aspects of our databases as I was learning how to maneuver through it myself, and I am eternally grateful. Of course, we have support any time we need it, and I can easily seek out resources or set up a Zoom call with an internal expert if I have any questions, but at the end of the day, the ticker moves forward only if everyone is doing their part, so each of us takes our part seriously. Interested in pursuing a career at MongoDB? We have several open roles on our teams across the globe , and would love you to build your career with us!