Seriously, another case of using Mongo incorrectly? I want to believe all the Mongo hate, but I can't because I always find out that the actual problem was one or more of:<p>* didn't read the manual<p>* poor schema<p>* didn't maintain the database (compactions, etc.)<p>In this case, they hit several:<p>" Its volume on disk is growing 3-4 times faster than the real volume of data it store;"<p>They should be doing compactions and are not. Using PostgreSQL does not avoid administration; it simply changes the administration to be done.<p>"it eats up all the memory without the possibility to limit this"<p>That's the idea -- that memory isn't actually used though; it's just memory mapping the file. It will swap out for something else that needs the space unless you are actively using all the data, in which case you really are using all your memory. Which is why you should put it on its own server...<p>"it begins to slow down the application because of frequent disk access"<p>"Finally we sleep quietly, and don’t fear that mongodb will drive out redis to swap once again."<p>You should be running Mongo on a server by itself. At the very least, if you're having disk contention issues, don't run it on the same server as your other database.<p>I'm not sure you always need to read the manual for everything, but for your production database, it's probably worth it.
Maybe I am just incredibly lucky, but mongodb has worked fine for ridewithgps.com - we are sitting at 670gb of data in mongo (actual DB size, indexes included) and haven't had a problem. Replica sets have been fantastic, I wish there was another DB out there that did auto-failover as cleanly/easily as mongo does. We've had a few server crashes of our primary, and aside from 1-2 seconds or so of errors as requests come in before the secondary is promoted, it's transparent.<p>With that being said, we are using it to store our JSON geo track data, most everything else is in a mysql database. As a result we haven't run into limitations around the storage/query model that some other people might be experiencing.<p>Additionally, we have some serious DB servers so haven't felt the pain of performance when exceeding working memory. 192gb of ram with 8 RAID10 512gb SSDs probably masks performance issues that other people are feeling.<p>Final note: I'll probably be walking away from mongo, due to the natural evolution of our stack. We'll store high fidelity track data as gzipped flat files of JSON, and a reduced track inside of postgis.<p>tl;dr - using mongo as a very simple key/value store for data that isn't updated frequently, which could easily be replaced by flat file storage, is painless. YMMV with other use cases.
The title is a bit misleading. This is basically an announcement of a fork of Errbit that has Postgres support. Additionally, the fork was announced as an issue on errbit with no discussion or as an official pull request.<p>I would not consider this good etiquette. If you fork your project (especially without discussing the intention first), adding a bug to the original project isn't a very nice thing to do.<p>An official pull request would be nicer or, even better, don't bother the original project, but just announce your fork over other channels.<p>Even better would be to at least discuss the issue with the original project - maybe they agree and you can work together.
Lets just say that PostgreSQL answers the criticisms of relational databases that led to NoSQL. The complaints all boiled down to saying that the RDBMS forced you to do things one way and that it was cumbersome. PostgreSQL evolved and fixed the most annoying issues like JSON support and schemaless key-value store support. That's the way open source is supposed to work. Now folks are learning that throwing out the baby with the bathwater leads to more complexity than just learning how to use a relational database. The pendulum has swung back.
The hstore enhancements coming in psql 9.4 will pretty much put mongo out to pasture.<p>"Mongodb" already nearly exists as a single column type, 9.4 will complete it.
All the philosophical issues and /(No)?SQL/ discussions aside, as a heavy user of Postgres and a user of Errbit, this is very good news to me. I have not much experience with running Mongo, but I have a ton of experience with running Postgres.<p>Even better: The application I'm using Errbit the most for is already running in front of a nicely replicated and immensely powerful postgres install.<p>Being able to put the Errbit data there is amazing.<p>This is some of the best news I've read today :-)
If you want to use MongoDB in a project and you don't intend to rely heavily on the aggregation framework, the consider TokuMX (<a href="http://www.tokutek.com/products/tokumx-for-mongodb/" rel="nofollow">http://www.tokutek.com/products/tokumx-for-mongodb/</a>) as it alleviates many of the shortcomings of MongoDB (data compression, document level locking for writes, ...) + it adds transactions.<p>It's a drop in replacement so it will work with current drivers. (if you have a running mongo cluster however expect quite some work if you want to migrate)<p>(I have no affiliation with TokuTek whatsoever except that I use their product)
I'm no MongoDB expert, but recently started to look into this db. Can anyone tell me (from experience, not from promo materials) - for which use cases MongoDB is good fit and for which ones it's not? It's clear that it can't fit for everyone. That's why it would be good to know in advance, for what it most likely to find and for what it's most likely not to fit.
Their use case didn't seem especially Mongo-centric, I wonder why they chose to go down the road.
We used MongoDB TokuMX to improve performance:
<a href="http://www.tokutek.com/resources/benchmark-results/tokumx-benchmark-hdd/" rel="nofollow">http://www.tokutek.com/resources/benchmark-results/tokumx-be...</a>
> Finally we sleep quietly, and don’t fear that mongodb will drive out redis to swap once again.<p>Well duh, Mongo was designed to live on its own server as it tries to claim all of the free memory available. Putting it on the same server with Redis makes no sense.<p>The case that caused you sleepless nights does not apply to 99% of projects out there.
In case you missed it, this submission is not about PostgreSQL vs MongoDB. It's about the crazy GIF parade in the comments interleaved with thumbs up emojis. You don't see such stuff often on github :)
This just makes me wonder why they chose Mongo in the first place. It sounds like they didn't really consider their needs when initially choosing databases. Mongo has some benefits that when properly implemented far outweigh the negatives. At the same time, it's still relatively young, and doesn't have the "maturity of process" that makes older SQL engines so easy to manage/implement. Eventually, I'm sure, Mongo will solve these issues and be a great database for those who need to utilize its many virtues.
"Its volume on disk is growing 3-4 times faster than the real volume of data it store[sic]"<p>Are they saying that it has a high constant overhead to the data, or are they saying the storage grows in a super-linear fashion?
Anyone compared MongoDB with other document stores, e.g. with <a href="https://github.com/triAGENS/ArangoDB" rel="nofollow">https://github.com/triAGENS/ArangoDB</a> ?
Does anyone have a recommendation for an authoritative guide to either Postgres or Mongodb? One that does more than show you where the levers are, that is.