I would have named it something like MongoCache.
This is what happens when you rely on the OS to handle paging.
It's not a niche at all. Those are standard OS primitives.
MongoDB arrived in the gap between MySQL sucking and SSDs becoming common enough that in-memory performance wasn't essential to get simple workloads to go.
But hey none of those are important to developers. We are just stupid sheep controlled by marketing.
In my experience, MongoDB arrived with NoSQL/BigTable to fill a different set of needs than RDBMS's. Relational databases are great but not all applications need full ACID or transactions. Sometimes applications require greater data modeling flexibility. Other times, pain-free scaling/distribution are important.
MySQL is great when those features are required, but even when you put SSDs under MySQL, it's still MySQL.
Agreed; that was part of my point. Distributed KV stores are a genuine novelty over classic RDBMSes and open an important line of attack for some classes of problems.
> Relational databases are great but not all applications need full ACID or transactions.
Also agreed. As a relational bigot, however, I only begrudgingly give up those guarantees. My point about MongoDB striking at a very particular moment is important: if SSDs had been widespread in 2005, I believe NoSQL alternatives simply would not have anything like the momentum they do now. Very fast random access is a seismic shift in the algo-economics of database systems.
> even when you put SSDs under MySQL, it's still MySQL.
One of my pet peeves is that many people take the limits of MySQL for the limits of RDBMSes. It's a bit like taking the limits of small cars as the limits of all wheeled vehicles.
It so happens that I am working a project where the central model is a graph; so even an arch relational pom-pom waver like me is considering picking a NoSQL solution for it.
And who on earth uses MongoDB for caching ? I've never heard of a single company doing that.
MongoDB uses memory-mapped files across all available memory to manage data, it sacrifices ACID for speed, and its capped collections sacrifice undefined size for more speed. Its client drivers originally defaulted to fire-and-forget semantics, emphasizing its performance-oriented design. Such performance orientation is suitable for cache or cache-like needs. The general point is that its place in a system is different than that of the typical "database", whether it's SQL/RDBMS, ACID-compliant, or even document.
I'm fully aware of the MongoDB's trough of disillusionment status in the community hype cycle. 10gen brought this on by setting unrealistic expectations early on, through poor documentation and marketing. Calling it a database, a term laden in the mind of the professional developer with expectations of ACID compliance and proprietary languages, was a shortcut that ignored its atypical performance-first roots, and all of the trade-offs that followed from that. I've read more comments from people with a lack or faulty understanding of MongoDB to surmise that it's stalled in the trough because the name confuses developers. "In-memory cache with persistence" is a also shortcut, but one that is a little more circuitous and strikes a better balance.
Memcached doesn't have persistence.