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.
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.
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.
I fail to see how a multi-threaded architecture is a problem with Postgres.
While it's not a fundamental issue, it does have some considerable drawbacks. A lot of the work required to make query processing use multiple cores (9.6, and the upcoming 10 release), would've been a lot easier if there were a shared memory space. There's no portable way to guarantee that shared memory that's allocated after process start can be mapped to the same addresses in different processes, so you've to deal with a relative addressing etc, which both complicates and slows down.
There's also upsides, don't get me wrong. Primarily around robustness in case of failures, but also some around resource isolation.
CockroachDB reached 1.0 less than 2 months ago. I'm not sure what your domain is, but personally I would be very hesitant to go with a database which is so new
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).
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.
Comments
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.
"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.
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.
I fail to see how a multi-threaded architecture is a problem with Postgres.
Postgres supports JSON type(and XML), so no.
While it's not a fundamental issue, it does have some considerable drawbacks. A lot of the work required to make query processing use multiple cores (9.6, and the upcoming 10 release), would've been a lot easier if there were a shared memory space. There's no portable way to guarantee that shared memory that's allocated after process start can be mapped to the same addresses in different processes, so you've to deal with a relative addressing etc, which both complicates and slows down.
There's also upsides, don't get me wrong. Primarily around robustness in case of failures, but also some around resource isolation.
CockroachDB called, problem solved for SQL with ACID.
Replication and Sharding are easy.
How is this relevant ?
MongoDB is a document database. If you use CockroachDB you lose this capability.
CockroachDB reached 1.0 less than 2 months ago. I'm not sure what your domain is, but personally I would be very hesitant to go with a database which is so new
MongoDB escaped being glorified /dev/null just last fall.
https://jepsen.io/analyses/mongodb-3-4-0-rc3
Exactly, this is an argument in waiting for the real-world behaviour of the database to be well understood
Have you actually used replica set and sharding?
I did and it is a complete disaster in MongoDB.
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).
Postgresql had never had a great story for sharding large datasets.
Maybe it can be used as an advanced cache with persistense and secondary indexes?
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.