4 ms·

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 la

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.

joepie91_ 11y ago
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, and thus never sees the warning even if it's there. Warnings like this belong in all the relevant spots in the documentation, not just on a download page.
- yousoundmad 11y ago
  yousoundmad
- cheald 11y ago
  That 32bit startup warning has been in place since 2009. It was in the README in 2008 (IIRC, pre-1.0). https://github.com/mongodb/mongo/commit/b3322b86a014683018ac81c30df0b0823bf03272 https://github.com/mongodb/mongo/commit/b3322b86a014683018ac... There's plenty in Mongo to complain about, but grousing about the 32-bit limitation just makes you look like you're bad at reading introductory documentation.
  - joepie91_ 11y ago
    This doesn't explain the data loss consequences (remember the client default!), nor was it clearly visible on the download page - you'd have to explicitly look for it. This was the case until as late as 2014: https://web.archive.org/web/20140704182658/http://www.mongodb.org/downloads https://web.archive.org/web/20140704182658/http://www.mongod... And again, the 'download' page or README is not sufficient for such a warning, nor is a startup message a reliable place to put it (because of initscripts and such). It should have been in all the relevant places in the documentation, instead.
    - cheald 11y ago
      Unacknowleged writes were a bad default. I think everyone with a shred of honesty will happily admit to that. It was certainly in the documentation, in the blog posts, in the startup logs, and in the README for quite a long time. If you missed it, it's probably because you weren't paying attention. Again, there are plenty of good reasons to dislike MongoDB, but this isn't one of them, and harping on it substantially degrades your credibility.
      - joepie91_ 11y ago
        > It was certainly in the documentation, [...] in the startup logs, and in the README for quite a long time. All the wrong places, as already stated. These are not the places where developers actually look. I provided some better example locations here: https://twitter.com/joepie91/status/622920351731843072 https://twitter.com/joepie91/status/622920351731843072 > [...] in the blog posts [...] Certainly not there. Go look around for MongoDB tutorials from the timespan where unacknowledged writes were the default, and almost none of them remark on the 32-bits limitation. > If you missed it, it's probably because you weren't paying attention. Nonsense. It simply wasn't in the locations where people actually look. You can easily verify that using the Wayback Machine (and in fact, this is still mostly the case today). > Again, there are plenty of good reasons to dislike MongoDB, but this isn't one of them, and harping on it substantially degrades your credibility. If pointing out extremely dangerous past negligence from the MongoDB developers "degrades my credibility" in your view, then you have some very strange ways to determine credibility.
        cheald 11y ago
        > All the wrong places, as already stated. These are not the places where developers actually look. If you're not reading READMEs, installation notes, and server logs and instead depend on marketing splash pages to highlight the limitations of the technologies you use, you're a bad developer. Sorry. > Certainly not [in blog posts] http://blog.mongodb.org/post/137788967/32-bit-limitations http://blog.mongodb.org/post/137788967/32-bit-limitations > It simply wasn't in the locations where people actually look. You can easily verify that using the Wayback Machine (and in fact, this is still mostly the case today). I first started using Mongo in 2010 according to my gitlogs (after it having been on my radar for some time before that), and I very distinctly remember reading about the 32-bit limitation well before I'd ever installed it, because we were also using Varnish at the time, which has similar issues on 32-bit systems because it too uses (or at least, at that time used) memory-mapped files. The claim that the limitation was not documented well, or was hidden, or was generally unknown at that time is just simply false.
- rrss1122 11y ago
  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.
philwelch 11y ago
> 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. That's all well and good, but reporting writes as successful and silently failing when your data ticks over 2 GB instead of throwing errors or doing something useful like that is more what the complaint is about. Obviously, you could set up monitors on your data storage and alarm if it reaches 1.75 GB, but if you're mature enough to do that, you're mature enough to use a real database solution.
giaour 11y ago
The author is cataloguing some of Mongo's "paper cuts," i.e., issues for which warnings and known workarounds exist but that really make the development experience less pleasant. For MongoDB's actual limitations, read aphyr's Call Me Maybe series.
- cwyers 11y ago
  Right. I am so sick and tired of MongoDB defenders saying "read the manual" after aphyr has found multiple faults in MongoDB that directly conflict with the documentation.
- stickfigure 11y ago
  To be fair, aphyr analyzed Mongo's clustering behavior and found a lot of problems. Which has been a consistent refrain in the series - apparently clustering a datastore is hard. ElasticSearch and RabbitMQ fair poorly as well. Also, it's not like Postgres even tries to offer clustering. So what are you comparing Mongo to? There's no reason to believe that a single-node Mongo instance will be any less reliable than a single-node MySQL or Postgres. At least, nobody has presented that argument.
  - giaour 11y ago
    Mongo is actually great for very small datasets. But they sell it as a clustered solution (mongodb.org is currently featuring a giant banner that reads, "Agility, scalability, performance. Pick three"), so it's fair to judge them on that.
    - stickfigure 11y ago
      I agree, but I'm getting the sense that some people (including the OP) are using the CMM article to claim that Postgres is more reliable. Postgres doesn't have this kind of clustering feature at all. Not a fair comparison.
jfb 11y ago
A database built by people who are careless with my data is not a database worth paying attention to, even when particular problems are remedied.

joepie91_ 11y ago

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, and thus never sees the warning even if it's there. Warnings like this belong in all the relevant spots in the documentation, not just on a download page.

yousoundmad 11y ago
yousoundmad
cheald 11y ago
That 32bit startup warning has been in place since 2009. It was in the README in 2008 (IIRC, pre-1.0). https://github.com/mongodb/mongo/commit/b3322b86a014683018ac81c30df0b0823bf03272 https://github.com/mongodb/mongo/commit/b3322b86a014683018ac... There's plenty in Mongo to complain about, but grousing about the 32-bit limitation just makes you look like you're bad at reading introductory documentation.
- joepie91_ 11y ago
  This doesn't explain the data loss consequences (remember the client default!), nor was it clearly visible on the download page - you'd have to explicitly look for it. This was the case until as late as 2014: https://web.archive.org/web/20140704182658/http://www.mongodb.org/downloads https://web.archive.org/web/20140704182658/http://www.mongod... And again, the 'download' page or README is not sufficient for such a warning, nor is a startup message a reliable place to put it (because of initscripts and such). It should have been in all the relevant places in the documentation, instead.
  - cheald 11y ago
    Unacknowleged writes were a bad default. I think everyone with a shred of honesty will happily admit to that. It was certainly in the documentation, in the blog posts, in the startup logs, and in the README for quite a long time. If you missed it, it's probably because you weren't paying attention. Again, there are plenty of good reasons to dislike MongoDB, but this isn't one of them, and harping on it substantially degrades your credibility.
    - joepie91_ 11y ago
      > It was certainly in the documentation, [...] in the startup logs, and in the README for quite a long time. All the wrong places, as already stated. These are not the places where developers actually look. I provided some better example locations here: https://twitter.com/joepie91/status/622920351731843072 https://twitter.com/joepie91/status/622920351731843072 > [...] in the blog posts [...] Certainly not there. Go look around for MongoDB tutorials from the timespan where unacknowledged writes were the default, and almost none of them remark on the 32-bits limitation. > If you missed it, it's probably because you weren't paying attention. Nonsense. It simply wasn't in the locations where people actually look. You can easily verify that using the Wayback Machine (and in fact, this is still mostly the case today). > Again, there are plenty of good reasons to dislike MongoDB, but this isn't one of them, and harping on it substantially degrades your credibility. If pointing out extremely dangerous past negligence from the MongoDB developers "degrades my credibility" in your view, then you have some very strange ways to determine credibility.
      - cheald 11y ago
        > All the wrong places, as already stated. These are not the places where developers actually look. If you're not reading READMEs, installation notes, and server logs and instead depend on marketing splash pages to highlight the limitations of the technologies you use, you're a bad developer. Sorry. > Certainly not [in blog posts] http://blog.mongodb.org/post/137788967/32-bit-limitations http://blog.mongodb.org/post/137788967/32-bit-limitations > It simply wasn't in the locations where people actually look. You can easily verify that using the Wayback Machine (and in fact, this is still mostly the case today). I first started using Mongo in 2010 according to my gitlogs (after it having been on my radar for some time before that), and I very distinctly remember reading about the 32-bit limitation well before I'd ever installed it, because we were also using Varnish at the time, which has similar issues on 32-bit systems because it too uses (or at least, at that time used) memory-mapped files. The claim that the limitation was not documented well, or was hidden, or was generally unknown at that time is just simply false.
rrss1122 11y ago
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.

philwelch 11y ago

> 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. That's all well and good, but reporting writes as successful and silently failing when your data ticks over 2 GB instead of throwing errors or doing something useful like that is more what the complaint is about. Obviously, you could set up monitors on your data storage and alarm if it reaches 1.75 GB, but if you're mature enough to do that, you're mature enough to use a real database solution.

giaour 11y ago

The author is cataloguing some of Mongo's "paper cuts," i.e., issues for which warnings and known workarounds exist but that really make the development experience less pleasant. For MongoDB's actual limitations, read aphyr's Call Me Maybe series.

cwyers 11y ago
Right. I am so sick and tired of MongoDB defenders saying "read the manual" after aphyr has found multiple faults in MongoDB that directly conflict with the documentation.
stickfigure 11y ago
To be fair, aphyr analyzed Mongo's clustering behavior and found a lot of problems. Which has been a consistent refrain in the series - apparently clustering a datastore is hard. ElasticSearch and RabbitMQ fair poorly as well. Also, it's not like Postgres even tries to offer clustering. So what are you comparing Mongo to? There's no reason to believe that a single-node Mongo instance will be any less reliable than a single-node MySQL or Postgres. At least, nobody has presented that argument.
- giaour 11y ago
  Mongo is actually great for very small datasets. But they sell it as a clustered solution (mongodb.org is currently featuring a giant banner that reads, "Agility, scalability, performance. Pick three"), so it's fair to judge them on that.
  - stickfigure 11y ago
    I agree, but I'm getting the sense that some people (including the OP) are using the CMM article to claim that Postgres is more reliable. Postgres doesn't have this kind of clustering feature at all. Not a fair comparison.

jfb 11y ago

A database built by people who are careless with my data is not a database worth paying attention to, even when particular problems are remedied.