4 ms·

Because it's not a particularly good database, but it's being marketed strongly. There are better (more mature, easier to maintain, faster, etc.) alternatives

by lucian1900 14y ago

Because it's not a particularly good database, but it's being marketed strongly. There are better (more mature, easier to maintain, faster, etc.) alternatives for both single-machine (Postgres, MySQL) and distributed (Cassandra, HBase) usage. It's a pain to take care of, it does table scans all the time (partly because it has no schema, partly because of design issues), it has pretty poor profiling tools. It's almost impossible to use without a model/schema in the app. Migrations are a pain. The one thing it's particularly well suited at is indexing and searching JSON-like data.

corresation 14y ago
for both single-machine (Postgres, MySQL) and distributed (Cassandra, HBase) usage. I'm surprised that MySQL Cluster Edition doesn't get more attention in the scale-out space. It is a simply brilliant product.
- TylerE 14y ago
  Because MySQL is owned by Oracle.
lttlrck 14y ago
'The one thing it's particularly well suited at is indexing and searching JSON-like data.' OMG! What a surprise! The fact that I read the documentation and through testing discovered its a perfect fit for our application means I am not one of the 'everybody' that hates it.
eknkc 14y ago
It's easy to jump in, and able to provide decent environment for developers. I believe that's similar to early MySQL, you know with only MyISAM tables, where there was no transaction support or referential integrity and your data was open to all kinds of corruption issues. It was easy to use, was installed almost everywhere and there were great tools around it. It has grown to be a pretty decent RDBMS. Mongo has the same traction behind it, so it should become a great solution in no time. (Given a decent development process it is. See PHP for a counter example)
- lucian1900 14y ago
  But why wait, when you can use Postgres now?
  - eknkc 14y ago
    I'm not saying that I would not use Postgres now. Actually, I've been running a website on MongoDB for over a year now. I don't remember the reason behind it but it haven't caused any problems so far. The web server handles more than a million page views per day and all data is stored on MongoDB. I'm not perfectly happy with it but it does what it's supposed to. With some gimmicks here and there. If I started from scratch today, I'd probably go with PostgreSQL. Not because MongoDB is "bad" but because it's data model itself causes some problems. For example, if you query some range on an index with upper and lower bounds (like age > 18 && age < 50) it can not use both bounds on the index. That's been driving me crazy on some queries and I had to use hacky indexes. It's not a bug though, it's the query syntax and data model causing these kind of behaviour. There have been similar examples during this last year but not something that would cause "hate" agains it. On the plus side, it makes prototyping stuff so pleasantly easy that you can not have that on PostgreSQL.
    - lucian1900 14y ago
      I consider it a design flaw that queries can only use one index. In fact, many queries can never use any index (I had to write a query optimiser because mongo doesn't bother). Actually some queries do use more than one index (top-level $or), but it's actually more annoying than useful. I find especially during prototyping having a clear data model is great. SQLAlchemy + Postgres, then later on Alembic for migrations is so much more pleasant, predictable and performant.
- deleted 14y ago
  [deleted]
nateabele 14y ago
You have clearly never attempted to use Cassandra in a production (or likely any) capacity. Just sayin'.
- lucian1900 14y ago
  Admittedly I haven't used older versions of Cassandra, or under as much load as I have Postgres or Mongo. My point was that it is designed for being distributed and it doesn't hide that fact. Mongo's replica sets and sharding are much less transparent and much less predictable.
- StavrosK 14y ago
  What's wrong with it?
jasonmccay 14y ago
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.

corresation 14y ago

for both single-machine (Postgres, MySQL) and distributed (Cassandra, HBase) usage. I'm surprised that MySQL Cluster Edition doesn't get more attention in the scale-out space. It is a simply brilliant product.

TylerE 14y ago
Because MySQL is owned by Oracle.

lttlrck 14y ago

'The one thing it's particularly well suited at is indexing and searching JSON-like data.' OMG! What a surprise! The fact that I read the documentation and through testing discovered its a perfect fit for our application means I am not one of the 'everybody' that hates it.

eknkc 14y ago

It's easy to jump in, and able to provide decent environment for developers. I believe that's similar to early MySQL, you know with only MyISAM tables, where there was no transaction support or referential integrity and your data was open to all kinds of corruption issues. It was easy to use, was installed almost everywhere and there were great tools around it. It has grown to be a pretty decent RDBMS. Mongo has the same traction behind it, so it should become a great solution in no time. (Given a decent development process it is. See PHP for a counter example)

lucian1900 14y ago
But why wait, when you can use Postgres now?
- eknkc 14y ago
  I'm not saying that I would not use Postgres now. Actually, I've been running a website on MongoDB for over a year now. I don't remember the reason behind it but it haven't caused any problems so far. The web server handles more than a million page views per day and all data is stored on MongoDB. I'm not perfectly happy with it but it does what it's supposed to. With some gimmicks here and there. If I started from scratch today, I'd probably go with PostgreSQL. Not because MongoDB is "bad" but because it's data model itself causes some problems. For example, if you query some range on an index with upper and lower bounds (like age > 18 && age < 50) it can not use both bounds on the index. That's been driving me crazy on some queries and I had to use hacky indexes. It's not a bug though, it's the query syntax and data model causing these kind of behaviour. There have been similar examples during this last year but not something that would cause "hate" agains it. On the plus side, it makes prototyping stuff so pleasantly easy that you can not have that on PostgreSQL.
  - lucian1900 14y ago
    I consider it a design flaw that queries can only use one index. In fact, many queries can never use any index (I had to write a query optimiser because mongo doesn't bother). Actually some queries do use more than one index (top-level $or), but it's actually more annoying than useful. I find especially during prototyping having a clear data model is great. SQLAlchemy + Postgres, then later on Alembic for migrations is so much more pleasant, predictable and performant.
deleted 14y ago
[deleted]

nateabele 14y ago

You have clearly never attempted to use Cassandra in a production (or likely any) capacity. Just sayin'.

lucian1900 14y ago
Admittedly I haven't used older versions of Cassandra, or under as much load as I have Postgres or Mongo. My point was that it is designed for being distributed and it doesn't hide that fact. Mongo's replica sets and sharding are much less transparent and much less predictable.
StavrosK 14y ago
What's wrong with it?

jasonmccay 14y ago

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.