This Week in MongoDB April 21-27

Amy Berman
April 21, 2014 | Updated: May 22, 2015
#Company

Here's what's going on in the MongoDB community this week:

Learn More

Events this Week:

Upcoming Events:

Online Education:

← Previous

MongoDB Backup for Sharded Clusters

A MongoDB backup strategy is necessary to protect your mission critical data. Backing up a distributed database system, such as a MongoDB sharded cluster, presents an additional level of complexity because each shard runs somewhat independently. Backing up any system requires a high level of attention to detail. Backups may not be fascinating, but they have to be right. MongoDB Management Service (MMS) moves the complexity of backing up a sharded system from you to us, while still providing confidence that the backups are reliable. To understand the benefits of MMS, let’s go over the alternative of backing up sharded MongoDB cluster yourself. You Can Do It Yourself To obtain a completely consistent point-in-time snapshot across the cluster, you will need to stop writes for a short time, essentially bringing the database offline. Once you do that, you can use any of the standard backup methods that MongoDB supports, including mongodump or file system snapshots . Most applications don’t allow stopping all writes to the database, so this way of getting a backup is a non-starter. Instead, most do-it-yourself solutions settle for approximate system wide snapshots. So just to be clear, if you are doing it yourself, you are probably settling for something other than a consistent snapshot. Even then, it’s not simple. Best practices are to have each shard be a replica set with at least three nodes. One node will be primary, and there will be two secondaries. Alternatively, you might have two nodes and an arbiter in each replica set. Here is how to get a mostly-consistent snapshot: Stop the cluster balancer  Take a backup up of the config database using mongodump. Lock one secondary node of each shard by issuing db.fsyncLock(). Do this as close to simultaneously as is feasible. Take backups of each shard in the cluster, preferably using a file system snapshot tool. Unlock each secondary as it completes. These steps are just an overview. The procedure is explained in-depth in the MongoDB docs . MongoDB Backups with MMS With MMS, you install the backup agent, turn the system on and you get consistent snapshots of the sharded cluster every six hours. That’s it. Ok, so how does it work? If you’re familiar with MMS, you’ll know that the MMS Backup Agent tails the replication oplog to provide a continuous backup of your data. MMS uses that oplog to maintain what is essentially a secondary node of every shard in your cluster. By default, we construct complete snapshots every six hours. For your replica sets, we can provide point-in-time recovery by replaying the oplog to the moment between snapshots that you specify. For sharded clusters, the backup agent pauses the balancer every six hours and inserts a token across all shards and config servers. MMS is always watching for those tokens. When MMS sees the token, it knows that it’s time to cut a consistent snapshot of the sharded system. The oplogs are applied to all replica sets in the cluster until the point in which the token was inserted, providing a consistent snapshot across the cluster. In addition to getting a complete snapshot every six hours, you can get more granular restore points by configuring checkpoints. During a checkpoint, a token is inserted to mark that moment. A snapshot is not created, but MMS can build restore images to that point. You can configure checkpoints at 15, 30, or 60 minute intervals. Let’s talk about the quality of the snapshot itself. It’s not a moment in time to the same degree you could obtain by turning off writes to your cluster. But, it’s better than the the technique outlined above in the do-it-yourself section. The tokens are inserted sequentially into every shard. The snapshots that result represent a view of the database system that an observer might witness standing at any given mongos. Using MMS, not only do you get a higher quality snapshot than you are likely getting yourself, you are getting it without the hassle of orchestrating your own snapshots. MMS moves the complexity of snapshot creation from your cluster to ours. You can start backing up MongoDB now by creating an MMS account .

April 21, 2014
Next →

Building AI With MongoDB: Integrating Vector Search And Cohere to Build Frontier Enterprise Apps

Cohere is the leading enterprise AI platform, building large language models (LLMs) which help businesses unlock the potential of their data. Operating at the frontier of AI, Cohere’s models provide a more intuitive way for users to retrieve, summarize, and generate complex information. Cohere offers both text generation and embedding models to its customers. Enterprises running mission-critical AI workloads select Cohere because its models offer the best performance-cost tradeoff and can be deployed in production at scale. Cohere’s platform is cloud-agnostic. Their models are accessible through their own API as well as popular cloud managed services, and can be deployed on a virtual private cloud (VPC) or even on-prem to meet companies where their data is, offering the highest levels of flexibility and control. Cohere’s leading Embed 3 and Rerank 3 models can be used with MongoDB Atlas Vector Search to convert MongoDB data to vectors and build a state-of-the-art semantic search system. Search results also can be passed to Cohere’s Command R family of models for retrieval augmented generation (RAG) with citations. Check out our AI resource page to learn more about building AI-powered apps with MongoDB. A new approach to vector embeddings It is in the realm of embedding where Cohere has made a host of recent advances. Described as “AI for language understanding,” Embed is Cohere’s leading text representation language model. Cohere offers both English and multilingual embedding models, and gives users the ability to specify the type of data they are computing an embedding for (e.g., search document, search query). The result is embeddings that improve the accuracy of search results for traditional enterprise search or retrieval-augmented generation. One challenge developers faced using Embed was that documents had to be passed one by one to the model endpoint, limiting throughput when dealing with larger data sets. To address that challenge and improve developer experience, Cohere has recently announced its new Embed Jobs endpoint . Now entire data sets can be passed in one operation to the model, and embedded outputs can be more easily ingested back into your storage systems. Additionally, with only a few lines of code, Rerank 3 can be added at the final stage of search systems to improve accuracy. It also works across 100+ languages and offers uniquely high accuracy on complex data such as JSON, code, and tabular structure. This is particularly useful for developers who rely on legacy dense retrieval systems. Demonstrating how developers can exploit this new endpoint, we have published the How to use Cohere embeddings and rerank modules with MongoDB Atlas tutorial . Readers will learn how to store, index, and search the embeddings from Cohere. They will also learn how to use the Cohere Rerank model to provide a powerful semantic boost to the quality of keyword and vector search results. Figure 1: Illustrating the embedding generation and search workflow shown in the tutorial Why MongoDB Atlas and Cohere? MongoDB Atlas provides a proven OLTP database handling high read and write throughput backed by transactional guarantees. Pairing these capabilities with Cohere’s batch embeddings is massively valuable to developers building sophisticated gen AI apps. Developers can be confident that Atlas Vector Search will handle high scale vector ingestion, making embeddings immediately available for accurate and reliable semantic search and RAG. Increasing the speed of experimentation, developers and data scientists can configure separate vector search indexes side by side to compare the performance of different parameters used in the creation of vector embeddings. In addition to batch embeddings, Atlas Triggers can also be used to embed new or updated source content in real time, as illustrated in the Cohere workflow shown in Figure 2. Figure 2: MongoDB Atlas Vector Search supports Cohere’s batch and real time workflows. (Image courtesy of Cohere) Supporting both batch and real-time embeddings from Cohere makes MongoDB Atlas well suited to highly dynamic gen AI-powered apps that need to be grounded in live, operational data. Developers can use MongoDB’s expressive query API to pre-filter query predicates against metadata, making it much faster to access and retrieve the more relevant vector embeddings. The unification and synchronization of source application data, metadata, and vector embeddings in a single platform, accessed by a single API, makes building gen AI apps faster, with lower cost and complexity. Those apps can be layered on top of the secure, resilient, and mature MongoDB Atlas developer data platform that is used today by over 45,000 customers spanning startups to enterprises and governments handling mission-critical workloads. What's next? To start your journey into gen AI and Atlas Vector Search, review our 10-minute Learning Byte . In the video, you’ll learn about use cases, benefits, and how to get started using Atlas Vector Search.

April 25, 2024