One of the benefits of using MMS to back up MongoDB is that you have unlimited restores, which means you can use these restores in ways that might not have imagine.
For example, you can use MMS to seed a new replica set member. In fact, it can be faster with very large datasets or on replica sets under heavy load. It will only work if the latest snapshot (or the custom last 24 hour point in time snapshot) is still covered by the oplog window. Then you could seed the new member with the snapshot and then allow it to sync to the other replica set members. The instructions can be found in the docs.
Please note: if you use “Excluded Namespaces” on your MMS Backup (these exclude collections or entire databases from the snapshots), you will not be able to use MMS Backup snapshots to seed.
There are lots of other scenarios in which you might use MMS to build new environments. We covered some of them in a recent webinar. The slides and video are now available.
Dating at eHarmony - 95% Faster on MongoDB
Thod Nguyen, CTO of eHarmony, delivered a fascinating insight into how the world’s largest relationship service provider improved customer experience by processing matches 95% faster and increased subscriptions by 50% after migrating from relational database technology to MongoDB. The full recording and slides from Thod’s MongoDB World session are available now. eHarmony currently operates in North America, Australia and the UK. The company has a great track record of success - since launch in 2000, 1.2 million couples have married after being introduced by the service. Today eHarmony has 55m registered users, a number that will increase dramatically as the service is rolled out to 20 other countries around the globe in the coming months. eHarmony employs some serious data science chops to match prospective partners. Users complete a detailed questionnaire when they sign up for the service. Sophisticated compatibility models are then executed to create a personality profile, based on the user’s responses. Additional research based around machine learning and predictive analytics is added to the algorithms to enhance the matching of prospective partners. Unlike searching for a specific item or term on Google, the matching process used to identify prospective partners is bi-directional, with multiple attributes such as age, location, education, preferences, income, etc. cross-referenced and scored between each potential partner. In eHarmony’s initial architecture, a single monolithic database stored all user data and matches, however this didn’t scale as the service grew. eHarmony split out the matches into a distributed Postgres database, which bought them some headroom, but as the number of potential matches grew to 3 billion per day, generating 25TB of data, they could only scale so far. Running a complete matching analysis of the user base was taking 2 weeks. In addition to the problems of scale, as the data models became richer and more complex, adjusting the schema required a full database dump and reload, causing operational complexity and downtime, as well as inhibiting how quickly the business could evolve. eHarmony knew they needed a different approach. They wanted a database that could: Support the complex, multi-attribute queries that provide the foundation of the compatibility matching system A flexible data model to seamlessly handle new attributes The ability to scale on commodity hardware, and not add operational overhead to a team already managing over 1,000 servers eHarmony explored Apache Solr as a possible solution, but it was eliminated as the matching system requires bi-directional searches, rather than just conventional un-directional searches. Apache Cassandra was also considered but the API was too difficult to match to the data model, and there were imbalances between read and write performance. After extensive evaluation, eHarmony selected MongoDB. As well as meeting the three requirements above, eHarmony also gained a lot of value from the MongoDB community and from the enterprise support that is part of MongoDB Enterprise Advanced . Thod provided the audience with key lessons based on eHarmony’s migration to MongoDB: Engage MongoDB engineers early. They can provide best practices in data modeling, sharding and deployment productization When testing, use production data and queries. Randomly kill nodes so you understand behavior in multiple failure conditions Run in shadow mode alongside the existing relational database to characterize performance at scale Of course, MongoDB isn’t the only part of eHarmony’s data management infrastructure. The data science team integrates MongoDB with Hadoop, as well as Apache Spark and R for predictive analytics. The ROI from the migration has been compelling. 95% faster compatibility matching. Matching the entire user base has been reduced from 2 weeks to 12 hours. 30% higher communication between prospective partners. 50% increase in paying subscribers. 60% increase in unique web site visits. And the story doesn’t end there. In addition to eHarmony rolling out to 20 new countries, they also plan to bring their data science expertise in relationship matching to the jobs market – matching new hires to potential employers. They will start to add geo-location services as part of the mobile experience, taking advantage of MongoDB’s support for geospatial indexes and queries. eHarmony are also excited by the prospect of pluggable storage engines delivered in MongoDB 3.0 . The ability to mix multiple storage engines within a MongoDB cluster can provide a foundation to consolidate search, matches and user data. Whether you’re looking for a new partner, or a new job, it seems eHarmony has the data science and database to get you there. If you are interested in learning more about migrating to MongoDB from an RDBMS, read the white paper below: RDBMS to MongoDB Migration Guide
The Rise of the Strategic Developer
The work of developers is sometimes seen as tactical in nature. In other words, developers are not often asked to produce strategy. Rather, they are expected to execute against strategy, manifesting digital experiences that are defined by the “business.” But that is changing. With the automation of many time-consuming tasks -- from database administration to coding itself -- developers are now able to spend more time on higher value work, like understanding market needs or identifying strategic problems to solve. And just as the value of their work increases, so too does the value of their opinions. As a result, many developers are evolving, from coders with their heads-down in the corporate trenches to highly strategic visionaries of the digital experiences that define brands. “I think the very definition of ‘developer’ is expanding,” says Stephen “Stennie” Steneker, an engineering manager on the Developer Relations team at MongoDB. “It’s not just programmers anymore. It’s anyone who builds something.” Stennie notes that the learning curve needed to build something is flattening. Fast. He points to an emerging category of low code tools like Zapier, which allows people to stitch web apps together without having to write scripts or set up APIs. “People with no formal software engineering experience can build complex automated workflows to solve business problems. That’s a strategic developer.” Many other traditional developer tasks are being automated as well. At MongoDB, for example, we pride ourselves on removing the most time-consuming, low-value work of database administration. And of course, services like GitHub Copilot are automating the act of coding itself. So what does this all mean for developers? A few things: First, move to higher ground. In describing one of the potential outcomes of GitHub Copilot, Microsoft CTO Kevin Scott said, ““It may very well be one of those things that makes programming itself more approachable.” When the barriers to entry for a particular line of work start falling, standing still is not an option. It’s time to up your strategic game by offering insight and suggestions on new digital experiences that advance the objectives of the business. Second, accept more responsibility. A strategic developer is someone who can conceive, articulate, and execute an idea. That also means you are accountable for the success or failure of that idea. And as Stennie reminded me, “There are more ways than ever before to measure the success of a developer’s work.” And third, never stop skilling. Developers with narrow or limited skill sets will never add strategic value, and they will always be vulnerable to replacement. Like software itself, developers need to constantly evolve and improve, expanding both hard and soft skills. How do you see the role of the developer evolving? Any advice for those that aspire to more strategic roles within their organizations? Reach out and let me know what you think at @MarkLovesTech .