3 ms·

The creator of Envoy had some choice words about Mongo a few days ago. https://twitter.com/mattklein123/status/1074717204224999427 https://twitter.com/mattklein

The creator of Envoy had some choice words about Mongo a few days ago. https://twitter.com/mattklein123/status/1074717204224999427 https://twitter.com/mattklein123/status/1074717204224999427 Plenty of people here like to dish on Mongo and the product seems to have been re-architected a few times since I used it seven years ago. By what metrics can we say the product is one worthy of passing a HN smell test? Passing Jepsen was seemingly not enough. https://www.mongodb.com/jepsen https://www.mongodb.com/jepsen

jimktrains2 8y ago
Passing might not be the right way to look at it? > This interpretation hinges on interpreting successful sub-majority writes as not necessarily successful: rather, a successful response is merely a suggestion that the write has probably occurred, or might later occur, or perhaps will occur, be visible to some clients, then un-occur, or perhaps nothing will happen whatsoever. > We note that this remains MongoDB's default level of write safety. - http://jepsen.io/analyses/mongodb-3-6-4 http://jepsen.io/analyses/mongodb-3-6-4 2018-10-23
politician 8y ago
Are you reading the detailed reports prepared by the Jepsen audit team, or the press release? Jepsen audits are public. The summary of the latest MongoDB report [1] follows, "In this Jepsen report, we will verify that MongoDB 3.6.4’s sharded clusters offer comparable safety to non-sharded deployments. We’ll also discuss MongoDB’s new support for causal consistency (CC) in version 3.6.4 and 4.0.0-rc1, and show that sessions prevent anomalies so long as user stick to majority reads and writes. However, with MongoDB’s default consistency levels, CC sessions fail to provide the claimed invariants." [1] http://jepsen.io/analyses/mongodb-3-6-4 http://jepsen.io/analyses/mongodb-3-6-4
ken 8y ago
> the product seems to have been re-architected a few times since I used it seven years ago That's really not what I want to hear about a place I'd be storing data. Was it just a prototype back then? (When did it stop being a prototype?) Would the creators be comfortable using version 1 still? Actually, I think that could be a good test of database stability: would you be willing to run a 5 year old version of your own software?
anyfoo 8y ago
> By what metrics can we say the product is one worthy of passing a HN smell test? Common sense and formal education? I'm sorry, I'm aware of how incredibly snarky and arrogant that sounds, but in this case I always struggled to comprehend how MongoDB, or most of "NoSQL" in general, was considered viable to begin with. "Schemaless" just immediately means that instead of the database keeping consistency, you now essentially have to do all your type and constraint checking in the application; I never understood how that's favorable, and how that remains maintainable in any way. On top of that, NoSQL (and maybe Mongo in particular?) also decided to throw away all guarantees that classical SQL databases have been offering for multiple decades for very good reason. I think everyone who's had a somewhat theoretical class on databases and learned about, for example, what ACID really means, will have smelled that something doesn't quite add up here.
- mooreds 8y ago
  > "Schemaless" just immediately means that instead of the database keeping consistency, you now essentially have to do all your type and constraint checking in the application... This is so true. Some component has to maintain integrity of the data. Should it be the application developer? Or the database software team? I know which one I'd choose, and which one is focused on data integrity and not business logic.
  - anyfoo 8y ago
    And it’s not just who you trust, it’s also at what layer you want to enforce your integrity and consistency. Not letting the db do that means that every part of the application that touches the database needs to do that enforcement. Even if you abstract that away into a strict layer directly above the database—which essentially means you’ve just implemented parts of a database on top of a database—you have to essentially invent and implement the methods and languages to do so yourself. At which point you’re pretty much guaranteed to be much worse of then if you had just let the DB do it. This might mean handling unexpected errors if you have a bug in your application logic, but that’s usually orders of magnitude better than introducing hard to fight inconsistencies.
  - jerrysievert 8y ago
harel 8y ago
In my previous startup we used mongo as the main datastore (this was pre Postgres 9.4, before indexable JSONB). It worked for us, and it worked fine. I saw the mob rising up against it, but we have not had any of the problems (maybe we just read the manual and had it configured correctly?). Today my go-to is postgres of course, but I had to wait until JSONB was out to make the switch.

jimktrains2 8y ago

Passing might not be the right way to look at it? > This interpretation hinges on interpreting successful sub-majority writes as not necessarily successful: rather, a successful response is merely a suggestion that the write has probably occurred, or might later occur, or perhaps will occur, be visible to some clients, then un-occur, or perhaps nothing will happen whatsoever. > We note that this remains MongoDB's default level of write safety. - http://jepsen.io/analyses/mongodb-3-6-4 http://jepsen.io/analyses/mongodb-3-6-4 2018-10-23

politician 8y ago

Are you reading the detailed reports prepared by the Jepsen audit team, or the press release? Jepsen audits are public. The summary of the latest MongoDB report [1] follows, "In this Jepsen report, we will verify that MongoDB 3.6.4’s sharded clusters offer comparable safety to non-sharded deployments. We’ll also discuss MongoDB’s new support for causal consistency (CC) in version 3.6.4 and 4.0.0-rc1, and show that sessions prevent anomalies so long as user stick to majority reads and writes. However, with MongoDB’s default consistency levels, CC sessions fail to provide the claimed invariants." [1] http://jepsen.io/analyses/mongodb-3-6-4 http://jepsen.io/analyses/mongodb-3-6-4

ken 8y ago

> the product seems to have been re-architected a few times since I used it seven years ago That's really not what I want to hear about a place I'd be storing data. Was it just a prototype back then? (When did it stop being a prototype?) Would the creators be comfortable using version 1 still? Actually, I think that could be a good test of database stability: would you be willing to run a 5 year old version of your own software?

anyfoo 8y ago

> By what metrics can we say the product is one worthy of passing a HN smell test? Common sense and formal education? I'm sorry, I'm aware of how incredibly snarky and arrogant that sounds, but in this case I always struggled to comprehend how MongoDB, or most of "NoSQL" in general, was considered viable to begin with. "Schemaless" just immediately means that instead of the database keeping consistency, you now essentially have to do all your type and constraint checking in the application; I never understood how that's favorable, and how that remains maintainable in any way. On top of that, NoSQL (and maybe Mongo in particular?) also decided to throw away all guarantees that classical SQL databases have been offering for multiple decades for very good reason. I think everyone who's had a somewhat theoretical class on databases and learned about, for example, what ACID really means, will have smelled that something doesn't quite add up here.

mooreds 8y ago
> "Schemaless" just immediately means that instead of the database keeping consistency, you now essentially have to do all your type and constraint checking in the application... This is so true. Some component has to maintain integrity of the data. Should it be the application developer? Or the database software team? I know which one I'd choose, and which one is focused on data integrity and not business logic.
- anyfoo 8y ago
  And it’s not just who you trust, it’s also at what layer you want to enforce your integrity and consistency. Not letting the db do that means that every part of the application that touches the database needs to do that enforcement. Even if you abstract that away into a strict layer directly above the database—which essentially means you’ve just implemented parts of a database on top of a database—you have to essentially invent and implement the methods and languages to do so yourself. At which point you’re pretty much guaranteed to be much worse of then if you had just let the DB do it. This might mean handling unexpected errors if you have a bug in your application logic, but that’s usually orders of magnitude better than introducing hard to fight inconsistencies.
- jerrysievert 8y ago

harel 8y ago

In my previous startup we used mongo as the main datastore (this was pre Postgres 9.4, before indexable JSONB). It worked for us, and it worked fine. I saw the mob rising up against it, but we have not had any of the problems (maybe we just read the manual and had it configured correctly?). Today my go-to is postgres of course, but I had to wait until JSONB was out to make the switch.