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

The genius and folly of MongoDB

nyeggen.com

Post reply on HN
Print view View original

201–210 of 280 posts

Re: The genius and folly of MongoDB

#201

Post by edvinbesic »

CoffeeDregs wrote: post #198
edvinbesic wrote: post #193

Earlier quoted context omitted.

This is a pretty silly argument. The people whom it affects are not people buying cars, it's more like launching a shuttle mission, at which point I would assume you have read the f*ing manual.

Grandparent seems to make a valid argument. it's more like launching a shuttle mission Given how much we spend time talking about MVPs, Lean Startup, etc, I think people on this site are trying to avoid launch a shuttle mission. [Often] They're looking at building startups and are looking for both time-tested and new-but-advantage-providing technologies and techniques. At first glance, MongoDB appears to be advantage…

I agree, but if you reach that point isn't that one of those good problems to have?

Re: The genius and folly of MongoDB

#203

Post by nawitus »

patrickod wrote: post #43
nawitus wrote: post #31

So, what's a good NoSQL database for e.g. node.js use? The only alternative I know of is CouchDB. (Yes, I should give more parameters about the intended use, but I really don't know any alternatives).

I'm unsure why you say there are no other alternatives. Surely the choice of database should preference your data and what you want to do with it over the language you'll use? There are node libraries for any database I've ever wanted to use (SQL and NoSQL alike)

I tried to say 'no NoSQL alternatives'. And I noticed that while there's node middleware for most libraries, the ease of use is different for each database.

Re: The genius and folly of MongoDB

#204

Post by victorhooi »

clwk wrote: post #187
functional_test wrote: post #179

Earlier quoted context omitted.

I would also read the manual of a car I just bought before driving it. I guess that's just my style. Don't get me wrong, I'm not saying your assumption is unreasonable. But in the end, it's on you as a conscientious developer to read the documentation. I'm not even suggesting cover to cover - in this case though they are very up front about write concerns. There is no real excuse to find this out any other way, it's…

Out of curiosity, have you ever bought a car, and did you actually read the whole manual before driving it? It's a nice hypothetical, and that might be your style. Most real-world car purchase scenarios I'm familiar with would make that style impractical.

Yes, whenever I buy a car, I read the manual. If it's second-hand, I download the manual.

Heck, even when I have a rental car for a single day, I will read the manual. Maybe not every page, but I will skim it for gotchas (and if I have time, the whole thing).

Maybe it's just the engineer in me, but it's what I do.

Come on guys, as computer engineers/programmers/developers/whatever, surely professional pride at least would mean we at least read the README and/or the manual, before putting something into production?

Re: The genius and folly of MongoDB

#205

Post by [deleted] »

chaffneue wrote: post #139
rdtsc wrote: post #106

The problem with MongoDB is their shadiness. The shipped with unacknowledged writes up until not too long ago. In other words you would write to it and there wouldn't be an ok or fail response, you'd just sort of hoped it would go in. They fixed that problem but it was too late. In my eyes they proved they are not to be trusted with data. Had they called themselves MangoCache or MongoProbabilisticStorage, fine, can s…

And it's not even good or recommended as a cache at any kind of profile. So I guess their most valuable niche is low traffic/prototype sites with poor architecture discipline or genuinely unrelated data sets. There are so much better tools for caching (memcached/redis), durable persistent storage (postgres), session storage (memcached/redis/browser hybrids) and document storage (postgres). Mongo is just one of those…

[deleted]

Re: The genius and folly of MongoDB

#206

Post by joeblau »

One thing I always do is try to scope a database for the problem. This site[1] has been a valuable resource for myself and colleague who were evaluation the best way to store/access our data depending on what we need back.

[1] - http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Re: The genius and folly of MongoDB

#207

Post by aaronem »

edraferi wrote: post #189
aaronem wrote: post #173

Earlier quoted context omitted.

That gets you halfway there, but you still don't have the ability to query your datastore by structure, unless you've installed PostgreSQL 9.3 and are using its JSON field type, which does have that capability, thus entirely demolishing the NoSQL USP as far as I can determine.

That is awesome.

Also of note is that stored procedures are supported in a variety of languages, including Javascript, so it's quite easy to handle cases where the surprisingly broad range of core JSON functions and operators [1] doesn't include what you need.

PostgreSQL has also recently added a key-value store type [2] with semantics reminiscent of Redis. The impression I get is that they're gunning for the NoSQL kids in general, and this pleases me; while I grant it is sometimes possible and necessary to obtain new insight in a field by ignoring all that's gone before, I very much doubt this is one of those times, and I am therefore delighted to see a properly engineered database engine gain more or less the entirety of the features which draw interest to the NoSQL crowd in the first place.

[1] http://www.postgresql.org/docs/9.3/static/functions-json.htm... [2] http://www.postgresql.org/docs/9.3/static/hstore.html

Re: The genius and folly of MongoDB

#208

Post by sitkack »

sargun wrote: post #136
EGreg wrote: post #129

Earlier quoted context omitted.

I think they are upset with their marketing, like "web scale". Even the name "Mongo" is derived from "Humongous" -- but that's exactly the scale at which you'd switch away from Mongo. Reminds me of this: http://www.youtube.com/watch?v=URJeuxI7kHo Want NoSQL? Use RIAK!

Riak also has massive problems. Realistically, figure out your data that you want to stick in a database, why, and how you're going to query it, and then work from there.

And those are what?

Re: The genius and folly of MongoDB

#209

Post by codeflo »

edvinbesic wrote: post #201
CoffeeDregs wrote: post #198

Earlier quoted context omitted.

Grandparent seems to make a valid argument. it's more like launching a shuttle mission Given how much we spend time talking about MVPs, Lean Startup, etc, I think people on this site are trying to avoid launch a shuttle mission. [Often] They're looking at building startups and are looking for both time-tested and new-but-advantage-providing technologies and techniques. At first glance, MongoDB appears to be advantage…

I agree, but if you reach that point isn't that one of those good problems to have?

Losing your data is never "I good problem to have". Even for a small startup, such a thing can easily kill all the momentum you've built up.

Re: The genius and folly of MongoDB

#210

Post by annnnd »

rdtsc wrote: post #169
functional_test wrote: post #126

Earlier quoted context omitted.

I understand some of the reasons people didn't like Mongo, but this always vexed me. The default write level was very clearly documented and you could always change it as necessary. Surely it would be necessary to read the documentation of a database before rolling it out to production?

> Surely it would be necessary to read the documentation of a database before rolling it out to production? You buy a car. It comes with brakes disabled because for whatever reasons that also lets it get to a higher top speed. You are expected to read you car owner manual and on page 54 you find that you have to hold "enable brakes" button under the console for 10 seconds to turn on your brakes. Would it vex you that…

I like your analogy, very fitting. To their defense however they are far from the only ones to do that... I lost about 2h worth of production data with HBase in just the same way - fortunately I didn't want to trust it completely anyway and had my own logs of all transactions on filesystem, but it definitely shattered my trust in that DB (not to mention it was a pain to setup and had no secondary indexes).

I use MongoDB now in production and I am happy about it. Not huge dataset by any means so MongoDB fits the bill perfectly. It has a few idiosyncrasies (doesn't release disk space after deleting records - what?!?) and you definitely want to read the manual on settings. But it is incredibly easy to use (documents instead of relational data) and allows me to focus on app development instead of my storage backend.

Post reply on HN