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 brands that quickly solved a problem that most of the better technologies missed - the user interface.

I think being able to have flexible data storage with indexing is where they are better than most other options. There's something to be said for some of what they do offer. I was able to replace the search system for a site that used SQL to MongoDB, which often includes geolocation, it works fairly well, I had considered using a ElasticSearch, or something similar, Mongo was a better fit.

Today, I would be inclined to use PostgreSQL with JSON support, and some triggers to update an aggregate search table, or look more seriously towards RethinkDB.

With any NoSQL system you give up something.. you just need to be aware of what you are giving up, why and for what gains.

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 people might be slightly critical of that car. Clearly they are silly for not reading their car manual until page 54.

That "feature" is not something that should be discovered by reading docs or when you get a crash and then load a backup from another week and still get a crash and then you start hitting your head on your desk.

Anything calling itself a "database" should not have shipped with those default settings _ever_. If they did they might have gotten away with it in my book by having a big flashing red warning on the front or download page. I don't remember one.

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 just negligence.

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.

Literally 1 month ago, I bought a car and did exactly this. What's impractical about spending a little time to read?

What is impractical is that something like brakes not working is not something you want to find in the manual on page 54. You don't want the car to start without that feature unless you enter a special code, and confirm you know what you are doing.

A database that has default configured that ends up corrupting users' data silently is like buying a car with the brakes disabled.

Well except that in the car case may brakes disabled won't make the car go faster, but in case of MongoDB I remember fans strutting write benchmarks around comparing it to Postgres, Couch and other database and telling how it is webscale. The reason that design decision was made is shady. That was my initial point.

Your approach is wholly impractical on its face, actually.

So, let me get this straight: You laid down tens of thousands of dollars on a vehicle that you only post-purchase read the manual of, and you're raising this as some sort of standard people should follow?

Honestly, asking the right questions (and test-driving) upfront should be what lands the purchase, and not discovering the folly of purchasing a car with such ass-backwards issues you only discover after the fact when you bother to dig out the manual.

You drove it off the lot after you bought it, right? Or did you read the manual in the lot right after signing the papers locking you into the purchase?

Turns out you can read the manual of a vehicle ahead of time. Turns out you can also test drive and do everything else you said, and we don't need to pretend that it's all mutually exclusive. Stop being a pedant -- me listing every bit of due diligence about my car isn't relevant, so let's stay on topic.

Honestly, how can people on HN actually be this against reading? Especially things that are really important? Sure, don't read the contest rules for your McDonald's monopoly. But if the data for your livelihood depends on something, there's no excuse for not reading the documentation.

> What's impractical about spending a little time to read?

It's impractical because people live a finite amount of time and this is a terrible use of it

If understanding your production database is a bad use of your time, then I really don't understand your priorities, but I'm glad you're not on my team.

You don't need to read every word of everything, but some things are worth it. Do you sign contracts without reading them too since it's a "terrible use of" your time?

> You don't need to read every word of everything, but some things are worth it.

Yes - I am saying in this particular car example, the benefit derived reading the entire manual before purchasing/driving a car is not worth the cost unless your time is worth very little. As others have pointed out, no one is flipping through the manual to check whether the brake pedal actually applies the brakes

But it is a good engineering decision to thoroughly read the docs before jumping into a new datastore like Mongo, I agree. Learning there are things like gigantic global locks and unsafe writes are normally enough to make you say, "hey, I probably shouldn't use this to store production data I actually care about"

That's fairly unusual; modern cars have a fairly standardized user experience such that there aren't many ways for a car to do something surprising and dangerous that's covered in the manual.

I did experience one once though: I discovered that a vehicle had traction control when the system activated during a skid. The computer and I disagreed about the best way to respond, and the surprise did make the situation more dangerous than it could have been.

In both vehicles and databases, the situations in which the product might do something unexpected and dangerous should be clearly documented in their own section of the manual. Databases should say "here are the things that could lead to data corruption or loss". Vehicles should say "here are the situations where the vehicle might disregard or override the driver's control inputs".

I'm curious about your desired response during the skid and what the traction control system did differently. Would you mind expanding on that if you remember it clearly?

Sure. The vehicle involved was rear wheel drive and, as loaded probably had a rear-biased mass distribution. It began to oversteer in a corner on a patch of ice. Standard protocol for these situations is to apply a moderate amount of throttle to shift weight to the rear and increase traction there while reducing or reversing steering input. The traction control system counteracted my attempt to increase power, requiring vastly more reverse steering input and interfering with my ability to position the vehicle on the road.

I suspect some people will believe the results wouldn't have been what I expected without the traction control. I can't prove they would have been, but I did grow up and learn to drive in Alaska. Based on my experience, I think I would have done better than the computer did.

Here's somebody describing the basic idea involved while discussing the joys of mildly irresponsible driving on cloverleafs: http://www.scottgood.com/jsg/blog.nsf/d6plinks/SGOD-66RJ2Y

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?

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-providing so people adopted it quickly. They didn't read the manual; they put it in production on a small site and got surprised by the lack of durability.

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.

I assure you, having to spend 75% of your administration time dealing with MongoDB problems, taking you away from other critical tasks, you'll see it's not really a great problem to have.

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.

doesn't hbase persist in the transaction log every update, using append on hdfs ? or did you have a version of hdfs that didn't have append ?

HBase never needed nor used append. "Append" refers to the ability to reopen an existing file from a new client and append data to it. HBase writes only immutable files, which means they are written once then only read. Even the WAL is no exception; it is written once, and then only opened for read when needed for recovery or replication.

HBase needs hflush to make sure that the WAL edits are resident at at least 3 (default) HDFS data node machines.

Not sure how exactly grand parent lost data. Each edit is first written to the WAL then committed to the in memory store. The in memory store is flushed to disk into a new file at a certain size. If a server crashes and had unflushed data in the memory store that part of the data is replayed from the WAL on another server.

See also here: http://hadoop-hbase.blogspot.com/2012/05/hbase-hdfs-and-dura...

HDFS didn't have append at the time, not sure how it is now. It did have some filesystem journalling though (if I remember correctly), we just didn't know we should turn it on.

I believe the write concern default is under the responsibilities of the driver -- not the Mongo Daemon.

Other databases are forgiving; they are configured "safe", even at the expense of speed. The intention is that you can deploy a small system immediately; if/as you grow you will see that the database is going too slowly. You can _then_ look at the performance/safety dials you can tune and choose appropriate trade-offs.

These are systems designed for the real world, where people don't read the manual until they have to.

When people assume MongoDB was similarly designed with their best interests in mind, that's when things go wrong.

>When people assume MongoDB was similarly designed with their best interests in mind, that's when things go wrong.

No, I just assume that a database has a similar set of features as other databases have had for decades. Mongo does not; it is clearly the exception - and for possibly nefarious reasons, as well.

I'm not sure how anyone else could know what my best interests are. There are a lot of real world applications where small amounts of data loss don't matter but latency matters a lot.

Any time I deploy something as critical as a database, I carefully read about what it does and how it works. Not doing so is like signing a contract without reading it.

> a lot of real world applications where small amounts of data loss don't matter but latency matters a lot.

I don't understand this reasoning. We are talking about defaults. Defaults are used by people who did not tweak the settings yet. If I am just starting building a thing, I will have bugs and squeaks and I want to make sure I am not fooled by some unreliable data store. I am not likely to need 100GiB/s throughput, but I am very likely to have to hunt bugs, like "I did click on this <like> button but it did not add to the total likes". And I would really really hate it if after half a day of bug hunting I would realize that my data store just didn't store the thing...

MongoDB is optimized for Mongo Inc, not for you, not for me.

> I understand some of the reasons people didn't like Mongo, but this always vexed me. The default write level ... Surely it would be necessary to read the documentation

I don't have much sympathy for people who can't RTFM but storing data is kind of a thing for databases.

the word "Database" brings forth images of ACID compliance.

if you're not trying for that standard at all, it's false advertising.

Mongo was sort of great at first, it's a not bad solution for low traffic sites. It's also great for prototyping. But when anything grows up into high availability, high traffic or anything high.

It's kind of funny, albeit interesting that it took this long for much of the industry to start knocking down the house of cards that is built around the database. However many of the databases that are coming out these days have a lot of the same cultural issue of "hide the issues" and "talk about the cool parts".

I'm expecting any minute now for the anti-schema-less pro-schema movement to rise up...

IMHO, it's all about what you're doing at the time, and making the right decision... albeit it helps if the decisions for a database isn't glossing over the issues as insignificant. :-/

btw - "MongoProbabilisticStorage" is a great name for a product!

Note that even with the changed default to 'acknowledged', data is not guaranteed to have been written to the journal. So, there is still no full durability in writes (by default) and there is a chance data might be lost (e.g. a mongod instance crashes).