MongoDB 1.4 Ready for Production

MongoDB
March 25, 2010 | Updated: January 20, 2017
#Releases

The MongoDB team is very excited to announce the release of MongoDB 1.4.0.  This is the culmination of 3 months of work in the 1.3 branch and has a large number of very important changes.

Many users have been running 1.3 in production, so this release is already very thoroghly vetted both by our regressions systems and by real users.

Some highlights:

Core server enhancements

Replication & Sharding

  • better handling for restarting slaves offline for a while
  • fast new slaves from snapshots
  • configurable slave delay
  • replication handles clock skew on master
  • $inc replication fixes
  • sharding alpha 3 - notably 2 phase commit on config servers

Deployment & production

  • configure “slow” for profiling
  • ability to do fsync + lock for backing up raw files
  • option for separate directory per db
  • http://localhost:28017/_status to get serverStatus via http
  • REST interface is off by default for security (–rest to enable)
  • can rotate logs with a db command, logRotate
  • enhancements to serverStatus - counters/replication lag
  • new mongostat tool and db.serverStatus() enhancements

Query language improvements

Geo

Downloads: www.mongodb.org/display/DOCS/Downloads

Full Change Log: jira

Release Notes: http://www.mongodb.org/display/DOCS/1.4+Release+Notes

Thanks for all your continued support, and we hope MongoDB 1.4 works great for you.

As always, please let us know of any issues,

-Eliot and the MongoDB Team

← Previous

MongoDB 1.4 Performance

We generally avoid posting benchmarks and suggest people create their own targeting their use cases. However, we have decided to publish a few of our internal micro-benchmarks comparing 1.2 with 1.4RC2 (aka 1.3.5) to show that in almost all cases performance is the same or better (sometime significantly so), even though we’ve added many new features. The test works by spawning N threads and having them hammer the DB with one operation as fast as they can. It is probably best to ignore the raw numbers and only look at the relative performance. In particular, these numbers shouldn’t be compared against other databases.  Results Code for benchmarks A few highlights (and one lowlight): Single threaded query performance increased slightly Query performance increases linearly or super-linearly as more cores are used Insert performance increases by 10-30% vs 1.2 It is usually faster to create an index after importing your data than before. More so in 1.4. Not shown, but performance for both 1.2 and 1.4 held steady from 10 threads up to at least 500 threads. Even where it looks like the lines will cross, they do not. Update and Upsert performance is the same or higher until using more than 4 hammering threads. In practice, this shouldn’t effect users unless they are already doing more updates per second than the server can handle. Even so, we will look into solutions to this in the 1.5.x series. This test was run on an Intel Core i7 Quad 860 2.8GHz with 8GB of RAM and an Intel G2 SSD. Even though they improved performance, HyperThreading and TurboBoost were disabled as they can skew results in nondeterministic ways.

March 25, 2010
Next →

MACH Aligned for Retail (Microservices, API-First, Cloud Native SaaS, Headless)

Across the Retail industry, MACH principles and the Mach Alliance are becoming increasingly common. What is MACH and why is it being embraced for Retail? The MACH Alliance is a non-profit organization fostering the adoption of composable architecture principles. It stands for Microservices, API-First, Cloud-Native SaaS and Headless. The MACH Alliance’s Manifesto is to: “Future proof enterprise technology and propel current and future digital experiences" The MACH Alliance and the creation of this set of principles originated in the Retail Industry. Several of the 5 co-founders of the MACH Alliance are technology companies building for retail use cases: for example commercetools is a composable commerce platform for retail (built completely on MongoDB). MongoDB has been a member of the MACH Alliance since 2020, as an “enabler” member, meaning use of our technology can enable the implementation of the MACH principles in application architectures. This is because a data layer built on MongoDB is ideal as the basis for a MACH architecture. Members of our Industry Solutions team sit on the MACH technology, growth and marketing councils, and actively are involved with furthering the adoption of MACH across the Retail Industry What is MACH, why is it important for retail? The retail industry has long been a fast adopter of technology and a forerunner in technology trends. This is because of the competitive nature of the business leading a drive towards innovation- its vital that retails are able to react quickly to new technologies (e.g. NFTs, VR, AI) to capture market share and stay ahead of the competitors. Retailers have realized that to be able to deliver new and value-add experiences to their customers, they have to cut back on operational overhead that leads to increased cost and build standard functionality that can either be bought or re-used. This is where the benefits of MACH comes in- it's all about increasing the ability to deliver innovation quickly while lowering operational costs & risk. Microservices: An approach to building applications in which business functions are broken down into smaller, self-contained components called services. These services function autonomously and are usually developed and deployed independently. This means the failure or outage of one microservice will not affect another and teams can develop in parallel, increasing efficiency. API-First: A style of development where the sharing and use of the data via API (application programming interface) is considered first and foremost in the development process. This means that services are designed to aid the easy sharing of information across the organization and simple interconnectivity of systems. Cloud-Native SaaS: Cloud-native SaaS solutions are vendor-managed applications developed in and for the cloud, and leveraging all the capabilities the cloud has to offer, such as fully managed hosting, built-in security, auto-scaling, cross-regional deployment and automatic updates. These are a good fit for a MACH architecture as adopting them can reduce operational costs and frees up developers for value-add work like new unique customer experiences. Headless: Decoupling the front end from the back-end so that front ends (or “heads”) can be created or iterated on with no dependencies on the back end. The fact that the layers are loosely coupled decreases time to market for new front ends, and encourages the re-use back-end services for multiple purposes. It also de-risks change in the long term as services can function independently. Where does MongoDB come in? MongoDB is an enabler for MACH, meaning that using MongoDB as your data layer helps retailers and retail software companies. achieve MACH compliance. Our data model, architecture and functionality empower IT organizations to build in line with these architecture principles. During a digital transformation, where a retailer is modernizing a monolith into a microservices based architecture, they're looking for a data layer which will enable speed of development & change. MongoDB is the "most wanted" database 4 years running on Stack Overflow's developer survey- this is because our document model maps to the way developers are thinking & coding, and the flexibility allows for iterative change of the data layer. When looking at API based communication, the standard format for APIs is JSON, which again maps to MongoDB's document model. The idea with API-first development is to develop with the API in mind- why not store the data the way you're going to serve it by API. This reduces complexity and increases performance. Cloud Native and SaaS products have become the norm as retailers wish to reduce maintenance and management work. MongoDB Atlas, provides a database-as-a-service, guaranteeing 99.995% uptime, automatic failover and self-healing and allowing DevOps engineers to spin up databases in minutes or by API/ script. Many retail software companies are also built on MongoDB Atlas- for example commercetools, which provides an ecommerce solution as a SaaS product. Headless architectures require a data layer that is able to adapt and change for new workloads. The ability to change the schema at runtime, with no downtime, makes MongoDB's document model ideal for this. Performance and the ability to scale for new "heads" is also important. MongoDB is known as a high performance database and can scale vertically automatically or scale out horizontally seamlessly. So MongoDB becomes a great choice for retailers choosing to adopt a MACH architecture (see figure 1 below). As a general purpose database with high performance, a rich expressive query language and secondary indexing, MongoDB is a really good fit as a data layer as it is capable of handling operational and analytical needs of the application. FIgure 1: Example of a MACH architecture Want to know more? Are you interested in a transition to MACH? Dive into our four part blog series exploring each topic in detail and how MongoDB supports each of these principles: Microservices API-First Cloud-Native SaaS Headless

February 1, 2023