81–90 of 122 posts
I think people only use it because it stores JSON and let's you query it arbitrarily on demand. It appears to be as good as CouchDB, but with on-demand queries, as good as Postgres, but with JSON (!). It appears to be quick and easy and the tool for the job. Also, when people say NoSQL they actually mean MongoDB.
Cassandra, Couch, Redis, Riak, Dynamo...
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.
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.
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.
Earlier quoted context omitted.
There are a few. Mongo has excellent integration with Hadoop and is becoming very popular in the big data analytics space. Likewise it is gaining traction in the EDW space as a result of their partnerships. Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes.
> Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes. It's not hard to make it easy to do a thing in the wrong way - and that's exactly what MongoDB does. It doesn't make you set up authentication or table schemas, so it looks 'really easy to set up'. In reality, though, you're wasting hours to save 10 minutes. Because at a later point, you're going to have…
Why would I care about having my database broken into or even my data being corrupted for hacks/spikes. The very definition of these is that they are throwaway designed to test an idea before rebuilding in something more suitable.
And yes MongoDB is schemaless. That doesn't mean your data is going to automatically corrupt itself. You can just define your schema in some shared library. I can just as easily corrupt PostgreSQL if I change data types without updating the ORM.
Not even a hackathon?
If your data really doesnt matter you might as well just use ElasticSearch as a document store, its a lot easier anyways
ES is amazing for what it does, but its use cases don't overlap heavily with Mongo (or RDBMSes).
Earlier quoted context omitted.
> Also it stills remains one of the simplest databases to setup and use making it still my goto for hacks/spikes. It's not hard to make it easy to do a thing in the wrong way - and that's exactly what MongoDB does. It doesn't make you set up authentication or table schemas, so it looks 'really easy to set up'. In reality, though, you're wasting hours to save 10 minutes. Because at a later point, you're going to have…
What exactly are you talking about ? Why would I care about having my database broken into or even my data being corrupted for hacks/spikes. The very definition of these is that they are throwaway designed to test an idea before rebuilding in something more suitable. And yes MongoDB is schemaless. That doesn't mean your data is going to automatically corrupt itself. You can just define your schema in some shared libr…
No. There's no rule that says a prototype must be thrown away - often, it can be built upon further. See also https://news.ycombinator.com/item?id=9913563
> And yes MongoDB is schemaless. That doesn't mean your data is going to automatically corrupt itself. You can just define your schema in some shared library.
This doesn't work if there is no shared library, for example if you have two separate components in different languages both using the database. And at that point you're (poorly) reinventing a schemaful database anyway.
> I can just as easily corrupt PostgreSQL if I change data types without updating the ORM.
A good ORM will abide by your database schema - and no, you can't "corrupt PostgreSQl" by "not updating your ORM". It will, at most, error out because you're trying to work with non-existent columns.
In a schemaless database, there's no such thing as "non-existent columns", thus you can quietly corrupt data without realizing it.
Earlier quoted context omitted.
The word 'loss' does not appear on that page. There's a world of difference IMO between a rejected operation (which is what I would assume from that description – that the address space exhaustion would be detected and the database would stop accepting writes) and irreversible data loss.
That's a consequence of their unacknowledged writes default - any write which failed for any reason wouldn't result in a rejection as far as the client is concerned (because the default was to shove the write request into the pipe and then continue without waiting for acknowledgement). As I mentioned earlier, most everyone acknowledges (heh) that as a bad default. If you were checking getLastError on your writes, you…
Earlier quoted context omitted.
yeap... but you have to give up many of the reasons for using meteor. (the dynamic refresh, etc.) The package is really just a simple wrapper around an npm library. Because meteor is node-based any db that node has libraries for can be "used" .... at the expense of giving up on most meteor features.
IFRC, postres can notify clients of changes, so you should be able to implement the missing features - that is to say the limitations are artificial at this point
Take it up with the Meteor.com people.
I've used MongoDB recently for the first time, for an internal project. Being schemaless, I believe it did speed up development time significantly, and allowed me to add stuff more gradually, but you could say that's just a way to indulge a certain laziness of design. Now that the project has matured, stepping back I can see how a relational database would be a better fit, but if I had used a rdbms from the beginning…
> but if I had used a rdbms from the beginning I might have not "shipped" quite as quickly. I doubt that. As mentioned in the article, migrations with rollbacks basically solve this problem, and let you iterate through schemas quickly. > Swapping it out for a real rdbms will mean changing a couple of classes anyway, nothing dramatic. In theory, perhaps, but I have yet to see that in practice. I do freelance code revi…
Maybe so, but as I said above, they are another thing to do at a time when things are changing fast and one is more worried about checking whether the application "makes sense" than proving its correctness, so to speak.
> I do freelance code review and tutoring for a living, and in every case I've seen, a significant amount of work would be needed
Well, duh: if this weren't the case, you wouldn't have been involved in the first place :) What company calls consultants to review code they know how to fix themselves in a few minutes?
As a smaller setup that requires far less traffic than a large scale real-time application, what are the draw backs of just using a basic MySQL installation? We've hit over 20k views per day on our internal wiki with no signs of even coming close to any limits with either our hardware or the SQL stack.
Earlier quoted context omitted.
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.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 init…
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…
Bad defaults? It was defended as "this is ok because system is distributed" and there was a joke about it helping ace all the silly benchmarks. So it wasn't "oops we forgot to uncomment out the fsync line in the code". It was a deliberate decision.
It was deceptive, and that is why many people hate MongoDB and wouldn't let it get even close to their data -- because have a track record of lying about the capabilities of their system.