4 ms·

You are making sweeping (but vague) negative characterizations of a technology while, at the same time, accusing the company that created the technology of mark

You are making sweeping (but vague) negative characterizations of a technology while, at the same time, accusing the company that created the technology of marketing it strongly. When DHH created Rails, was it his job to tell you all the reasons why you should not use it over Java/.NET/PHP or, instead, to tell you all the reasons that he created it and the problems that he was trying to solve by developing apps with it? To say that there are better alternatives implies that you understand everyone's use case. It is faulty logic. One of the reasons for the revolt that was "NoSQL" was an attempt to get people to stop shoe-horning data into MySQL ... so the concept of developers using database engines poorly isn't new. Same with MongoDB and developers that use it based on their experiences with MySQL or other relational (or non-relational) models. I have seen people use MongoDB to great (even amazing) success and have seen others use it very poorly. In both cases, it was the developer (and not the technology) that was responsible for the way they used the technology.

lucian1900 14y ago
I blame both the technology for being poor and the creators for claiming things it cannot really do. While all tools can be used both well and poorly, some tools are just poor themselves.
- jasonmccay 14y ago
  Can you offer an example of the creators claiming that it does something that it really cannot do? Also, while MongoDB does have its faults and some sharp edges, it is far from poor. For the most part, 2.x MongoDB is solid, performs well and generally without issue.
  - lucian1900 14y ago
    They claim the oplog ensures durability, but it actually gets written and fsynced quite late in the process. This becomes quite obvious when the master of your replicaset changes: clients will receive errors and you will get inconsistent data you have to clean up later. This is the sort of thing Postgres and even Redis get right. They claim sharding works up to a high number of nodes, but even when following their recommendations, it's pretty easy to get inconsistencies. Also, many useful commands don't work (or work differently) with sharding. This is the sort of thing Cassandra and HBase get right. They used to claim you can have control over whether reads/writes happen on the master or slaves, but not all commands supported this differentiation. There's was safe and masterOnly, but they don't always apply (and amazingly enough, don't always work). This is the sort of thing Cassandra gets right, and at least newer Mongo (and clients) support more granularity, and more consistently. They claim certain benchmark numbers, but neglect to mention they're done without durability or any router/replica/shard setup. It's nothing overly enthusiastic creators of a new database wouldn't be expected to do, but still annoying.
    - ranman 14y ago
      AFAIK 10gen vehemently refrains from releasing benchmarks.
cpleppert 14y ago
There is something to be said for well architected software independent of any features that one may find attractive in it. For databases this is a big problem as you often don't find out about technical problems until you are already committed to the technology and are trying to scale it. The same thing happened with MySQL and now it looks like it is happening with MongoDB as well. Mongo has so many corner cases and although I have never scaled it up in production the amount of moving pieces and the clear lack of attention paid to distributed programming literature in the design doesn't inspire a lot of confidence. Technical problems with MongoDB are being explained away as features in the same way MySQL did. Why does Mongo MMAP its datafiles?? So the cache stays warm!!! Why doesn't MySQL have transactions? No one needs transactions, just lock the table !! If you didn't consider these cases you might think that Mongo sounded pretty good. I don't fault 10gen for pushing this hard and taking advantage of the perception that NoSQL is a more modern technology. I just can't believe there isn't something better that does what Mongo does.
- lucian1900 14y ago
  RethinkDB looks to be a better Mongo. It even does MVCC, the lack of which I certainly felt with Mongo (can't do analytics queries on your data or build indexes without DoS-ing your db).
  - coffeemug 14y ago
    We also don't mmap the data files, though it's much more relevant to the internal architecture than user facing features :)

lucian1900 14y ago

I blame both the technology for being poor and the creators for claiming things it cannot really do. While all tools can be used both well and poorly, some tools are just poor themselves.

jasonmccay 14y ago
Can you offer an example of the creators claiming that it does something that it really cannot do? Also, while MongoDB does have its faults and some sharp edges, it is far from poor. For the most part, 2.x MongoDB is solid, performs well and generally without issue.
- lucian1900 14y ago
  They claim the oplog ensures durability, but it actually gets written and fsynced quite late in the process. This becomes quite obvious when the master of your replicaset changes: clients will receive errors and you will get inconsistent data you have to clean up later. This is the sort of thing Postgres and even Redis get right. They claim sharding works up to a high number of nodes, but even when following their recommendations, it's pretty easy to get inconsistencies. Also, many useful commands don't work (or work differently) with sharding. This is the sort of thing Cassandra and HBase get right. They used to claim you can have control over whether reads/writes happen on the master or slaves, but not all commands supported this differentiation. There's was safe and masterOnly, but they don't always apply (and amazingly enough, don't always work). This is the sort of thing Cassandra gets right, and at least newer Mongo (and clients) support more granularity, and more consistently. They claim certain benchmark numbers, but neglect to mention they're done without durability or any router/replica/shard setup. It's nothing overly enthusiastic creators of a new database wouldn't be expected to do, but still annoying.
  - ranman 14y ago
    AFAIK 10gen vehemently refrains from releasing benchmarks.

cpleppert 14y ago

There is something to be said for well architected software independent of any features that one may find attractive in it. For databases this is a big problem as you often don't find out about technical problems until you are already committed to the technology and are trying to scale it. The same thing happened with MySQL and now it looks like it is happening with MongoDB as well. Mongo has so many corner cases and although I have never scaled it up in production the amount of moving pieces and the clear lack of attention paid to distributed programming literature in the design doesn't inspire a lot of confidence. Technical problems with MongoDB are being explained away as features in the same way MySQL did. Why does Mongo MMAP its datafiles?? So the cache stays warm!!! Why doesn't MySQL have transactions? No one needs transactions, just lock the table !! If you didn't consider these cases you might think that Mongo sounded pretty good. I don't fault 10gen for pushing this hard and taking advantage of the perception that NoSQL is a more modern technology. I just can't believe there isn't something better that does what Mongo does.

lucian1900 14y ago
RethinkDB looks to be a better Mongo. It even does MVCC, the lack of which I certainly felt with Mongo (can't do analytics queries on your data or build indexes without DoS-ing your db).
- coffeemug 14y ago
  We also don't mmap the data files, though it's much more relevant to the internal architecture than user facing features :)