Q: Web applications, right?
A: Well, no, because in MongoDB there's nothing that's that specific to Web apps. Conceptually, it's a general-purpose database. True, the early adopters were from the Web, But I think people use it for everything: for content management systems, for personalization systems, for streaming mobile. They use it for Web, but also for accounting stuff and on the offline analytic side, where you have large repositories of historical data. It's pretty broad.
Q: Are there certain common characteristics of these enterprise apps? You make it sound like a hodgepodge.
A: It's very broad. It's kind of like if we were to ask: What's the use case for Oracle RDBMS? I can give you a good answer, but it might be a long answer. A document database certainly works well when the shape of the data fits with document-oriented data models, either from the programming languages or the types of columns or the datasets you're dealing with.
For example, one telco wrote a product catalog application for their company, a giant company with 100,000 products. Some of them are phones, some of them are extended warranties, and some of them are service plans. They have all these different properties to their products. They found it was very easy to do that with MongoDB because of the way the data model works. That's a nice example of a use case.
I think some other sweet spots would be the back end to content management applications, lots of usage for mobile applications, lots of usage for online applications that need an operational data store that's real time, with tens of thousands of reads and writes per second.
I think one area where it would not be used would be for supercomplex transactions, nor would it be a good fit when you have legacy requirements for SQL or UVC, for example.
Q: At the CIO level I think there's probably a widespread perception that NoSQL is no good for transactions at all. Would you like to give the counterargument to that?
A: It depends on the product. Different products have different consistency models. MongoDB is a little bit more in the strong consistency view of the world. In MongoDB you can do atomic operations on individual JSON documents, and those documents can be quite rich. That's your transactional scope. Within a single document, if you want to debit A and credit B, as a transaction, you can do that. However, you can't do that across documents.
We'd like for you to be able to do that, but the problem is that in distributive transactions that are fully generalized on 1,000-server clusters, it's very, very hard to make those fast. So what we've done is ... we're giving you what we can make fast. It turns out that will get you pretty far, especially if you take into consideration that you're getting the schema design. I find that in 75 percent of use cases there's a mass transactionality that ends up being a great way to solve a problem. But there's some minority where you would say: No, I want something different.
If there are 20 requirements for a project, the classic database would be superstrong on the distributive transaction requirement, but then it's going to be weaker on some of these other things, like ease of the data mapping and speed and scale, for example. You have to kind of sum it up and kind of decide what's the right product for the right use case.