Live data from Hacker News

Jepsen Disputes MongoDB's Data Consistency Claims

infoq.com

21–30 of 416 posts

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#21
post #20

Earlier quoted context omitted.

Why not use PostgreSQL instead? It supports a JSON document data type natively. It also has exceptional stewardship as an open source project. Mongo should never be a first choice, but a last choice for edge cases.

Postgres has terrible indexing with json. It doesn’t keep statistics so simple queries sometimes take much longer than expected due to query planner not knowing much about the data.

[deleted]

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#22
post #20

Earlier quoted context omitted.

Why not use PostgreSQL instead? It supports a JSON document data type natively. It also has exceptional stewardship as an open source project. Mongo should never be a first choice, but a last choice for edge cases.

Postgres has terrible indexing with json. It doesn’t keep statistics so simple queries sometimes take much longer than expected due to query planner not knowing much about the data.

DB noob question: if you know that you should be indexing on a json attribute, can’t you put it into a «proper column» and index there?

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#23
post #20

Earlier quoted context omitted.

Why not use PostgreSQL instead? It supports a JSON document data type natively. It also has exceptional stewardship as an open source project. Mongo should never be a first choice, but a last choice for edge cases.

Postgres has terrible indexing with json. It doesn’t keep statistics so simple queries sometimes take much longer than expected due to query planner not knowing much about the data.

[deleted]

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#24
post #20

Earlier quoted context omitted.

Why not use PostgreSQL instead? It supports a JSON document data type natively. It also has exceptional stewardship as an open source project. Mongo should never be a first choice, but a last choice for edge cases.

Postgres has terrible indexing with json. It doesn’t keep statistics so simple queries sometimes take much longer than expected due to query planner not knowing much about the data.

[deleted]

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#25
post #20

Earlier quoted context omitted.

Why not use PostgreSQL instead? It supports a JSON document data type natively. It also has exceptional stewardship as an open source project. Mongo should never be a first choice, but a last choice for edge cases.

Postgres has terrible indexing with json. It doesn’t keep statistics so simple queries sometimes take much longer than expected due to query planner not knowing much about the data.

I’ve seen that as well, the default estimate for jsonb can seriously confuse the query planner. There is a patch in PG13 that addresses this as far as I understand, but I’m not familiar enough with PG internals to be sure I’m reading that right. I’ll be playing with this when PG13 is out, the jsonb feature is really useful, though I wouldn’t recommend to shove relational data into it. Many things are much, much harder to query inside jsonb than regular columns.

There are ways around the statistics issue in some cases, e.g. defining a functional index on a jsonb property will collect proper statistics.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#26
post #20

Earlier quoted context omitted.

Why not use PostgreSQL instead? It supports a JSON document data type natively. It also has exceptional stewardship as an open source project. Mongo should never be a first choice, but a last choice for edge cases.

Postgres has terrible indexing with json. It doesn’t keep statistics so simple queries sometimes take much longer than expected due to query planner not knowing much about the data.

“It doesn’t keep statistics” is a weird way to say “I expect full table scans to always be fast”.

Create a functional index.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#27
In the circles I run in, MongoDB is regarded as a joke and the company behind it as basically duplicitous. For example, they still list Facebook as their first user of MongoDB on their website, for example, but there is no MongoDB use in Facebook hasn't been for years (it came in only via a startup acquisition).

I had the misfortune to use MongoDB at a previous job. The replication protocol wasn't atomic. You would find partial records that were never fixed in replicas. They claimed they fixed that in several releases, but never did. The right answer turned out to be to abandon MongoDB.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#28

"We found that due to these weak defaults, MongoDB’s causal sessions did not preserve causal consistency by default: users needed to specify both write and read concern majority (or higher) to actually get causal consistency. MongoDB closed the issue, saying it was working as designed, and updated their isolation documentation to note that even though MongoDB offers “causal consistency in client sessions”, that guara…

Kyle's point is that it's arguably valid but certainly unhelpful: the default settings are liable to lead to data loss. Moreover, he draws attention specifically to transactions as something which you would expect to make things safer, but in fact there's a rather arcane part of the documentation that notes that you need to manually specify both read and write concerns on every transaction individually if you want transactions to behave consistently, regardless of the concerns specified at the database level.

Basically, there are a large number of pitfalls that it's very easy to fall into unless you have an encyclopaedic knowledge of the documentation, and you need to ignore some of the words that are used (like "transaction" or "ACID") because they carry connotations that either do not apply or only apply if you do extra work to make it so.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#29
MongoDB started life as a database designed for speed and ease of use over durability. That's not a good look for a database.

People have told me that they have since changed, but the evidence is overwhelmingly and repeatedly against them.

They seem to have been successful on marketing alone. Or people care more about speed and ease of use than durability, and my assumptions about what people want in a database are just wrong.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#30

[repost - asking for help] I am disappointed with the direction that MongoDB took this past few years. Going ACID shows in benchmarks [1] and it’s not advisable if you are using MongoDB for stats and queue. (No one uses MongoDB for financial transactions despite the changes.) And the recent change to a restrictive license is worrisome as well. I have been thinking of forking 3.4 and make it back to “true” open source…

> And the recent change to a restrictive license is worrisome as well. I have been thinking of forking 3.4 and make it back to “true” open source and awesome performance.

Please do; someone needs to take that first step, and then many more could potentially contribute.

Post reply on HN