5 ms·

MongoDB has purpose, but inventory management is not one of those purposes.

by russdpale 9y ago

gaius 9y ago
MongoDB has purpose It literally does not.
- paulddraper 9y ago
  I think you're trolling but in case you aren't: structured logging, distributed cache, heterogenous analytics. You might prefer other solutions to each just as I prefer technologies other than Perl, but "no purpose" is incorrect.
  - gaius 9y ago
    There are better solutions to all of those use cases. Logging? ELK. Cache? Redis. Not sure what you mean by "heterogenous analytics" but that's usually a layer on top of whatever data store you choose, and we've established that MongoDB just isn't a good data store.
  - user5994461 9y ago
    It's not trolling. MongoDB really doesn't have a purpose. There is nothing it is good at. https://thehftguy.com/2017/03/29/whats-the-best-nosql-database-cassandra-vs-mongodb-vs-redis-vs-elasticsearch/ https://thehftguy.com/2017/03/29/whats-the-best-nosql-databa... logging => elasticsearch distributed cache => memcache analytics => any SQL database for low volume (< 1TB). any data warehouse database for high volume (> 10TB).
    - paulddraper 9y ago
      "Memcache" Requires holding all data in RAM. Loses all data on a restart. Can't cache values more than 1mb. (Not that these are necessarily terrible; they're limitations that may not be appropriate for all uses.) "Don't use mongo, use any data warehouse database" That's what I suggested; you just turned it into an abstract recommendation.
- united893 9y ago
  All the cool kids are beating up this mongo kid, let's join in, we'll be cool too! I'm sorry but your comment here on HN adds no value other than just piling on. MongoDB has indeed a purpose, and it's wildly misunderstood. MongoDB initially optimized for engineering efficiency (allowing developers to prototype quickly) over engineering quality. This allowed them to gain market share and with the newfound wealth (and unicorn valuation) then buy up a real storage engine which supports transactions, and written by DB veterans (of BerkeleyDB fame). Early versions were definitely buggy, but since bringing in WiredTiger, they're now a serious player. That initial gamble on optimizing for engineering ease-of-use is the reason they're not out of business, like Rethink and Basho. As a startup you have to hustle, can't just sell on the philosophical beauty of cleanly abstracted haskell.
  - gaius 9y ago
    That initial gamble on optimizing for engineering ease-of-use But that was not a clever gambit. They had a bad product that they told a lot of lies about. That they got rich doing that is a sad indictment of our industry.
    - threeseed 9y ago
      Have you actually the product ? And be honest here. Because it was never a truly awful product. Yes it had some bugs but it was no worse than what we were seeing with Oracle or Cassandra. And if you call marketing blurbs "lies" then I am surprised you manage to survive day to day at all. PostgreSQL calls their database the "most advanced", Oracle calls theirs "#1 Database for Cloud Scale Simplicity". It's just regular marketing fluff.
      - brianwawok 9y ago
        I used it. It was awful. I cannot think of a single use case for mongo.
      - gaius 9y ago
        Yep. Project to replace a single 24-core, 24G, SAN-connected Oracle box with 10 48-core, 96G boxes with internal SSD running Mongo. The Oracle box was faster and had a DBA look at it maybe once a week. The Mongo setup required a full time team of a half dozen people. It's a complete joke. And their marketing lies included "you don't need a DBA"..
s_kilk 9y ago
Indeed. The truth is that MongoDB is well suited to a fairly narrow set of use-cases, but ends up being used for all sorts of stuff in practice. Hence the weird contortions which the author observes in the book they're reading.
camus2 9y ago
> MongoDB has purpose, but inventory management is not one of those purposes. What purpose does it have frankly? The only one I see might be GridFS for what it is worth, though I don't believe one second the performances are that great, but when it comes to document oriented DB, Postgres can store both JSON and XML and query them and also do partial atomic changes. Scaling? easier maybe... Now competition is good and I'm sure NoSQL db success kind of forced traditional players to innovate. But I see no reason to use MongoDB in 2017.
- weddpros 9y ago
  "No reason to use MongoDB in 2017" I would reply: replica sets and sharding and multi-threaded architecture and the absence of impedance mismatch, all in a single product that was designed for these features.
  - user5994461 9y ago
    Have you actually used replica set and sharding? I did and it is a complete disaster in MongoDB.
    - threeseed 9y ago
      Yes. With hundreds of nodes. MongoDB also has some very large customers using it so clearly it isn't a complete disaster. I would chose to use it over PostgreSQL any day of the week (not that there is a clear option regardless).
  - camus2 9y ago
    > I would reply: replica sets and sharding and multi-threaded architecture and the absence of impedance mismatch, all in a single product that was designed for these features. If you don't care about data integrity, transactions and efficiency, then by all means. But in that case, a distributed file system is as efficient. > multi-threaded architecture I fail to see how a multi-threaded architecture is a problem with Postgres. > the absence of impedance mismatch Postgres supports JSON type(and XML), so no.

MongoDB has purpose, but inventory management is not one of those purposes.

gaius 9y ago

MongoDB has purpose It literally does not.

paulddraper 9y ago
I think you're trolling but in case you aren't: structured logging, distributed cache, heterogenous analytics. You might prefer other solutions to each just as I prefer technologies other than Perl, but "no purpose" is incorrect.
- gaius 9y ago
  There are better solutions to all of those use cases. Logging? ELK. Cache? Redis. Not sure what you mean by "heterogenous analytics" but that's usually a layer on top of whatever data store you choose, and we've established that MongoDB just isn't a good data store.
- user5994461 9y ago
  It's not trolling. MongoDB really doesn't have a purpose. There is nothing it is good at. https://thehftguy.com/2017/03/29/whats-the-best-nosql-database-cassandra-vs-mongodb-vs-redis-vs-elasticsearch/ https://thehftguy.com/2017/03/29/whats-the-best-nosql-databa... logging => elasticsearch distributed cache => memcache analytics => any SQL database for low volume (< 1TB). any data warehouse database for high volume (> 10TB).
  - paulddraper 9y ago
    "Memcache" Requires holding all data in RAM. Loses all data on a restart. Can't cache values more than 1mb. (Not that these are necessarily terrible; they're limitations that may not be appropriate for all uses.) "Don't use mongo, use any data warehouse database" That's what I suggested; you just turned it into an abstract recommendation.
united893 9y ago
All the cool kids are beating up this mongo kid, let's join in, we'll be cool too! I'm sorry but your comment here on HN adds no value other than just piling on. MongoDB has indeed a purpose, and it's wildly misunderstood. MongoDB initially optimized for engineering efficiency (allowing developers to prototype quickly) over engineering quality. This allowed them to gain market share and with the newfound wealth (and unicorn valuation) then buy up a real storage engine which supports transactions, and written by DB veterans (of BerkeleyDB fame). Early versions were definitely buggy, but since bringing in WiredTiger, they're now a serious player. That initial gamble on optimizing for engineering ease-of-use is the reason they're not out of business, like Rethink and Basho. As a startup you have to hustle, can't just sell on the philosophical beauty of cleanly abstracted haskell.
- gaius 9y ago
  That initial gamble on optimizing for engineering ease-of-use But that was not a clever gambit. They had a bad product that they told a lot of lies about. That they got rich doing that is a sad indictment of our industry.
  - threeseed 9y ago
    Have you actually the product ? And be honest here. Because it was never a truly awful product. Yes it had some bugs but it was no worse than what we were seeing with Oracle or Cassandra. And if you call marketing blurbs "lies" then I am surprised you manage to survive day to day at all. PostgreSQL calls their database the "most advanced", Oracle calls theirs "#1 Database for Cloud Scale Simplicity". It's just regular marketing fluff.
    - brianwawok 9y ago
      I used it. It was awful. I cannot think of a single use case for mongo.
    - gaius 9y ago
      Yep. Project to replace a single 24-core, 24G, SAN-connected Oracle box with 10 48-core, 96G boxes with internal SSD running Mongo. The Oracle box was faster and had a DBA look at it maybe once a week. The Mongo setup required a full time team of a half dozen people. It's a complete joke. And their marketing lies included "you don't need a DBA"..

s_kilk 9y ago

Indeed. The truth is that MongoDB is well suited to a fairly narrow set of use-cases, but ends up being used for all sorts of stuff in practice. Hence the weird contortions which the author observes in the book they're reading.

camus2 9y ago

> MongoDB has purpose, but inventory management is not one of those purposes. What purpose does it have frankly? The only one I see might be GridFS for what it is worth, though I don't believe one second the performances are that great, but when it comes to document oriented DB, Postgres can store both JSON and XML and query them and also do partial atomic changes. Scaling? easier maybe... Now competition is good and I'm sure NoSQL db success kind of forced traditional players to innovate. But I see no reason to use MongoDB in 2017.

weddpros 9y ago
"No reason to use MongoDB in 2017" I would reply: replica sets and sharding and multi-threaded architecture and the absence of impedance mismatch, all in a single product that was designed for these features.
- user5994461 9y ago
  Have you actually used replica set and sharding? I did and it is a complete disaster in MongoDB.
  - threeseed 9y ago
    Yes. With hundreds of nodes. MongoDB also has some very large customers using it so clearly it isn't a complete disaster. I would chose to use it over PostgreSQL any day of the week (not that there is a clear option regardless).
- camus2 9y ago
  > I would reply: replica sets and sharding and multi-threaded architecture and the absence of impedance mismatch, all in a single product that was designed for these features. If you don't care about data integrity, transactions and efficiency, then by all means. But in that case, a distributed file system is as efficient. > multi-threaded architecture I fail to see how a multi-threaded architecture is a problem with Postgres. > the absence of impedance mismatch Postgres supports JSON type(and XML), so no.