3 ms·

The fact that some are okay with and would use an unreliable tool is not inconsistent with the fact that it is documented that the tool is unreliable. Popularit

The fact that some are okay with and would use an unreliable tool is not inconsistent with the fact that it is documented that the tool is unreliable. Popularity among users has little to do with the tool being reliable, and this particular one is already popular for being unreliable.

threeseed 8y ago
What you are saying doesn't really make any sense. A systemically unreliable database would never be popular as its not a piece of your architecture that you can tolerate having constant outages with. And there is no evidence of MongoDB being systemically unreliable.
- macintux 8y ago
  There are use cases where losing data is an acceptable tradeoff, particularly if the database is not the system of record.
- erik_seaberg 8y ago
  A reckless enough design (e.g., returning success when a request is merely buffered at the client) can lose writes without telling you that it lost writes, which won't affect its popularity among users who don't audit for that.
- pritambaral 8y ago
  > A systemically unreliable database would never be popular 1. Correctness and popularity are different 2. Not everyone looks for correctness, even when looking for a database. See: MySQL. > as its not a piece of your architecture that you can tolerate having constant outages with Reliability and correctness are not binary scales of 'works' vs. 'does not work'. Again, see MySQL. > there is no evidence of MongoDB being systemically unreliable There is plenty of evidence of MongoDB losing writes because of its (honestly) stupid design: writing to memory maps instead of files, never fsyncing, sharding and distributing without confirming disk flush. --- MySQL: For a long time, one needed to be aware of certain caveats and corners and limitations of MySQL or be surprised with data inconsistency and loss. That is not to say that MySQL could not be operated reliably; it could, just that the barrier was higher than it appeared. From truncating data (with a warning) to not accepting and silently (i.e., without warnings) ignoring CHECK constraints, I've had clients who lost business data and realized it only too late to go back to the original data source. I used to think MySQL was an bad database due to its concessions of correctness and poor documentation, until MongoDB came along with their lofty marketing and high-and-mighty "Nobody needs SQL anymore, we are Web-scale" blare-horn and failed to deliver on even keeping the data it claimed to have saved.
Thaxll 8y ago
Let me guess you're a Postgress troll?

threeseed 8y ago

What you are saying doesn't really make any sense. A systemically unreliable database would never be popular as its not a piece of your architecture that you can tolerate having constant outages with. And there is no evidence of MongoDB being systemically unreliable.

macintux 8y ago
There are use cases where losing data is an acceptable tradeoff, particularly if the database is not the system of record.
erik_seaberg 8y ago
A reckless enough design (e.g., returning success when a request is merely buffered at the client) can lose writes without telling you that it lost writes, which won't affect its popularity among users who don't audit for that.
pritambaral 8y ago
> A systemically unreliable database would never be popular 1. Correctness and popularity are different 2. Not everyone looks for correctness, even when looking for a database. See: MySQL. > as its not a piece of your architecture that you can tolerate having constant outages with Reliability and correctness are not binary scales of 'works' vs. 'does not work'. Again, see MySQL. > there is no evidence of MongoDB being systemically unreliable There is plenty of evidence of MongoDB losing writes because of its (honestly) stupid design: writing to memory maps instead of files, never fsyncing, sharding and distributing without confirming disk flush. --- MySQL: For a long time, one needed to be aware of certain caveats and corners and limitations of MySQL or be surprised with data inconsistency and loss. That is not to say that MySQL could not be operated reliably; it could, just that the barrier was higher than it appeared. From truncating data (with a warning) to not accepting and silently (i.e., without warnings) ignoring CHECK constraints, I've had clients who lost business data and realized it only too late to go back to the original data source. I used to think MySQL was an bad database due to its concessions of correctness and poor documentation, until MongoDB came along with their lofty marketing and high-and-mighty "Nobody needs SQL anymore, we are Web-scale" blare-horn and failed to deliver on even keeping the data it claimed to have saved.

Thaxll 8y ago

Let me guess you're a Postgress troll?