NoSQL For Dummies (2015)
Part IV. Document Databases
Chapter 18. MongoDB
In This Chapter
Working with open-source software
Supporting MongoDB
MongoDB is the poster child for the NoSQL database movement. If asked to name a NoSQL database, most people will say MongoDB, and many people start with MongoDB when looking at NoSQL technology. This popularity is both a blessing and a curse. It’s obviously good for MongoDB, Inc. (formerly 10gen). On the flip side, though, people try to use MongoDB for purposes it was not designed for, or try to apply relational database approaches to this fundamentally different database model.
MongoDB is a good NoSQL document database with a range of features that, in the open-source NoSQL world, are hard to beat. Starting your NoSQL career with MongoDB is a good approach to take.
In this chapter, I describe how MongoDB can be used, and where support can be found for your own implementation.
Using an Open-Source Document Database
Some companies can’t afford to purchase commercial software, support, or consulting, at least at the outset. If this describes your company, you may want to start with the free open-source version of MongoDB, which you can find at https://www.mongodb.org/downloads.
MongoDB’s use of the GNU Affero General Public License (AGPL) v3.0 means that anyone can download the software source code, compile it, and use it to provide a database service, either for her own applications or as a shared public cloud computing service.
Doing so reduces the costs and complexities of adopting MongoDB. Several cloud providers on Amazon and Azure offer hosted MongoDB database services.
MongoDB’s core database code is available under the GNU AGPL v3.0 license. MongoDB is unique in using this particular license. This differs from the standard GNU GPL in ensuring that, if a modified version of MongoDB is created and run on a public service (for example, in the Amazon or Azure clouds), then the source code for that modification must be released back to the community under the same GNU AGPL v3.0 license. Some commercial companies may find this requirement problematic, because it may prevent them from producing their own enhanced MongoDB and making it available as a unique commercial service on the public cloud.
Handling JSON documents
MongoDB natively handles JSON documents. Like XML, JSON documents’ property names can be quite verbose text. MongoDB uses its own BSON (short for Binary JSON) storage format to reduce the amount of space and processing required to store JSON documents. This binary representation provides efficient serialization that is useful for storage and network transmission.
This internal operation is handled transparently by the client drivers and MongoDB. Developers never need to worry about this implementation detail.
Finding a language binding
One of the main strengths of MongoDB is the range of official programming language drivers it supports. In fact, it officially supports ten drivers. These drivers are released under Apache License v2.0, allowing you to extend the drivers, or fix them as needed, and to redistribute the code.
Also, more than 32 unofficial drivers (the code is not reviewed by MongoDB) under a variety of licenses are available, which is by far the most language drivers I’ve come across for any NoSQL database.
Whether you want a modern-day or older esoteric programming language, MongoDB probably has a language binding for you, as shown here:
· Official: C, C++, C#, Java, Node.js, Perl, PHP, Python, Ruby, Scala
· Unofficial: ActionScript 3, Clojure, ColdFusion, D, Dart, Delphi, Entity, Erlang, Factor, Fantom, F#, Go, Groovy, JavaScript, Lisp, Lua, MATLAB, Node.js, Objective C, OCaml, Opa, Perl, PHP, PowerShell, Prolog, Python, R, REST, Ruby, Scala, Racket, Smalltalk
If your language binding isn’t mentioned in the preceding list, then you really are using something rare and wonderful for your applications!
Effective indexing
Storing data is one thing, finding it again is quite another! Retrieving a document using a document ID, or (primary) key, is supported by every NoSQL document database.
In many situations, though, you may want a list of all comments on a web page or all recipes for puddings (my personal favorite!). This requires retrieving a list of documents based not on their key but on other information within the document — for example, a page_id JSON property. These indexed fields are commonly referred to as secondary indexes. Adding an index to these fields allows you to use them in queries against the MongoDB database.
In some situations, you may want to search by several of these fields at a time, such as for all pudding recipes that contain chocolate but are gluten free. MongoDB solves this issue by allowing you to create a compound index, which is basically an index for all three fields (recipe type, ingredients, is gluten free), perhaps ordered according to the name of the recipe.
You can create a compound index for each combination of query fields and sort orders you need. The flip side is that you need an index for every single combination. If you want to add a query term for only five-star recipes, then you need yet another compound index, maybe several for different sorting orders, too.
Other document NoSQL databases (MarkLogic Server and Microsoft DocumentDB) and search engines solve this matter by allowing an intersection of the results of each individual index. In this way, there’s no need for compound indexes, just a single index per field and a piece of math to perform an intersection on each index lookup’s document id list. This approach reduces the amount of administration required for the database and the space needed for the index on disk and in memory.
You also need to think about how to structure your documents so that you can create effective indexes for querying. MongoDB, in true NoSQL style, doesn’t support cross-document joins, which means that your document structure must contain all the information needed to resolve a query. Essentially, you construct your documents to look like the “answers” you’re looking for. The process of merging information to provide effective answers is called denormalization and is a key skill required for working with NoSQL databases.
MongoDB doesn’t support a universal index — you need to manually configure every index. In its 2.6 version, MongoDB introduced basic geospatial support through the adoption of the GeoJSON standard.
Likewise, advanced full-text searches aren’t supported in MongoDB. A common pattern is to integrate the Solr search engine with MongoDB (see Part VI of this book for details on Solr). This provides eventually consistent full-text searches of your documents. However, in this case, you must write part of your application according to MongoDB’s programming API and part in accordance with Solr’s. If, however, you need full-text indexing in MongoDB, this is the approach to take.
Finding Support for MongoDB
MongoDB, Inc., is the commercial company behind most of the development and innovation of the MongoDB NoSQL database, and it is one of the largest NoSQL companies in terms of investments, raising $150 million through October 2013.
This funding round was purely to improve MongoDB and help it become an enterprise-class product ready for high-end mission-critical workloads. So far, MongoDB has added geospatial search and started improving support for index intersection and security. MongoDB has also added a database write journal to ensure data durability in the event of a system failure.
Over the next two to three years, we should begin seeing better database locking, fully composable search indexes, and security permissions at the document level. At the moment these are lacking in MongoDB.
MongoDB in the cloud
MongoDB, Inc., provides advice on running MongoDB on a wide variety of cloud platforms, which isn’t surprising because MongoDB emerged from the 10gen company’s cloud application requirement.
MongoDB supports the following public cloud platforms:
· Amazon EC2
· dotCloud
· Google Compute Engine
· Joyent Cloud
· Rackspace Cloud
· Red Hat OpenShift
· VMWare Cloud Foundry
· Windows Azure
There is, of course, nothing stopping you from downloading MongoDB and installing it on your private cloud. This, too, is supported.
Licensing advanced features
Not all functionality is available on the free download version of MongoDB. If you want any of the following functionality, you must buy MongoDB Enterprise from MongoDB, Inc.
· MongoDB Management Service (MMS): Enables disaster recovery replication to a second cluster and is a systems monitoring tool.
· Security integrations: Includes Kerberos, LDAP authentication, and auditing.
· Enterprise software integration: Integrates MongoDB with your organization’s monitoring tools through SNMP (Simple Network Management Protocol).
· Certified operating system support: Includes full testing and bug fixes for operating systems.
· On-demand training: Provides access to online training portal.
· 24/7 support: Includes software support and bug fixes.
· Commercial license: Enables you to use MongoDB as an embedded database in a commercial product or service you sell.
In practice, disaster recovery replication to a second or subsequent site is required for enterprise application software. If you’re a large enterprise thinking about betting part of your business on a NoSQL document database, you need disaster recovery replication, which means forking out the money for an Enterprise License Agreement.
Ensuring a sustainable partner
MongoDB, Inc., now has the funding required to improve its product and market it to organizations worldwide. With offices all over the globe, you can find official support locally, specific to your needs when using MongoDB, including regular health checks, presales architecture and deployment advice, and expert consulting services, all for a significant price, of course. If you’re working on your first major project, this advice can be invaluable. For example, it can help you spot ways to apply best practices and avoid common pitfalls.
As a principal sales engineer, I know how valuable early-stage consulting advice is. You may need only 20 days of consultancy over a year’s time, but it helps ensure a successful project. It’s also generally a good idea to have a health check a few months after you go live because estimates on the size requirements of systems never exactly match their scale of actual predicted use, or growth of use. So, it’s best to do an early-stage tweak of a few post-deployment settings in order to tune your database appropriately. For this, expert advice is best — so buy a few of those consultancy days.
The document NoSQL database landscape is now in prime time. With IBM buying Cloudant and Microsoft building DocumentDB — from scratch — it’s clear that these types of databases are the most valuable applications of NoSQL technology.
With the entry of the big boys of IBM and Microsoft, and Oracle with its NoSQL key-value store, competition will begin to get tight. The market is no longer immature and full of startups competing for cutting-edge customers.
Enterprise capabilities and rich functionality that help reduce development and administration costs will become increasingly important, as will security, data durability, consistency, and systems monitoring.
MongoDB must meet the expectations of investment groups providing it with funding. It will be interesting to see how MongoDB reacts to competition from IBM Cloudant and especially Microsoft’s DocumentDB. DocumentDB seems aimed squarely at providing just a little more than MongoDB does, but of course at a commercial software price.
For now, though, MongoDB’s status as a leading document NoSQL database vendor, along with the others I discuss in this part of the book, is assured. With a large installation base, the ability to be installed in private clouds, and many experienced developers on the market, MongoDB will be hard pressed to be surpassed by Microsoft for a while yet.