9 ms·
I’ll Give MongoDB Another Try In Ten Years
- xoail 14y agoThe world is moving towards 64 bit. 9 out of 10 machines I lay hands on run 64 bit. Just move on and stop complaining.
- ceejayoz 14y agoIn fairness, this would eventually happen on a 64 bit machine too, just not as quickly. No excuse for not reading the docs, though.
- xoail 14y agoIndeed but by then there will be more advancements in software to compliment changes. If you are in technology business it is assumed that you will keep up with technology.
- cheald 14y agoThe 64-bit limit is 8.6 exabytes. There won't be anyone using Mongo that runs into that limit this century.
- krzyk 14y agoBut when you run out of disk space (as one of the posters wrote) it doesn't complain either. And running of of disk space happens.
- ceejayoz 14y agoNot reading the documentation (or hell, the red "note" text under each 32 bit download link at http://www.mongodb.org/downloads http://www.mongodb.org/downloads) for basic limitations will bite you in the ass in 2022 just as easily as it will in 2012.
- diego 14y agoExcept that it was hidden deeply in the documentation. It's like making a car that has the gas and brake pedals switched, and then blaming accidents on people not reading section 5 of the owner's manual. I'm hardly an inexperienced programmer. I've used Cassandra, SimpleDB, Voldemort, etc. I wrote part of the Inktomi Search Engine in the 90s, and plenty of (what today would be called) NoSQL stores over the years. A default that's so counterintuitive for a database should be featured prominently with a huge neon sign. It wasn't in the Ruby tutorial, or in any of the many documents I read. It's buried deep in the Mongo website, and the first Google match about the 32-bit limitation is a blog post from 2009.
- lbcadden3 14y agoIt's on the download page. http://www.mongodb.org/downloads http://www.mongodb.org/downloads
- diego 14y agoI installed it through Ubuntu (apt-get). Most people must (or should) be installing MongoDB through a package manager. Once again, assuming that people will see the warning because it's on the download page is shortsighted.
- deelowe 14y agoSee dmaz's comment about the log files. I'm a complete mongodb noob as well, but found out pretty quickly that there's a 2GB limit on 32bit systems. It really is hard to miss.
- dmaz 14y agoIt also prints to the log upon starting a 32-bit server.
- ig1 14y agoAs the OP points out the limit is pretty clearly specified on the download page and there's a "note" linking to the limit right next to where it says "32-bit". Sometimes you just have to admit you screwed up and didn't read the documentation. Everyone does it, we're hackers, we'd much rather play with technology than read docs.
- Adirael 14y agoJust read the documentation and learn the APIs, this is what happens when you just copy and paste code from a tutorial.
- diego 14y agoThis type of attitude is not constructive. Of course I read the documentation. Much more than "copy and paste from the tutorial." I looked at tons of code samples as needed, read blog posts, etc. The limitation wasn't obvious at all. This reminds me of the attitude that I had to correct in developers that worked for me: - There is a huge difference between "it works" and "it does what the user expects in a friendly way." Steve Jobs said that if you need to read a user manual (particularly to do the most vanilla usage of a product), the problem is the product. Not you.
- jff 14y agoIn the time you've spent defending yourself here and on your blog, you could have learned how to use MongoDB properly, or just gone and bought a 64-bit computer.
- phlyingpenguin 14y agoAre you really arguing that you shouldn't have to study documentation? First, blog posts and code samples are not documentation (in this case, at least). If you were working for me as a developer and had the attitude that you shouldn't have to _thoroughly_ read the manual and notes for something like MongoDB, I'd let you go. Steve Jobs was not a programmer.
- jeremiep 14y agoYou're comparing something like an iPhone, intended for the average Joe, to a complex system intended for developers and especially data architects. Assuming software to be intuitive is a good sign of a bad programmer in my book; any good engineer would never assume anything. Heck, I learned about error handling in Mongo the first hour I started learning it. Same for the 2Gb limitation of 32-bit. The mongo manual is very well done and also happens to be fully indexed in Google.
- 14y ago
- base698 14y agoI used MongoDB one afternoon, and guess what! It doesn't have table-locking writes?! :) In all seriousness, I built a 10 machine Mongo cluster, talked with a 10gen consultant a full day, went to Mongo meetup, and ran all sorts of benchmarks before ever using it in production. I still don't feel like I have the expertise to write a snarky blog post about it.
- meritt 14y ago> It doesn't have table-locking writes?! :) Not really following the snark there. Are you trying to compare MongoDB to MySQL's MyISAM storage engine? Like there aren't numerous other extremely valid RDBMS solutions out there, which don't do table locks during a write? (MySQL InnoDB, Percona, Maria, Aria, Postgresql, Firebird, etc...)
- gnufied 14y agoNo. He is saying out of all faults Mongo has - blog author picks the one which is rather well known.
- chimeracoder 14y agoWorse, it's the necessary tradeoff of one of MongoDB's self-proclaimed benefits (asynchronicity) - it's not an edge case; it's part of the core reasons you'd switch to MongoDB (or at least take into account when making that choice). If that surprises you, it's because you haven't switched for the right reasons or haven't researched enough to know that every benefit has a tradeoff (and to know what those tradeoffs are). To give an analogy, it'd be as if someone read this post and decided to use a SQL database solely because they care about write-durability... and then complaining when they "suddenly" encounter an error when trying to include an extra field with an INSERT on-the-fly. ('You mean SQL has fixed schemas??')
- mattmanser 14y agoWhere on this page is the word asynchronous mentioned: http://www.mongodb.org/ http://www.mongodb.org/ If they just wrote asynch on that page somewhere most experienced programmers would immediately understand the implications. And also understand how the amazing performance was being achieved.
- jeremiep 14y agoI stopped reading at "WTF zomg LOL zombie sandwiches!". Just another script kiddie who can't read documentation and blames his tools instead.
- jff 14y agoMaybe in another 10 years, he'll have managed to lay hands on the elusive 64-bit computer.
- calpaterson 14y agoIt's pretty incredible that the author of a post called "I’ll Give MongoDB Another Try. In Ten Years." criticises a comment on this same post telling him to read the tutorial all the way through as "unnecessarily aggressive". Aside from that, though, the 32 bit limitation is clear in the documentation and present on the download page. It's fine not to read the documentation before you use something but you can't then complain that it did something you did not expect. Mongodb is a little different from other databases. So is Redis. You can't blow everything off that is conceptually different.
- diego 14y agoSee my comment below. If you use a package manager you never see the warning.
- matthewcford 14y agoOne would presume, if you're going to use a database you would check it's limitations first, this one is well documented. There are plenty of valid arguments for not using MongoDB, but this is the weakest I have seen so far.
- jonny_eh 14y agoI don't think his problem was the size limit, it was the lack of exceptions being raised or log errors being recorded.
- true_religion 14y agoMaybe.... just maybe you should read the documentation of the database you're installing before you actually start using it in production. I'm sure this only bit the author because he was using MongoDB for a toy project, and in a real system he'd have done due diligence first. I'm not a fan of MongoDB myself, but if I were to use it I know that I must read about every option available because by default MongoDB's team chose settings that are suited for speed and not reliability, durability, or (if i'm being less charitable) even sanity.
- 14y ago
- DanWaterworth 14y agoInteresting that you're quoting the zen of python, but using ruby. I wonder if the python mongo client would have the same behaviour. There seems to be a number of people commenting, telling you to read the documentation, but I'm with you, that is completely counter-intuitive behaviour and should be viewed as a bug.
- agscala 14y agoThis has nothing to do with the client library, so it would not matter which language you use to interface with MongoDB.
- DanWaterworth 14y agoAs I understand it, it has everything to do with the client library, some clients may call getLastError on every operation and raise errors when they occur, for example.
- andrewvc 14y agoI'm a pretty big detractor of mongo, but I don't agree with this post. One of mongo's main design decisions is to defer writes, making this sort of thing possible. I think it's a crappy tradeoff but it is one of the things that makes mongodb mongodb. If you use it without knowing this you haven't researched it well.
- DanWaterworth 14y agoWhen is this behaviour useful? (Benchmarks don't count)
- pooriaazimi 14y agoI'm no expert in this area, but maybe if you want to use mongo for logging? Or things like that. I kinda like TCP vs. UDP analogy. Sometimes you care more about speed than precision. A few dropped items in a log. Not a big deal. I'd rather have that, than to be forced to use a more expensive machine for the job. That said, I absolutely think the default should be the TCP way.
- eli 14y agoWell, any time you'd rather have speed over completeness. Maybe you're aggregating tweets from the Twitter API and if the occasional one goes missing, it's not a big deal, or perhaps you can grab it on the next update. Maybe you're generating a real-time stats dashboard for your site and if one pageview gets lost every million, it's not a big deal. Look, I agree that in most cases you probably want to do everything you can to make your data 100% complete. But failed writes should be really rare, and there are plenty of times I'd trade the rare missing write for cheaper/faster database servers.
- DanWaterworth 14y agoThis wasn't the occasional write though, this was every write after 2GB. That should set off alarm bells somewhere.
- 14y ago
- ef4 14y agoWhile this article is a bit flippant, I think ten years is a pretty good number when you consider the vast amount of engineering effort that has already been poured into projects like Postgres. This brings me back to the recent discussion about reading other people's code: it is almost certainly smarter to extend an existing database until it's capable of meeting your needs, rather than write one from scratch. The fact that many programmers don't see it that way is a testament to their irrational fear of diving into other people's code.
- taligent 14y ago10 years and PostgreSQL still has no easy, manageable solution for replication or sharding. And it's JSON support is still nothing more than a bolted on hack on top of a BLOB. People need to stop acting like PostgreSQL is some holy grail database. It isn't.
- dmpk2k 14y agoI think that just reinforces his point. Making a solid database is hard work. And making a solid, featureful, and performant database is vastly harder.
- prodigal_erik 14y agoCorrectly and efficiently querying sharded tables is not only a very complicated dark art but also heavily patented. I thought they had a replication story, though.
- mtkd 14y agoThis is the latest in a long line of negative posts on MongoDB based solely on first impressions because either: 1) it does not behave exactly like SQL 2) the user didn't read any more than a Quickstart Guide 3) the user fundamentally misunderstands the aim of the new technology or the application it is intended for Ember.js suffers from the same ignorance. What makes it worse is all the morons who upvote without even reading the detail purely because the title reinforces some misconceived bias they already have. 'NoSQL' is part of the problem. This technology has absolutely no comparison with SQL other than it persists data.
- smacktoward 14y agoThis technology has absolutely no comparison with SQL other than it persists data Except that apparently under certain circumstances it doesn't persist data, which was the author's point. Personally I wouldn't be upset about a limitation like the one described as much as I would be upset about the database not logging an error when it discards the data. Logs are a primary way you figure out what's wrong when your application isn't behaving as expected. If you open the logs and see a bunch of "32-bit capabilities exceeded, please buy a real computer" messages, you learn what the problem is. If the database error logs are empty, that implies that everything is working fine, when in this case it clearly isn't.
- ukd1 14y agoYou can get MySQL to do dumb stuff as well, though you have to specifically ask it to take more risks - http://dev.mysql.com/doc/refman/5.5/en/insert-delayed.html http://dev.mysql.com/doc/refman/5.5/en/insert-delayed.html Almost all of the complaints against MongoDB are down to assumptions and lack of understanding about the database.
- linuxhansl 14y agoI'm sorry. Which part of "It silently ignored my data" do you not understand? You call people "morons", yet it appears that you did not read the article yourself. Whether SQL or not, scalable or not, old or new, or whatever... Is completely immaterial here. When a database silently stops accepting data, and apparently has done so for 3 years, you have to at least admit that there are strange design goals at play. Now, the entire claim of the article might be incorrect. Did you verify that yourself? Edit: Spelling
- daveungerer 14y agoIt's almost like the commenters who are bashing the author of the post did not read the bit in bold, which is his main point: If you tell a database to store something, and it doesn’t complain, you should safely assume that it was stored. This has nothing to do with the 2Gb limitation. Nowhere in the documentation does it mention that it will silently discard your data. What will happen with the 64-bit version if you run out of disk space, more silently discarded data? I know a lot of you may have cut your teeth on MySQL which, in its default configuration, will happily truncate your strings if they are bigger than a column. Guess what? Anyone serious about databases does not consider MySQL to be a proper database with those defaults. And with this, neither is MongoDB, though it may have its uses if you don't need to be absolutely certain that your data is stored. EDIT: Thanks for pointing out getLastError. My point still stands, since guaranteed persistence is optional rather than the default. In fact, reading more of the docs points out that some drivers can call getLastError by default to ensure persistence. That means that MongoDB + Driver X can be considered a database, but not MongoDB on its own. I'm just struggling to imagine being willing to lose some amount of data purely for the sake of performance, so philosophically it's not a database unless you force it to be. Much like MySQL. EDIT2: Not trying to be snarky here, but I would love to hear about datasets people have where missing random data would not be an issue. I'm serious, just want to know what the use case is that MongoDB's default behaviour was designed for. EDIT3: (Seriously) I'm sure MongoDB works splendidly when you setup your driver to ensure that a certain numbers of servers will confirm receipt of the data (if your driver supports such an option), nowhere am I disputing that. But that number really should have a lower bound of 1, enforced by MongoDB itself. And to the guy who called me stupid: you are what's wrong with HN.
- ceejayoz 14y ago> Nowhere in the documentation does it mention that it will silently discard your data. Demonstrably false. http://www.mongodb.org/display/DOCS/getLastError+Command http://www.mongodb.org/display/DOCS/getLastError+Command "MongoDB does not wait for a response by default when writing to the database. Use the getLastError command to ensure that operations have succeeded."
- 14y ago
- eranation 14y agoI'm using MongoDB for experimental work for about 6 months, it has a few amazing advantages, it's the MVP / POC king, you just do it, it's the agile iteration master, it's definitely not the best choice for doing any statistics, or any financial like transaction handling. However, it starts to feel like Anti MongoDB is just considered cool today, when I see someone that worked with MongoDB for a year, upgraded to 2.2, knows it inside out and still hates it, I would listen, and start to worry. but until then, I'm going to keep using it, and saving time.
- nestlequ1k 14y agoAgreed. I've been using it almost daily for 2 years. It was not an instant learning curve (what DB is?), but it's an absolute joy to develop for. People who would rather not bother, can stick with their tools, work slower, and be happy.
- ShabbyDoo 14y agoThe author doesn't mention if he had called getLastError after inserting data: http://www.mongodb.org/display/DOCS/getLastError+Command http://www.mongodb.org/display/DOCS/getLastError+Command The MongoDB "way" is that clients know the importance of their data and can choose write strategies which make the proper trade-off between insertion throughput/latency and durability/consistency.
- deleted 14y ago[deleted]
- macaroniHeadset 14y agoI use MongoDB heavily and read this expecting some kind of insight. Instead some kid used it for 5 minutes without reading the docs and whined about 32 bit of all things. Stop wasting peoples time. RTFM.
- jcoder 14y agoAll I'm getting from this conversation is that there is a heavy prevalence of Stockholm Syndrome among MongoDB users.
- bdcravens 14y agoThere's a bigger question here. I get why diego was flabbergasted by the default, and I also hear legitimate claims that the documentation should have been read. But what I want to know is: Why are MongoDB advocates in such a bad mood? It's legit to criticize a language or a database. However, it seems to me that when MongoDB gets involved, the tone is far more aggressive and defensive. What's up with that? It's just software, bits and config files. It's not like someone called your mom a harlot. Here's what I think. New developers, for a long time, have come into the industry and become overwhelmed with everything they need to learn. Let's take typical database servers. Writing a SELECT is easy enough, but to truly be an expert you have to learn about data writing operations, indexing, execution plans, triggers, replication, sharding, GRANTs, etc. As it's a mature technology, you start out barely an apprentice, with all these experienced professionals around you. In recent years, software development has really been turned on its head. We're not building apps using the same stack we've used for a long time: OO + RDBMS + view layer + physical hardware. The younger the technology, the better, it seems. In theory, a 3 year developer and a 20 year developer are now pretty equal when we're talking about a technology that's been around 2-3 years. That wouldn't be true if we were dealing with say, OO design patterns. (Even when new languages come along, you still get to keep your experience in the core competencies.) Attacks on these new technologies are perceived as an assault on this new world order, and those who have walked into being one of the "newb elite" respond emotionally to what they see as a battle for the return to the old guard. Am I totally off base here?
- manuscreationis 14y agoWhile I agree with the sentiment you're expressing here on some levels (people don't like it when you insult things they like, as they feel they need to defend their choice or themselves because of it), I don't think that quite applies here. This is a case where, although the ultimate complaint of the author is the behavior of the product (which is documented, but un-intuitive in nature unless you've read up on the issue), it's the way in which he chose to frame the problem that is getting people upset. This is a known issue, even if it seems like a completely poor design decision. The issue I think most people here are taking is that because the author did almost no research on the topic, he got himself into a problem, and is trying to blame it on Mongo.
- manuscreationis 14y agoDoes he have a point that it should have very vocally complained to him that his size limit have been reached, and records were not being stored? Yes. Without question. Is this his own fault for not reading the documentation and understanding that he should have opted for the 64bit version outright? Yes. Without question.
- nemesisj 14y agoWe've been interviewing candidates to join our team for a few months, and I've also lent some interviewing support to other startups in our area. I've noticed a trend across about 20+ candidates, all of whom are smart people: people are using Mongo without actually understanding what the hell it's trying to solve by getting away from the RDBMS paradigm. I'm not sure if this is because 10gen markets it as a general purpose tool, but I have yet to talk with a candidate who can actually describe why they were using the DB vs. a SQL database. I'm all for learning new things, but I can't help but wonder if the string of negative MongoDB posts is coming from people who pick it b/c it's new, then realise pretty far in that this is nothing like a normal DB, and "having no schema" isn't really a reason to go with a tool as foundational as a data store. I think Mongo is great for really specific problems that its designed to solve. It's probably pretty bad for a general purpose tool, but I'd be surprised if anyone serious actually considers it one.
- AlisdairO 14y ago> but I can't help but wonder if the string of negative MongoDB posts is coming from people who pick it b/c it's new, then realise pretty far in that this is nothing like a normal DB, and "having no schema" isn't really a reason to go with a tool as foundational as a data store. My observation has been that a substantial number of people pick NoSQL stores because they don't really understand RDBMSs, and can't be bothered to learn. I don't mean this as a dig at NoSQL in general - there's perfectly valid reasons to want some NoSQL features - but the hype train does attract a lot of people who just want the new hotness.
- clintonb11 14y agoWhat about scalability? Trying to cluster and shard MySQL is a very difficult task, but with MongoDB it is trivial. No schema can be good, but scaling out easily is the big plus I see.
- markmm 14y ago/dev/null is the most scalable system though, just fire up a node and it's there.
- rjzzleep 14y agoi welcome the post. even though most of my stuff runs on 64bit, i actually do have a few 32 bit systems here and there. I never knew. Because as the op mentions it's not written anywhere _obvious_. another thing I didn't realize was that because of the memory mapped systems which i guess is fine performancewise it's hard to estimate memory usage on a machine. from what I understand there is no possibility to limit the memory usage. Which means that the only way you can limit the amount of memory used is by keeping the size of the database below your memory. quite important things to know imho. here's an interesting post mentioned in the comments: http://www.zopyx.com/blog/goodbye-mongodb http://www.zopyx.com/blog/goodbye-mongodb
- pooriaazimi 14y ago> it's not written anywhere _obvious_. Isn't http://www.mongodb.org/downloads http://www.mongodb.org/downloads an obvious place?
- frederico 14y agoLooks pretty obvious to me; however I am a novice when it comes to RTFM..
- krzyk 14y agoYeas, there is a small "note" there. But for me the problem is not that the author didn't know about 2GB data limit. The problem is that Mongodb didn't complain when he was inserting data above the limit. A data store doesn't complain when it runs out of space? It should be mentioned as the biggest problem with 32bit version.
- arielweisberg 14y agoWhen I wrote some hobby code for Postgres using the PHP driver I had to manually check error codes after each and every operation. This came as no surprise to me. Exception throwing database drivers are a relatively new thing not an old thing. The only thing MongoDB does differently is that the writes are fire and forget in that the database hasn't returned a response of any kind when the function returns. In native code you can forget about using exceptions in a database driver because exception handling can be exceptionally broken on some platforms. SmartOS I am looking in your direction.
- alwold 14y agoException throwing is not that new. It's just a question of what is the style in the language you're using. In Java, for example, throwing exceptions has been the norm since JDBC was invented in 1997. PHP is definitely different in that exceptions are rare. Same story with C++. I'm not super experienced with Ruby, but they seem pretty common there, so I would've expected to get one.
- ericcholis 14y agoFirst, your friends with MongoDB are fsync and safe. These are both documented and discussed in more than a few places: http://nosql.mypopescu.com/post/1052759609/mongodb-safe-and-fsync-explained http://nosql.mypopescu.com/post/1052759609/mongodb-safe-and-... So, assuming you are writing an ecommerce application, here's where I think these flags come in. - Session data: fsync = true. Wait for a response, and ensure it's written to disk - Internal web analytics: safe = false. Who cares if it's written, I've got an application to serve! - Orders: fsync = true. I know, RDBMS, transactions, blah blah blah. People tend to look at NoSQL and wonder why it doesn't function like MySQL, then they loudly complain how bad the software is. Nobody is writing articles about how Memcached doesn't function like MySQL.
- jeffdavis 14y agoI think blaming the user here is partially valid (he didn't read the docs), but that's not the whole story. There is a discontinuity between the ease-of-use story and the blame-the-user story, regardless of how well documented the async insert behavior is. And it doesn't have to be this way. There are ways of designing interfaces, APIs, and even naming that go a long way to prevent your users from shooting themselves in the foot. Take postgres. It also supports at least a couple kinds of async insert, one of which is a part of libpq (postgres C client library). It's called "sendQuery" and it's documented under the "Asynchronous Command Processing" section. It's hard to imagine a user trying to use that and expecting it to return an error code or exception. Even if the user doesn't read the docs, or reads some fragment from a blog post, they will still see that the name suggests async and that it returns an int rather than a PGResult (which means it obviously doesn't fit into the normal sync pattern). There is no reason mongo couldn't be clear about this distinction -- say, rename "insert" to "async_insert" and have "insert" be a wrapper around async_insert and getLastError. But instead, it's the user's fault because they didn't read the docs. Careful API design is important to reduce the frequency of these kinds of errors. In postgres, it's relatively hard to shoot yourself in the foot this badly in such a simple case. I'm sure there are gotchas, but there is a conscious effort to prevent surprises of this sort.
- chimeracoder 14y ago> There is no reason mongo couldn't be clear about this distinction -- say, rename "insert" to "async_insert" and have "insert" be a wrapper around async_insert and getLastError. But instead, it's the user's fault because they didn't read the docs. Because if you don't read enough of the docs to understand that 'insert' is asynchronous insert, you don't understand MongoDB and haven't done your research. Why should 'insert' default to synchronous? Why shouldn't we instead have a sync_insert function instead? The only reason is that you're assuming familiarity for people coming from SQL/synchronous-oriented DBMS, but why should they be forced into an awkward design just because it's what people are familiar with from other DBMS?
- lotyrin 14y agoIt's not that way because somebody in the 70's flipped a coin and decided that sync was heads. It's because it's a reasonable assumption to make. Data loss shouldn't be a surprise, if I need speed and am willing to risk dataloss I should have the option, but should explicitly choose to use it.
- kombine 14y agoA lot of bashing of MongoDB lately is a sign to give a technology at least a try.
- nestlequ1k 14y agoGreat point. That's usually how you to tell when a technology is starting to disrupt things. Really smart people / experts in their field (which Diego definitely is) start to bash it. In this case, he has a point but has way overblown things. But that's ok, that means Mongo is on the right track.
- wglb 14y agoI am trying to reconcile the ideas of "Mongo is on the right track" with burning a user by losing data.
- pjungwir 14y agoI ran into this same nasty surprise building a prototype to store requests in Mongo instead of Postgres. It was enough to scare me away, too. Glad I noticed it while it was still just a script+Makefile simulation. Another problem with Mongo I never heard anyone else raise is that there are no namespaces. If I install Mongo, all the tables/collections live in the same namespace. What if I want to use it for multiple projects? How do other people solve this problem?
- clintonb11 14y agoYou have multiple databases, just like a sql solution. One database per project.
- etrain 14y agoI had a very similar experience about a year ago. Except instead of running out of RAM on a 32-bit instance, I was running out of disk on a 64-bit instance. That's right, my database ran out of disk, and the driver didn't throw an exception. Yes, I realize that there's a "safe=True" option to my python driver. But I'm writing to a database. As others have said here and elsewhere, the default behavior of a database and its drivers should be to complain loudly when a write fails. It is ridiculous that safe!=True by default. If I want to turn off this feature to improve performance, I will.
- frederico 14y agoTwo paths for working with new technologies: - Download, Brief 3rd party tutorial, Production, Break, Complain, RTFM / Complain - RTFM, Smile, Download | Move On, Staging, Production Seems most of the issues from this article came from a lack of reading and investigating.
- Andrex 14y agoInteresting you switched to Couch. I was hesitant to recommend it reading the post because I feared you were turned off JSON stores entirely, glad to hear that's not the case. In general it feels like Couch actually takes storing data seriously. Append-only and whatnot. It's slower and a little bulkier than Mongo, but it does the important things right (1.0 bugs notwithstanding.) I'd love a follow-up blog post on your experience with Couch.
- louischatriot 14y agoI agree with posts stating that you should read the docs before using a tool you don't know. But I also think that these two really important points should be mentioned in the Getting Started guide, in bold: - The 32bit 2GB limitation (seriously when I started with MongoDB I wasn't expecting this!) - The fire-and-forget policy These are really not points to be discovered in chapter whatever of the docs.
- taligent 14y agoIt's on the download page: http://www.mongodb.org/downloads http://www.mongodb.org/downloads
- louischatriot 14y agoIndeed. It is definitely not big enough though.
- bobx11 14y agoThe fact that this is on the front page shows that HN is no longer a real news trading site for real hackers. :(
- eranation 14y agoIsn't the write result containing the info? e.g. if the write failed, it will contain the error if you just check for it? if so, and I haven't checked (but I assume it's so) then this post is equivalent to ranting on Go's lack of exception handling. like it, don't like it, it is what it is, you can either use it, or fork it and make your own database / language.
- markmm 14y agoOne of the main reasons I hear people advocating MongoDB is it's ease of horizontal scaling, via replication and auto sharding. I wonder how many projects have such large data sets that they really require sharding of their data? I understand having another node or two for fail over but I reckon with the spec of the largest offerings from AWS or Linode most people will never need to worry about this and can manage everything on one Postgres or MySQL db. Why complicate things before you have to.
- ojosilva 14y agoI can think of several cases where throwing an exception is counterintuitive to Mongo's design and applications. Let's say, if your app returns control to the user while storing data asynchronously, throwing an exception might not be the best way of handling errors. In fact, if throwing exceptions were Mongo's default, I wonder how long it would take for a blog post entitled "Mongo blew up my app" to appear.