MongoDB 3.0.13 is out and is ready for production deployment. This release contains only fixes since 3.0.12, and is a recommended upgrade for all 3.0 users.
Fixed in this release:
- SERVER Add Debian 8 (Jessie) builds and associated package repository
- SERVER On RHEL7/Centos7 mongod can't stop if pid location in conf differs from the init.d script
- SERVER Database/Collection drop during initial sync can cause collmod to fail initial sync
- SERVER Update to PCRE 8.39
- SERVER Building 2dsphere index uses excessive memory
- TOOLS No numeric version in --version output
As always, please let us know of any issues.
-- The MongoDB Team
Announcing MongoDB 3.4
Today we are announcing MongoDB 3.4 , another milestone in our march to being the default database for modern applications. 3.4 makes MongoDB more flexible than ever, allowing developers to consolidate even more use cases into their MongoDB deployment, even as we continue to mature the platform and its ecosystem. MongoDB was created to make it easy for developers to work with their data, beginning with introducing the document model itself. Documents are the best rudimentary unit for a data store, because they let you represent any kind of data, and embody their structure however best suits your use case. Whether that means deep or shallow nesting (or no nesting), documents can handle it. The key is being able to add many types of queries and algorithms to the data. MongoDB 3.4 adds a stage to the aggregation pipeline that enables faceted search , greatly simplifying the query load for applications that browse and explore that data. It also adds operators to power graph queries . As we continue to add query features, users can consolidate more uses cases, instead of bloating their application footprint with a proliferation of specialized data stores. Just because it’s easy to work with data in MongoDB, it doesn’t mean we can’t make it easier. In 3.4, the aggregation pipeline continues to mature , with more operators and expressions, enhancing string handling, allowing more sophisticated use of array elements, testing fields for type, and support for branching. Financial calculations are made simple with the addition of a Decimal data type. I think it was John Donne who said: “No database is an island,” but whoever said it, they were very right. A database has to work as the heart of an ecosystem, and in 3.4, we continue to build that thriving ecosystem. Connecting MongoDB to the outside world is better than ever. MongoDB 3.4 introduces a ground-up rewrite of the BI connector , which improves performance, simplifies installation and configuration, and supports Windows. 3.4 also includes an update for our Apache Spark connector , with support for the Spark 2.0. We’ve also extended the platforms that MongoDB runs on, including ARM-64, and IBM’s POWER8 and zSeries platforms. MongoDB Compass is growing up with 3.4. It has new ways to depict data, such as the map view for geographic data, and it has become a data manipulation and performance tuning tool as well. In 3.4, Compass offers visual plan explanations, real-time stats, CRUD operations and index creation, so now you can identify, diagnose, and fix performance and data problems all from within Compass. Of course, MongoDB 3.4 is supported by our trifecta of enterprise-grade ops management platforms: Ops Manager , Cloud Manager , and MongoDB Atlas , each of which add new features with this release. Ops Manager, for example, has improved its monitoring with built in telemetry gathering tailored to each deployment platform, and now allows ops teams to create server pools to serve up database-as-a-service to internal teams. Atlas introduces Virtual Private Cloud (VPC) Peering, allowing teams to use convenient private IPs to talk to their MongoDB service from within their AWS VPC. There’s a ton more than I can fit into a blog post. That’s what release notes are for. But I shouldn’t leave out a few highlights, like: tunable consistency control for replica sets, including linearizable reads; collations for queries and indexes; and read-only views , which enable us to bring field level security to apps handling regulated data. We’re incredibly excited to ship MongoDB 3.4 to you, so it can help your data serve you, not the other way around. Our approach is to build a database that can handle any kind of data, and the capabilities to query that data however you need to. Learn more about MongoDB 3.4, register for our upcoming webinar: Find out what's new About the Author - Eliot Horowitz Eliot Horowitz is CTO and Co-Founder of MongoDB. Eliot is one of the core MongoDB kernel committers. Previously, he was Co-Founder and CTO of ShopWiki. Eliot developed the crawling and data extraction algorithm that is the core of its innovative technology. He has quickly become one of Silicon Alley's up and coming entrepreneurs and was selected as one of BusinessWeek's Top 25 Entrepreneurs Under Age 25 nationwide in 2006. Earlier, Eliot was a software developer in the R&D group at DoubleClick (acquired by Google for $3.1 billion). Eliot received a BS in Computer Science from Brown University.
Splitit & MongoDB Atlas: Racing to Capture a Global Opportunity
Splitit is a global payment solution that allows businesses to offer installment plans for their customers. Unlike with other buy now, pay later (BNPL) solutions, Splitit shoppers can split their online purchases into monthly installments by using their existing credit, without the need for registration, application, or approval. “We have a very different proposition than others in this space,” says Splitit’s CTO, Ran Landau. “We’re not a financing company. We utilize the customer’s existing credit card arrangement, which allows us to accommodate smaller average deal values and a broader range of installment schedules.” Splitit works with online retailers across all market sectors and diverse price points, and recently raised $71.5 million in investment to fund global expansion. Following its IPO in January 2019, the business had seen strong growth as more consumers moved from brick and mortar to ecommerce. Then COVID-19 hit, and online shopping boomed. Landau recognized that the company needed to quickly scale its infrastructure in order to capture this large opportunity. The Need for Speed Landau joined Splitit in May 2019 and worked to modernize the company’s infrastructure. At the time, the team was using a traditional relational database. “As tech leaders, we need to make the right decision,” he says. “When I came to Splitit, I knew I needed a powerful NoSQL server so that my developers could develop faster and so that we could scale – both things that our relational databases were failing to deliver.” In the interest of getting up and running quickly, Ran’s team thought that they could move faster using a cloud-provider database that mimicked MongoDB functionality. He had used MongoDB before and saw that this solution offered the same drivers he was familiar with and claimed compatibility with MongoDB 3.6. Initially, the new solution seemed fine. But as the team started to migrate more data into the database, however, Landau noticed a few missing features. Scripts for moving documents from one collection to another were failing, and overall performance was deteriorating. The application became slow and unresponsive even though the load on the database was normal. “We were having issues with small things, like renaming collections. I couldn’t search or navigate through documents easily,” recalls Landau. Offline Database: A Breaking Point The application was unable to communicate with the database for 20 minutes, and when the database finally came back online, something wasn’t right. Landau contacted support, but the experience was not very helpful. “We were not pleased with the response from the database vendor,” he explains. “They insisted that the issue was on our side. It wasn’t so collaborative.” Fortunately, he had taken a snapshot of the data so Splitit was able to revert back to an earlier point in time. But the incident was troubling. Other teams also had been complaining about how difficult it was to debug problems and connect to the database successfully. Landau knew he needed to find a better solution as soon as possible. MongoDB Atlas: A Reliable, Scalable Solution Landau believed that MongoDB was still the right choice for Splitit, and investigated whether the company offered a cloud solution. He discovered MongoDB Atlas and decided to give it a try. “The migration to MongoDB Atlas was so simple. I exported whatever data I had, then imported it into the new cluster. I changed the connection strings and set up VPC peering in all of my environments,” says Landau. “It was incredibly easy.” Not only was MongoDB Atlas built on actual MongoDB database software, but it was also secure, easy to use, and offered valuable features such as Performance Advisor . “It can tell you which indexes need to be built to increase speed. It’s such a powerful tool — you don’t need to think; it analyzes everything for you,” explains Landau. Another great feature was auto-scaling. “My biggest concern as I scale is that things keep working. I don’t have to stop, evaluate, and maintain the components in my system,” says Landau. “If we go back to doing database operations, we can’t build new features to grow the business.” Auto-archival Made Easy with Online Archive As a business in the financial services industry, Splitit needs to comply with various regulations, including PCI DSS . A key requirement is logging every transaction and storing it for auditing purposes. For Splitit, that adds up to millions of logs per day. Landau knew that storing this data in the operational database was not a cost-effective, long-term solution, so he initially used an AWS Lambda function to move batches of logs older than 30 days from one collection to another periodically. A few months ago, he discovered Online Archive , a new feature released at MongoDB.live in June 2020. With it, Landau was able to define a simple rule for archiving data from a cluster into a more cost-effective storage layer and let Atlas automatically handle the data movement. “The gem of our transition to Atlas was finding Online Archive,” says Landau. “There’s no scripting involved and I don’t have to worry about my aging data. I can store years of logs and know that it’s always available if I need it.” Online Archive gives me the flexibility to store all of my data without incurring high costs, and feel safe that I won't lose it. It's the perfect solution. Ran Landau, CTO, Splitit With federated queries, the team can also easily analyze the data stored in both the cluster and the Online Archive for a variety of use cases. Ready for Hypergrowth and Beyond Looking back, Landau admits that he learned his lesson. In trying to move quickly, he selected a solution that appeared to work like MongoDB, but ultimately paid the price in reliability, features, and scalability. You wouldn't buy a fake shirt. You wouldn't buy fake shoes. Why buy a fake database? MongoDB Atlas is the real thing. Ran Landau, CTO, Splitit Landau is confident that his investment in MongoDB puts in place a core building block for the business’ continued success. With a fully managed solution, his team can focus on building features that differentiate Splitit from competitors to capture more of the market. “We saw our growth triple in March due to COVID-19, but the sector as a whole is expanding,” he says. “Our technology is patent protected. Everything we build moving forward will be on MongoDB. As a company that’s scaling rapidly, the most important thing is not having to worry about my scaling. MongoDB Atlas takes care of everything.”