3 ms·

MongoDB work well ONLY if indexes (and working set) fit in the memory. What are the indexes size in the benchmark? (I doubt as I see you are running a 145GB dat

• brey 12y ago
  once you start page faulting and hitting spinning disk it's game over for any database's performance, postgres included.
  • yangyang 12y ago
    There are plenty of database that don't fit into RAM completely and are perfectly usable. It depends on what you can fit in buffer cache / OS page cache. The whole point of btree indexes is that they're efficient to query from disk.
  • Nitramp 12y ago
    ... but that usually doesn't mean you have to have your full data set in memory, only the hot parts. And even if so, one or two ~10 ms seeks during a query aren't that terrible.
    • brey 12y ago
      mongodb recommends that your working set lives in memory, not your entire database - it's generally much cheaper to add more RAM than code in any case. a few seeks aren't terrible for small/medium applications, but when you're asking for thousands of queries a second any disk access is bad news.
  • collyw 12y ago
    That sounds like bollocks. I have a script that grows a bit Perl hash. It fills up memory and starts paging. The application grinds to a halt (almost). I tie the hash to Berkly DB file, so it writes to disk. Performance is about a third of the in memory hash, BUT doesn't slow when it's too big for memory.