MongoDB 3.2.5 is out and is ready for production deployment. This release contains only fixes since 3.2.4, and is a recommended upgrade for all 3.2 users.
Fixed in this release:
- SERVER-23274 Aggregate with out, then stepdown, out collection dropped.
- SERVER-23283 RangeDeleter does not log cursor ids correctly in deleteNow()
- SERVER-22964 IX GlobalLock being held while wating for wt cache eviction
- SERVER-22937 Retry catalog operations whenever possible
- SERVER-22831 Low query rate with heavy cache pressure and an idle collection
- SERVER-21681 In-memory storage engine not reporting index size
As always, please let us know of any issues.
– The MongoDB Team
Oxford Nanopore Technologies & MongoDB: Powering Real-Time Genetic Analysis with Docker, MongoDB, & AWS
Genetic analysis is entering the mobile age. Earlier this year scientific journal Nature published a paper showing how Ebola researchers in Guinea were able to analyse genetic material in hours, rather than the weeks it had previously taken. This increased speed meant doctors could better understand the spread of the disease. Then quickly develop strategies to stop it. The hardware that enabled the genetic analysis is the MinION , from UK-based Oxford Nanopore Technology . The stapler-sized MinION is the data-capture side of the analysis, but for the purposes of this article we’re interested in data processing and analysis. In particular how Oxford Nanopore has been able to build a fast, agile and powerful cloud-based platform that has the potential to deliver biological analyses to any scientist, at any time, anywhere in the world. The applications for this genetic analysis go far beyond the medical field and disease control. Oxford Nanopore is using technologies like MongoDB, Amazon Web Services, and Docker containers in its stated goal: “to enable the real-time analysis of any living thing, by any user, in any environment.” A Billionth of a Meter The MinION does its genetic magic through the use of nanopores. Each nanopore is just a billionth of a meter wide. The technology in the MinION threads the genetic material through the nanopores where tiny differences in each sample can be registered as electrical disruptions. If you want a more detailed explanation of nanopores, check out Oxford Nanopore Technologies’ website . DNA sequencing can be associated with predictive human questions alone, for example “what probability is there that this person will develop a specific disease?” But human genome research is just a part of the equation, and the portable nature of the MinION means it might be suitable for a more diverse range of questions: Is the soup I’m about to eat safe? What type of disease am I looking at? Where did this pathogen originate? How can we grow more resilient plants? Is this hospital ward clean? Crucially, these questions need to be answered quickly, and in a range of environments – from the science lab to the middle of the jungle. Three Billion Bases in the Cloud The cleverest sequencing tool in the world would be worthless if we were unable to process and understand the data it created. To deal with the volume and velocity of processing billions of lines of DNA, Oxford Nanopore Technologies built analysis capabilities offered by Metrichor , on powerful software that can scale seamlessly in the cloud. Richard Carter, Associate Director, Data Integration at Oxford Nanopore gave a presentation at MongoDB Days where he noted: “When we began building Metrichor services, it was clear our data would not fit in the neat rows and columns of a relational database. We needed a database that could look at our complex information in more flexible and dynamic ways. It was a straightforward decision to go with MongoDB. It’s robust, best of breed, and has the data modelling and analytics flexibility we required. We also observed the technology has an incredible community behind it, coupled with extensive documentation and training. All of which enable us to get productive with the technology much faster.” The DNA data is read locally onto the MinION and it’s then sent to an Amazon Web Services cloud. The findings are then analysed before the results are sent back to the user’s laptop or displayed in web reports. All of this is driven by, and stored in the non-relational database MongoDB. Docker containers are used to package, deploy and run the software across the cloud deployment. Carter also noted that: “The biology and hardware is the real trick, of course, but we needed power and scalability to run cloud based services as we wished.” There were other challenges the team had during development of their software. They had a technical goal and a number of ways they could reach it while keeping the focus on the biology. It was essential they had the freedom to experiment and make significant changes as they went along. “Happily, MongoDB supports an evolutionary approach to development.” explained Carter. “We were spinning up instances and working on the science almost instantly. The database got out of the way.” Carter’s team does not have a database administrator. They have found that MongoDB Cloud Manager is able to provide all the monitoring data needed to keep a deployment healthy. Features like simple, automated deployment across any cloud region, continuous backups, and telemetry visualisations also mean administration doesn’t monopolise the developers’ time. Giant Ideas Guinea is just one of the many places where researchers are using Nanopore’s data architecture for analysis. In fact, NASA will soon be using the MinION for testing biological molecules on the International Space Station. Regardless of the location, the combination of rigorous science and the power of cloud computing is ushering in a new way of understanding the world. Read more about MongoDB and its implementation on the AWS cloud platform. MongoDB on AWS: Guidelines and Best Practices About the Author - Mat Keep Mat is director of product and market analysis at MongoDB. He is responsible for building the vision, positioning and content for MongoDB’s products and services, including the analysis of market trends and customer requirements. Prior to MongoDB, Mat was director of product management at Oracle Corp. with responsibility for the MySQL database in web, telecoms, cloud and big data workloads. This followed a series of sales, business development and analyst / programmer positions with both technology vendors and end-user companies.
Solving Customer Challenges: Meet Consulting Engineer Paul-Emile Brotons
Our Professional Services team is growing. Hear from Paul-Emile Brotons about his Consulting Engineer (CE) role, the types of projects he works on for customers, how he continually learns, and what makes this role a great opportunity for people with technical backgrounds who enjoy solving a variety of problems. Jackie Denner: Thanks for sharing your experience as a Consulting Engineer. Can you tell me about the Consulting Engineer team within Professional Services at MongoDB? Paul-Emile Brotons: I joined MongoDB a year and a half ago. The Consulting Engineering team is responsible for assisting customers at every stage of their MongoDB journey to ensure they are successful. We assist customers with training, database design, architecture design, code reviews, preproduction audits and reviews, setup, and health checks. I’m part of the South European team and I’m based out of Paris, but the Consulting Engineering team is worldwide. Since we are solving challenging problems, the team is very close and meets daily to share ideas and discuss solutions. I always have colleagues available to help at any time of day. JD: As a junior engineer, why did you opt for a Consulting Engineer role instead of a traditional Product Engineer role? PEB: Before joining MongoDB, I was a full-stack engineer at a French startup specializing in revenue management. I learned great technical skills there, but, in the end, I felt I was missing the big picture: What other stacks exist on the market? What tools are other engineering teams at big companies or startups working with? That is exactly what the Consulting Engineer role made possible for me. Since our projects are usually short-term, a typical CE may see 50 projects in a year. In my current role, I have been working with almost every new and exciting technology. I also get to learn how people within product and engineering work in other organizations. I find this very valuable, and it’s not something you can easily find in a traditional Product Engineer role. JD: What does a day in your role look like? PEB: CEs are assigned to “missions,” which typically range from one to four days and concern a specific customer. Longer-term projects can span several months. My role generally starts the week before. Before each mission, I try to set up a short preconsult session where I meet with customers and discover the topics they want to discuss. Then, on the day of the mission, I provide training, performance evaluation, tuning, and more. I learn a lot in my role, and I try to find solutions to all the difficult problems the customer has not been able to solve alone. It’s challenging and very rewarding. In some cases, I may not be assigned to a customer and I will be working on preparation and continuous learning. I appreciate the liberty my role gives me. JD: What was your onboarding like, and what learning and growth opportunities are there on the Consulting Engineer team? PEB: To be completely honest, I was a bit scared when I joined. I was very impressed with the way people work here, and I had a feeling it would be hard for me to onboard. However, the ramp-up process is so well-done that it almost felt easy. The first weeks were dedicated only to training. First, we have to learn a lot about MongoDB. A CE is a database expert. Since almost every software needs a persistent layer, this expertise is very valuable. Second, we have to know our stuff when it comes to Linux, networking, cloud providers, architecture, coding, and more. Afterward, everything is done to gradually increase the level of difficulty; complex missions are not delivered by new hires. Management is really careful about that, which is reassuring. Once a CE is performing well in their role, they may be promoted to Senior and then Principal grades. Many of us also study to pass certifications. I will soon start studying for a Linux sysadmin certification. The management team is very supportive and encourages continuous learning. JD: How do you interact with other teams at MongoDB? PEB: The CE role requires a lot of interaction with teams such as Sales, Presales Engineering, and Product Engineering. Consulting Engineers can be leveraged to help Sales and Solution Architects before the sale happens, since we are seen as trusted advisers. We also often speak to product teams to discuss the inner workings of a product, feature, or system. I’ve had the opportunity to meet many people within MongoDB. JD: What is one of the most interesting or challenging projects you’ve worked on? PEB: It is honestly difficult to choose, but I would pick a long project I worked on with a major container transportation and shipping company. It was challenging given the scope of the project and the number of interactions and subjects I had to deal with. The project was key for the customer, and it was technically demanding. We had to review the whole application architecture; analyze the front end to infer the requests and schema design needed on the database side; work with a wide range of professionals, including developers, solution architects, Linux engineers, and project managers; and test that everything would happen as expected. It was a great learning experience, from both a personal and professional perspective. JD: What makes someone successful in a CE role? PEB: Aside from sufficient knowledge of computer science, the CE role requires good communication and problem-solving skills. You have to know how to listen to and understand the problems customers encounter before you can think of a solution. Good customer contact is often the key to a mission’s success, and it makes the difference between a satisfied customer and a happy customer. JD: What advice would you offer someone looking to move into Professional Services at MongoDB? PEB: First, prepare well for the interviews — study up on algorithms, two programming languages, and basic database and hardware concepts. The interviews can be challenging, and there are a lot of rounds. Second, I would advise candidates to look at the beginners course on the MongoDB University website. The courses are free and they’re the best I have done on the web so far. Going deeper into learning MongoDB before joining the company saved me a lot of time. Last but not least, I would encourage candidates to contact CEs at MongoDB to get a clear view of the company and the role. My colleagues and I are more than happy to answer any questions that might help someone decide if this role is the right fit for them. Interested in a Professional Services career at MongoDB? We have several open roles on our team and would love for you to transform your career with us!