111–120 of 188 posts
I am okay if others continue to use MongoDB. It will keep my team gainfully employed ;)
Earlier quoted context omitted.
This is a problem I've had to explain to too many developers recently. It's not faster just because you throw away data modeling practices and jam bits of info all over the place. If you have semi normalized data relationships, Mongo really doesn't fit the bill that well as your primary data store. Where it shines is when you've got computed pieces of data to display (parts of a user data feed for example, data for a…
> find the barriers to entry on NoSQL lower Not having to think rigorously about the logical structure of your data is a huge selling point for many. For programmers, because it means they don't have to think . And for employers, because it means they can make do with programmers who don't want to think.
Earlier quoted context omitted.
To be fair, I think your comment shows why this sort of post _can_ still be useful. You're very unlikely to lose data on a modern Mongo system using default configuration (their troubles with durability have largely been solved), but there are many other good reasons not to use it, and it's enlightening to read about and understand what they are.
If "their troubles with durability have largely been solved" were true then I'm sure HN would be flooded with posts about "MongoDB solves durability with an entirely new architecture". I might be wrong here. How did they solve the "your data is lost when a disk fails"?
Previously, Mongo had very serious problems in that are because its client would assume that any message sent to the outgoing socket buffer was persisted "well enough", which was an obvious untruth [1]. This was also one of the somewhat underhanded techniques they used to achieve their early benchmarks.
As of version 3, they have defaulted their client's "write_concern" value to "1", which means that it will wait for confirmation from a replica set's primary before considering a value persisted [2]. This puts Mongo roughly on the same level as any other database in terms of durability guarantees.
Disk failure is entirely tangential to your original premise that "Mongo loses data". I'm not getting into it, but there a variety of techniques that Mongo (and every other known database) can use to protect against that.
[1] http://hackingdistributed.com/2013/01/29/mongo-ft/
[2] https://docs.mongodb.com/manual/reference/write-concern/
> You can see why this is attractive: all the data you need is already located where you need it.
That doesn't sound attractive at all. That sounds more like a recipe for "we use five hundred times more RAM than the deduplicated data that we actually have" type of disaster.
...All for a production data set which could be "turned into about 1.2 million rows in MySQL." I think the moral is "If you think your data is too big for a relational database, you're almost certainly wrong."
Earlier quoted context omitted.
Indexes are not an example of denormalization. Normalization means that there is one canonical element that describes an object, not that there's only one copy or representation of that element.
Indexes are basically a copy of the original data, only sorted in the right order. They are denormalized data, sort of.
Earlier quoted context omitted.
Indexes are basically a copy of the original data, only sorted in the right order. They are denormalized data, sort of.
Indexes are often only a pointer to that data, and they are not denormalized, they are better described as projections of your data (this way saving the work of ordering/filtering on that same projection in the future.)
Earlier quoted context omitted.
Actually, when you have a toy project that needs a RDBMS, go ahead and use SQLite. The consensus is that relatively few applications are a good fit for MongoDB, irrespective of scale.
What's an example of an application that is a good fit for MongoDB?
If you have a file store service, where you're storing relatively big files (big images, videos, etc) and some metadata associated to them which need to be queried.
It's easier to implement than "traditional" solutions (metadata goes in a RDBMS and actual files go to some directory, NAS, or whatever).
Also, apart from being a nicer solution from a programmer's perspective, you'll be able to easily scale horizontally because it supports sharding.
Like I said, I didn't tried this myself so take it with a grain of salt. Also, I don't know how that compares to storing blobs in a RDBMS.
Earlier quoted context omitted.
Indexes are not an example of denormalization. Normalization means that there is one canonical element that describes an object, not that there's only one copy or representation of that element.
Indexes are basically a copy of the original data, only sorted in the right order. They are denormalized data, sort of.
My first introduction to databases was with PHP/MySQL, where normalization was the name of the game. The whole point of normalization is that there is no duplication of data anywhere. If it's possible for duplicate data to exist, that's a symptom of a design flaw in the schema. I've been using Mongo recently, and every time I raise criticism of it, the counterargument I hear is "forget about normalization! Duplicatio…
I don't like MongoDB either, but normalization is not the answer for every project. For some projects, reading efficiency is so important that people are willing to pay for of it in disk space, an increase in writing costs, and even app complexity.