Getting past the startup hype, 10 things you should do with MongoDB
My company has been big into MongoDB over the past year. We’ve seen all kinds of MongoDB projects that we or our partners have worked on, so I figured it was worth stuffing them into a top 10 list, with the intent to enlighten those who still want to know which tasks might be best handled by the document flavor of NoSQL databases. The jobs we’ve encountered break down along the following lines.
1. Profiles of people
Yes, LDAP is fine for identity when you’re authenticating or authorizing, but what about profiling things or people that aren’t strongly associated with the system? What about criminal records or child support suspects or customer rewards? What about users of promotions and what they clicked on? There’s always new data to add to the user’s profile, from the usual top-level stuff (phone, address, email, etc.) to information a layer below (i.e., phone type). Other database types haven’t evolved fast enough to capture the hundred ways we contact each other or the dozens of ways we pay for things.
2. Product/catalog data
Way back when, I worked for a cell phone manufacturer (or two) and later a chemical company. Each had a weird version of the same problem: Products were composed of other products, and which products those were composed of changed over time and tended to have more than one brand or identifier. Capturing the thing that contains the thing that contains the thing is much simpler in a document database than in some other database types.
3. Geospatial data
This isn’t necessarily because MongoDB is a great document database, but because it has specific geospatial features. Either way, MongoDB is your friend, whether you’re calculating your bike ride distance or figuring out geospecific information about your customers.
4. Funds, mutual funds, etc.
The finance industry is complicated, so don’t make it more complicated than it needs to be. Investment vehicles often are composed of other investment vehicles, which are then composed of other investment vehicles. Whether this is a “bandwidth” fund or a mutual fund or a fund of funds, if you’re trying to perform while flattening the data out, you may suffer. Heck, the industry is full of documents that contain documents that contain documents, so why not use a document database?
5. Metadata
As Forrest Gump said, “it happens,” and then you have lots of it. You need to categorize and say what “it” is like. MongoDB does this well. There are other database types that will also work (i.e., graph databases), but MongoDB is a fine choice.
6. Talk
People are social creatures, and over the last decade or so we’ve generated exabytes of social data. Mongo is a fine choice to handle the load. Often, people talk topically, with a lot of associated metadata. MongoDB is good for storing that too.
7. Content
They don’t call MongoDB a “document” database for nothing. It’s great for serving up text and HTML, as well as for storing and indexing content and controlling its structure.
8. Games
You have to water those flowers or serve those restaurant patrons or grow your vegetables or kill zombies or whatever. Games have goals, which consist of multiple objectives obtained through achievement or paying your way out. Whether it’s a titanium rake or a BFG 9000, MongoDB can handle the concurrency and save the (often multi-level) data.
9. Events
MongoDB may not be the only game in town with regards to event logging, but it’s a perfectly good choice that won’t slow you down.
10. Bills/invoices
Orders have line items containing product data. The order is also sent to a location and billed to another location. This is how it is and always has been. Orders also progress through many states. You might freak over the idea of a NoSQL database doing “transactions,” but Mongo can perform these as discrete operations if you’ve properly designed your document. MongoDB can handle the concurrency, can efficiently “add one more,” and can track the changes as the bill of sale moves through the system.
What kinds of projects are you doing with MongoDB? Where have you found it to be perfectly suitable, and where have you decided something else was better? Let me know in the comments.
