Ask HN: Why use MongoDB? I have given three chances to mongodb. Not fill my expectations, in the end for me there will be a need for a join or complex queries. I have tried to use it in 4 projects and does not convince me. Can anyone give me a reason other than replication to use it |
If you are using Node you should use Mongoose and then you may see why some people love Mongo. Complex queries and joins (not technically called joins I guess) are incredibly easy to accomplish with that module[1]. Personally, I have migrated back to MySQL since I was unable to convince my colleagues that Mongo would last long-term and frankly I am not 100% confident either for the kind of business applications that we need[2].
[1]: http://mongoosejs.com/docs/populate.html
[2]: payment processing industry handling billions of records
My experience with ORMs has not been pleasant either but Mongoose was very, very nice.
Essentially you end up with an a lot of linking by item IDs as you would with a traditional relational database but the "eventual consistency" was where I thought there may be issues in the future.
I personally never saw problems stemming from this but my projects using MongoDB never really even hit a million objects in a single collection (not 100% sure on that). Again, at scale is where I'd lose confidence.
This is entirely speculation but when it comes to critical infrastructure I can't leave anything to chance.
But I didn't use joins, nor was this anywhere near a production server. From my understanding, if you have a heavy requirement for joins then you just shouldn't be using MongoDB in the first place. It isn't a traditional relational database.
- flexible document schema reduces migration complexity greatly, really important when we have our software deployed on many customers sites. - flexible schema is also important to our product because we support custom forms and fields. - the ability to store and search nested data - replication is easy to setup - easy to maintain, good export formats - no dependence on customer's DBAs - no more frustrating explain-plan debugging of underperformant joins - text search (simple yet useful) - regex support - fast, up to 3x faster than SQL based engines for our use cases. - works well as a cache - decent also as a work queue with tailable capped collections.
Our biggest complain: the lack of transactions combined with data denormalization pitfalls is a PITA to work around in code.
Overall just a great db for when you need a flexible schema.
And if I want to attach non-kv data like last_updated, or have foreign key relationships between one dict() and some other stuff like the corresponding user record's primary key - it's already in an RDB.