Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never, ever, ever use MongoDB

cryto.net

Post reply on HN
Print view View original

111–120 of 122 posts

Re: Never, ever, ever use MongoDB

#111

Post by btreecat »

threeseed wrote: post #44
karmakaze wrote: post #22

Now with PostgreSQL 9.4 there isn't really any reason to use MongoDB (JSONB is better suited than BSON). For any other use CouchDB.

There are a few. Mongo has excellent integration with Hadoop and is becoming very popular in the big data analytics space. Likewise it is gaining traction in the EDW space as a result of their partnerships. Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes.

>Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes.

Eh, more complex and less secure the sqlite which if you want can store json as string values and provide full text search.

Re: Never, ever, ever use MongoDB

#112

Post by rrss1122 »

joepie91_ wrote: post #20
TheHippo wrote: post #11

Or: You could just RTFM and avoid all these issues. For example: The message warning you that 32bit builds are not safe for storing more than 2GB of data is larger than the download button itself. If don't see this, you should probably be not in charge of storing any data anyways. Many other issues have been resolved with the 3.0 release or are documented very clearly.

1. There was no such warning for a long, long time. 2. It's a dumb limitation, and an architectural issue as far as I'm concerned. 3. It still doesn't justify silently throwing away data for years. 4. Many of the points on my list remain unaddressed, and likely never will be addressed. EDIT: Additionally, the typical system administrator doesn't install MongoDB from the 'Downloads' page, but uses a package manager, a…

If you're on 32-bit systems, you're even more out of luck. With the release of version 3.0, MongoDB dropped commercial support for 32-bit systems. You can still get binaries, but without commercial support they'll probably stop making those for 32-bit systems soon enough.

Re: Never, ever, ever use MongoDB

#113

Post by jqm »

bsg75 wrote: post #95
jqm wrote: post #53

I did the MongoDB class they offer but was always scared to use in production (after reading so many bad experiences). And it's really too bad. I find JSON is just so much more pleasant to deal with than SQL.

Apples and oranges. JSON is a format (Object Notation), SQL is a query language. Some databases support queries of JSON structured data using SQL.

Sure. But I'm just stating which I'd rather deal with. Not claiming equivalency....

Does MongoDB allow SQL queries? I didn't know that, but then again, I guess I don't care either. I haven't looked at Mongo in a couple of years after deciding not to use it. I do recall liking the query syntax from the class though.

I haven't messed with JSON features in PostgreSQL yet and have no idea how they work. That's next.

Re: Never, ever, ever use MongoDB

#114

Post by rdtsc »

cwyers wrote: post #110
rdtsc wrote: post #91

Earlier quoted context omitted.

Schemaless is just one aspect the other one is clustering/replication. Not sure about MongoDB but CouchDB has master-less peer to peer replication built in. That is hard to bolt-on later on top of Postgres and other databases. Just saying that is another factor in play, not just schema vs no-schema.

That's not really useful to prototyping.

Yes it is if you are prototyping a distributed service.

Unless the belief is "if it works on my laptop, it will work distributed across 50 nodes as well" is something you believe in (you shouldn't... without very good reasons).

Re: Never, ever, ever use MongoDB

#116

Post by jeremysmyth »

bsg75 wrote: post #93
cwyers wrote: post #60

Earlier quoted context omitted.

I don't understand why a schemaless database is so great for prototyping. Most of the pain from schema changes is when you have a lot of code or a lot of users depending on an existing schema, so it's hard to change (or at least, hard to change while maintaining uptime). Running ALTER TABLE on a small dataset with almost no users is trivial.

A lot of ALTER angst comes from MySQL where any table alter results in a full table lock and copy. In most other RDBMS, column addition and some type changes are a quick metadata change.

Not all: https://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-...

Re: Never, ever, ever use MongoDB

#117

Post by vhogemann »

If you're trying to use MongoDB as a relational database, and don't understand its limitations and strengths, of course it will be terrible.

MongoDB is good if:

a) Your data model fits into the document model. Usually that means you'll be querying only one collection at time.

b) The access pattern of your application is a lot of READs and few writes. MongoDB has a collection lock, so it sucks for concurrent read/write operations.

c) If you need ACID support, your operations must be restricted to a single document.

If your problem fits on the restrictions above, you probably won't run into many problems. We've been using Mongo to store our authentication info, and to store payment transactions. No major problems so far, but our needs fit nicely into what MongoDB can provide.

Most of the rants I see are from people that got burned trying to use MongoDB as a drop-in replacement for a relational database.

Re: Never, ever, ever use MongoDB

#118

Post by agnivade »

pm24601 wrote: post #66
karmakaze wrote: post #22

Now with PostgreSQL 9.4 there isn't really any reason to use MongoDB (JSONB is better suited than BSON). For any other use CouchDB.

sadly, meteor uses mongo and only mongo. And we are using meteor (which is based on node) Two levels: node and mongo == two levels of sadness. (let the flames commence)

Aah interesting, I have been planning to give meteor a spin. Any reason for supporting only Mongo ? Is it because libraries are yet to come out ?

Edit: punctuation.

Re: Never, ever, ever use MongoDB

#119

Post by derefr »

joepie91_ wrote: post #73
djacobs wrote: post #68

Earlier quoted context omitted.

I'm all for using tools that don't make bad things easy, but I think threeseed is saying that for hacks and spikes, the "later point" you're referring to might not matter. (I agree that those are the only jobs I'd use Mongo for, too.) Of course, if you're at a company where those spikes find a way of turning into production code, then it's a different story.

Realistically, though, almost always at least some portion of your hacks makes it into production. And if you're saving 10 minutes for 5 hours lost, then even at a going-into-production-rate of 10%, it's still not worth it. Hacks that remain hacks in 100% of the cases, are rare :)

I've always thought it would be a great idea to create an explicit "prototyping database" that has limitations that actually prevent you from putting it in production, no matter how small your use-case. Things like "erases random rows after 24 hours" or "default row limit of 100; can increment this by 100 once per day by solving a CAPTCHA."

Re: Never, ever, ever use MongoDB

#120

Post by djacobs »

joepie91_ wrote: post #73
djacobs wrote: post #68

Earlier quoted context omitted.

I'm all for using tools that don't make bad things easy, but I think threeseed is saying that for hacks and spikes, the "later point" you're referring to might not matter. (I agree that those are the only jobs I'd use Mongo for, too.) Of course, if you're at a company where those spikes find a way of turning into production code, then it's a different story.

Realistically, though, almost always at least some portion of your hacks makes it into production. And if you're saving 10 minutes for 5 hours lost, then even at a going-into-production-rate of 10%, it's still not worth it. Hacks that remain hacks in 100% of the cases, are rare :)

I think my experience is different from yours (I don't let spikes make it past my own branch), but as far as production goes, we're on the same page!
Post reply on HN