Here's what we're reading this week at MongoDB:
Ashnik: “Performance degrades after migrating to MongoDB”. Really? Read this.
Diginomica: MyDealerLot boosts dealership revenue opportunities with MongoDB
DZone: Product Catalog with MongoDB, Part 1: Schema Design
DZone: Product Catalog with MongoDB, Part 2: Product Search
Forbes: Bypass The Cord, TV Viewing Shifts To The Small Screen
Paul Done's Technical Blog: Tracking Versions in MongoDB
VentureBeat: The 5 backend tools every game developer needs
MongoDB Users: Get Ready for the AWS Reboot
Over the next few days, AWS will be issuing an emergency patch , and as part of this process they’ll rebooting a substantial number of EC2 instances. The maintenance starts tomorrow and will continue until the end of the month. To see if you’ll be impacted, AWS recommends you go to the “Events“ page on the EC2 console, which will list any pending instance reboots for your AWS account. For those of you who run MongoDB on EC2, you can easily distribute your replica set nodes across multiple availability zones to help ensure that your deployment withstands outages like these without suffering any application downtime. If you have a node in an AZ that gets rebooted, your replica set will automatically fail over to a node in a different AZ. No big deal. Here’s a (non-exhaustive) AWS-reboot-preparedness checklist: Backup. We always recommend you take regular backups. This weekend especially -- make sure you have a current backup of your data before the EC2 instances get rebooted. Availability Zones. As a general practice, we recommend that you deploy replica sets across multiple availability zones. In this case, you may want to proactively change your replica sets' primaries to nodes that will not be impacted by the reboot. And if your nodes aren’t spread across availability zones, we’d suggest that you make this change now so that you have a valid voting config when the instances get rebooted. Replica Set Review. Do a once over of your replica sets to ensure that, if any given availability zone is rebooted, you have enough voting members to continue normal database operations. Some common strategies include: Adding additional secondaries to the replica set Adding an arbiter to a replica set What to Expect. When AWS reboots the instances, you should expect to see failovers occur in your replica sets. A failover typically lasts no more than a few seconds, but while it’s in progress, writes will fail and reads on the primary will fail. Once the failover process has completed, normal operation should be restored. If for some reason normal operation is not restored, MongoDB Enterprise customers should reach out to our support team; others should take advantage of our incredibly active community on Google Groups . Our support organization is on call to assist proactively in advance of the maintenance, or to respond in case of any incidents related to the reboot. And we’ve provisioned some extra folks this weekend just to be sure you have the help you need.
Considering NoSQL? Let's Break Down Your Options
Non-relational alternatives to relational databases — usually referred to as NoSQL databases — have been rapidly gaining popularity over the past decade. In 2013, MongoDB published one of our most popular white papers, “Top 5 Considerations When Evaluating NoSQL Databases.” We have since updated that paper as the technology has evolved. MongoDB is now offering a major update, which adds two new issues organizations should include in their thinking: how a database handles data generated at the edge by mobile devices and how a database fits into a broader data platform that includes search and analytics. If you’re testing the waters of NoSQL databases, then you’re probably familiar with how they’re different from traditional relational databases. The list of things you already know about NoSQL probably looks something like this: They use a different data model and query language. They have dynamic schemas. They scale horizontally. Beyond those common features, there are significant differences among NoSQL databases. The seven areas of significant differences among your options are: Data model (document, graph, key-value, etc.) Query model Consistency and transactional model APIs Mobile data Data platform Commercial support, community strength, and lock-in From MongoDB’s point of view, the most important consideration is the data model. We popularized the document model , which supports a superset of all data models, making it useful for a wide variety of applications. Key features include the ability to index and query in any field, and the natural mapping of document data structures to objects in modern programming languages. Recent shifts in how modern applications are developed and deployed — and in the experiences they offer customers — highlight the two new considerations. Mobile use cases: Mobile applications introduce the added challenge of not always being connected to the network. Developers need a solution for keeping all their customers’ apps in sync with the back-end database, no matter where they are in the world and what kind of network connection they have. The solution also needs to scale easily and quickly as more users download an app, and support the cutting edge of mobile development technologies as they evolve. Data platform: MongoDB’s application data platform provides developers a unified interface to serve transactional and operational applications alongside search, real-time, and data lake application needs. It eliminates the overhead and friction of developers having to stitch together multiple discrete technologies into a complex architecture, each creating its own duplicated data silo — connected by fragile ETL pipelines — and accessed, secured, governed, and operationalized by different APIs and tools. For a deep dive into all the differences among NoSQL databases, download our white paper, “ Top 7 Considerations When Evaluating NoSQL Databases .”