6 ms·

Because when you're not operating at significant scale, or have certain specific use cases, it's a fantastically elegant solution and one that's very quick and

by aroman 13y ago

Because when you're not operating at significant scale, or have certain specific use cases, it's a fantastically elegant solution and one that's very quick and easy to set up. I have used mongodb for a number of smaller projects, and I have had an excellent experience. It's not "a terrible idea in practice". It might be a terrible fit for what you want, but that doesn't mean it's bad technology.

JulianMorrison 13y ago
Are you dead certain those projects aren't ever eating data, and nor are they about to crash tomorrow with an unrecoverably hosed DB? I still say it's bad technology. Use plain old SQL instead.
- lmm 13y ago
  "plain old SQL" can require a lot of mangling one's data to fit its constraints. I refuse to believe that there isn't a better key-value store for the case where the values are json documents, even if mongodb isn't it.
  - gaius 13y ago
    Except it isn't "SQL" it's first-order predicate calculus - a provably sound way to store and query your data.
  - pwg 13y ago
    But if one is going to use a key-value store anyway, where is the "mangling"? Building a key-value store in an SQL database is trivial (this below is for PostgreSQL): create table keyvalue (key text, value text); create index keyvalue_idx on keyvalue(key); And use is trivial as well: insert into keyvalue (key, value) values ('key', 'value'); select value from keyvalue where key = 'key'; [edit] formatting fix.
    - lmm 13y ago
      It is not nice to have to manipulate JSON as a plain string (you miss out on validation, have to manually construct like expressions for queries, and I don't even want to think about what you'd have to do to update part of a document), at least using "plain old SQL". (PostgreSQL's native JSON support would make it quite easy, but that supports my point)
      - snaky 13y ago
        If you need to query JSON content, why to store it like plain string, to begin with? Parse it at application level (or even in stored procedure) and store like ordinary fields. Or use hstore.
        kanja 13y ago
        Postgres additionally has a json field type.
        snaky 13y ago
        That is for now, until PostgreSQL 9.3 released, have only one useful feature comparing to plain string - validation. That's not much help, and that original lmm's point was about.
  - JulianMorrison 13y ago
    Redis. Riak. Rethinkdb. Cassandra (with a mapping layer). SQL (with a mapping layer). SQL, in a JSON-typed column (PostgreSQL supports it). SQL, in a blob field, plus indexes. I could go on.
timr 13y ago
"when you're not operating at significant scale, or have certain specific use cases, it's a fantastically elegant solution and one that's very quick and easy to set up." When you're not operating at significant scale, you can use a relational database. They're easy and fast to set up, have nice write-safety guarantees, are more flexible than a key-value store, and will scale well beyond anything that mongo has ever achieved. You can even use them as a key-value store! The downside, of course, is that you have to a tiny bit of knowledge about set theory, and that's a deal breaker for most "developers" today. The whole point of the GP was that Mongo isn't elegant or easy...it's just naive and short-sighted, and the architectural mistakes within it are fundamental and probably unfixable (at least, not without killing the speed advantages they claim). The real reason that people use mongo is that most webapp devs don't have a very good understanding of how computers work, and want everything to look like Javascript, because that's all they really know.
- lucisferre 13y ago
  You lost me when you quoted the word "developers". Edit: And this is downvoted for calling out the fact that people on HN can't discuss a freakin' database without hurling insults.
  - timr 13y ago
    I quoted "developers", because we need a term to distinguish people who know basic computer science from people who know just enough to install software and piece together APIs. The latter group tends not to realize that things like overwriting your working set in memory and global write-locking lead inevitably to consistency and throughput issues. The primary problem in software today is that we've confused the ability to build something with actually knowing anything of value.
    - lucisferre 13y ago
      In the real world though, both groups still need to use what works in practice. It's entirely possible for MongoDB to work sufficiently well for a certain group of people in a reasonably cost effective way. Exaggerating its problems (as bad as they are) doesn't add weight to your agrement. For example, global write-locking will not _inevitably_ lead to consistency or throughput unless the write frequencies are sufficient to cause and require that. Lots of data problems aren't "big data", they're barely a medium. I'll agree MongoDB is not a terribly well engineered database however I don't agree that SQL is always the best alternative in these simpler scenarios. There are lots of things wrong with using SQL to solve every data problem. I also don't agree that knowing SQL is equivalent to understanding "set theory". I've known plenty of DBAs who don't know the first thing about set theory and really just know just enough to install the software and piece together the APIs. The fact that one has chosen SQL doesn't make them good at working with data any more than choosing MongoDB makes someone bad, or implies they don't understand "set theory". What concerns me mostly though isn't the MongoDB issue but that we can't discus the issue in a professional way, without elitism and distain dripping through. You seem to have confused "computer science" with "anything of value". I happen to believe there are more things worth knowing that are of value to practical software development than just the computer science (not to minimize that of course).

by aroman 13y ago

JulianMorrison 13y ago

Are you dead certain those projects aren't ever eating data, and nor are they about to crash tomorrow with an unrecoverably hosed DB? I still say it's bad technology. Use plain old SQL instead.

lmm 13y ago
"plain old SQL" can require a lot of mangling one's data to fit its constraints. I refuse to believe that there isn't a better key-value store for the case where the values are json documents, even if mongodb isn't it.
- gaius 13y ago
  Except it isn't "SQL" it's first-order predicate calculus - a provably sound way to store and query your data.
- pwg 13y ago
  But if one is going to use a key-value store anyway, where is the "mangling"? Building a key-value store in an SQL database is trivial (this below is for PostgreSQL): create table keyvalue (key text, value text); create index keyvalue_idx on keyvalue(key); And use is trivial as well: insert into keyvalue (key, value) values ('key', 'value'); select value from keyvalue where key = 'key'; [edit] formatting fix.
  - lmm 13y ago
    It is not nice to have to manipulate JSON as a plain string (you miss out on validation, have to manually construct like expressions for queries, and I don't even want to think about what you'd have to do to update part of a document), at least using "plain old SQL". (PostgreSQL's native JSON support would make it quite easy, but that supports my point)
    - snaky 13y ago
      If you need to query JSON content, why to store it like plain string, to begin with? Parse it at application level (or even in stored procedure) and store like ordinary fields. Or use hstore.
      - kanja 13y ago
        Postgres additionally has a json field type.
        snaky 13y ago
        That is for now, until PostgreSQL 9.3 released, have only one useful feature comparing to plain string - validation. That's not much help, and that original lmm's point was about.
- JulianMorrison 13y ago
  Redis. Riak. Rethinkdb. Cassandra (with a mapping layer). SQL (with a mapping layer). SQL, in a JSON-typed column (PostgreSQL supports it). SQL, in a blob field, plus indexes. I could go on.

timr 13y ago

"when you're not operating at significant scale, or have certain specific use cases, it's a fantastically elegant solution and one that's very quick and easy to set up." When you're not operating at significant scale, you can use a relational database. They're easy and fast to set up, have nice write-safety guarantees, are more flexible than a key-value store, and will scale well beyond anything that mongo has ever achieved. You can even use them as a key-value store! The downside, of course, is that you have to a tiny bit of knowledge about set theory, and that's a deal breaker for most "developers" today. The whole point of the GP was that Mongo isn't elegant or easy...it's just naive and short-sighted, and the architectural mistakes within it are fundamental and probably unfixable (at least, not without killing the speed advantages they claim). The real reason that people use mongo is that most webapp devs don't have a very good understanding of how computers work, and want everything to look like Javascript, because that's all they really know.

lucisferre 13y ago
You lost me when you quoted the word "developers". Edit: And this is downvoted for calling out the fact that people on HN can't discuss a freakin' database without hurling insults.
- timr 13y ago
  I quoted "developers", because we need a term to distinguish people who know basic computer science from people who know just enough to install software and piece together APIs. The latter group tends not to realize that things like overwriting your working set in memory and global write-locking lead inevitably to consistency and throughput issues. The primary problem in software today is that we've confused the ability to build something with actually knowing anything of value.
  - lucisferre 13y ago
    In the real world though, both groups still need to use what works in practice. It's entirely possible for MongoDB to work sufficiently well for a certain group of people in a reasonably cost effective way. Exaggerating its problems (as bad as they are) doesn't add weight to your agrement. For example, global write-locking will not _inevitably_ lead to consistency or throughput unless the write frequencies are sufficient to cause and require that. Lots of data problems aren't "big data", they're barely a medium. I'll agree MongoDB is not a terribly well engineered database however I don't agree that SQL is always the best alternative in these simpler scenarios. There are lots of things wrong with using SQL to solve every data problem. I also don't agree that knowing SQL is equivalent to understanding "set theory". I've known plenty of DBAs who don't know the first thing about set theory and really just know just enough to install the software and piece together the APIs. The fact that one has chosen SQL doesn't make them good at working with data any more than choosing MongoDB makes someone bad, or implies they don't understand "set theory". What concerns me mostly though isn't the MongoDB issue but that we can't discus the issue in a professional way, without elitism and distain dripping through. You seem to have confused "computer science" with "anything of value". I happen to believe there are more things worth knowing that are of value to practical software development than just the computer science (not to minimize that of course).