5 ms·

MongoDB is not a particularly good database. But it is a pretty good in-memory cache that can persist to disk, which is a valuable technical niche. It's a small

by mcgwiz 13y ago

MongoDB is not a particularly good database. But it is a pretty good in-memory cache that can persist to disk, which is a valuable technical niche. It's a small change in perspective (that is betrayed by their marketing) but has a huge impact on expectations, use and value. I would have named it something like MongoCache.

deleted 13y ago
[deleted]
nasalgoat 13y ago
Actually, it's a really poor in-memory cache, since it pages back and forth to disk constantly.
- mcgwiz 13y ago
  No one's arguing that disk paging is high-performance. In fact, MongoDB themselves explicitly recommend that you keep your working set size below physical memory size.
  - nasalgoat 13y ago
    Our data is 1/10th of available memory and MongoDB still pages back and forth to disk constantly. This is what happens when you rely on the OS to handle paging.
RSASecure 13y ago
I would stick to in memory cache solutions like redis, memcache over mongo
- tracker1 13y ago
  Depending on your needs, mongo has a much nicer interface than redis... Not to mention supporting indexing in the DB instead of having to DIY your own... I used it at a site that did mostly classified listings, and the performance was a lot better than the SQL RDBMS that was being used for search/display.
- mcgwiz 13y ago
  Yes, I agree. But regarding my comment, the use case was caching with persistence. Redis has some persistence options (pure snapshot or pure journal), but they just aren't its primary use case and aren't nearly as mature or performant as MongoDB's memory-mapped filing. Also Redis is key-value so requires manual indexing, i.e. much more up-front developer effort. Memcached doesn't have persistence.
jacques_chester 13y ago
> But it is a pretty good in-memory cache that can persist to disk, which is a valuable technical niche 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.
- jeltz 13y ago
  MongoDB has quite poor in-memory performance due to its simplistic locking strategy. I personally think MongoDB only had the best marketing of any NoSQL database.
  - threeseed 13y ago
    MongoDB is also incredibly ease to install, use, manage and understand. But hey none of those are important to developers. We are just stupid sheep controlled by marketing.
    - gaius 13y ago
      Because when you chuck it over the fence to ops, it's not your problem any more, right?
- mcgwiz 13y ago
  Yeah, memory-mapped files and journaling are standard OS primitives. I would say auto-sharding, replication, indexing, and complex schema-less querying are not. 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.
  - jacques_chester 13y ago
    > I would say auto-sharding, replication, indexing, and complex schema-less querying are not. 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.
icedchai 13y ago
you can write a "cache that persists to disk" in a few lines of C code. ever hear of memory mapped files ?
- johnbellone 13y ago
  That with a little bit of Fortran can get you in a big world of hurt.
- mcgwiz 13y ago
  I'm confused. You do realize that MongoDB uses memory mapped files for managing and interacting with all data...
  - icedchai 13y ago
    Yes, I realize this. My point is that it's not a "technical niche", it's something nearly anyone can do, and has been able to do, for decades.
threeseed 13y ago
MongoDB is a great database if you have a domain model that is more document driven. And who on earth uses MongoDB for caching ? I've never heard of a single company doing that.
- mcgwiz 13y ago
  Sorry, I guess, that you haven't heard of teams caching denormalized data in MongoDB... 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.

by mcgwiz 13y ago

deleted 13y ago

[deleted]

nasalgoat 13y ago

Actually, it's a really poor in-memory cache, since it pages back and forth to disk constantly.

mcgwiz 13y ago
No one's arguing that disk paging is high-performance. In fact, MongoDB themselves explicitly recommend that you keep your working set size below physical memory size.
- nasalgoat 13y ago
  Our data is 1/10th of available memory and MongoDB still pages back and forth to disk constantly. This is what happens when you rely on the OS to handle paging.

RSASecure 13y ago

I would stick to in memory cache solutions like redis, memcache over mongo

tracker1 13y ago
Depending on your needs, mongo has a much nicer interface than redis... Not to mention supporting indexing in the DB instead of having to DIY your own... I used it at a site that did mostly classified listings, and the performance was a lot better than the SQL RDBMS that was being used for search/display.
mcgwiz 13y ago
Yes, I agree. But regarding my comment, the use case was caching with persistence. Redis has some persistence options (pure snapshot or pure journal), but they just aren't its primary use case and aren't nearly as mature or performant as MongoDB's memory-mapped filing. Also Redis is key-value so requires manual indexing, i.e. much more up-front developer effort. Memcached doesn't have persistence.

jacques_chester 13y ago

> But it is a pretty good in-memory cache that can persist to disk, which is a valuable technical niche 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.

jeltz 13y ago
MongoDB has quite poor in-memory performance due to its simplistic locking strategy. I personally think MongoDB only had the best marketing of any NoSQL database.
- threeseed 13y ago
  MongoDB is also incredibly ease to install, use, manage and understand. But hey none of those are important to developers. We are just stupid sheep controlled by marketing.
  - gaius 13y ago
    Because when you chuck it over the fence to ops, it's not your problem any more, right?
mcgwiz 13y ago
Yeah, memory-mapped files and journaling are standard OS primitives. I would say auto-sharding, replication, indexing, and complex schema-less querying are not. 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.
- jacques_chester 13y ago
  > I would say auto-sharding, replication, indexing, and complex schema-less querying are not. 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.

icedchai 13y ago

you can write a "cache that persists to disk" in a few lines of C code. ever hear of memory mapped files ?

johnbellone 13y ago
That with a little bit of Fortran can get you in a big world of hurt.
mcgwiz 13y ago
I'm confused. You do realize that MongoDB uses memory mapped files for managing and interacting with all data...
- icedchai 13y ago
  Yes, I realize this. My point is that it's not a "technical niche", it's something nearly anyone can do, and has been able to do, for decades.

threeseed 13y ago

MongoDB is a great database if you have a domain model that is more document driven. And who on earth uses MongoDB for caching ? I've never heard of a single company doing that.

mcgwiz 13y ago
Sorry, I guess, that you haven't heard of teams caching denormalized data in MongoDB... 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.