Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jepsen Disputes MongoDB's Data Consistency Claims

infoq.com

Post reply on HN
Print view View original

301–310 of 416 posts

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#301

Post by marcan_42 »

tasuki wrote: post #297
chx wrote: post #64

Earlier quoted context omitted.

There was a time when I advocated for MongoDB with the usual caveats. The ability to easily store and index complex data was of great value. And then in 2015 October, within a week of each other, SQLite and MySQL both learned how to index on expressions and store JSON (SQLite 3.9 2015-10-14, MySQL 5.7 2015-10-21). PostgreSQL added jsonb the year prior in 9.4. At that moment the value of MongoDB for me diminished grea…

Why is storing json in a database important to you? Whenever I see json fields in PostgreSQL/MySQL, I know I'm most likely in for inconsistent data and a world of pain.

Why is storing all data normalized in a database important to you? Whenever I see an exceedingly complicated database schema, I know I'm most likely in for unfixable legacy DB warts and incessant schema updates for every little feature.

Hyperbole aside, the best option often is somewhere in between. I find that a relational database with columns for primary keys/relations/anything used in WHERE statements in the normal application path, and a json blob for everything else that's just attributes for the current row/object/document, makes for a very flexible and successful DB schema. You get all the strong relational consistency benefits of traditional schemas, plus the flexibility to add and modify features that don't require relation changes without touching the schema, and the ability to represent complex structures while still allowing ad-hoc and admin path queries to peek into them where necessary.

In fact, most "fully normalized" databases end up reimplementing a key/value store or twelve in there anyway (e.g. config settings, user attributes, and the like). Might as well just use JSON at that point.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#302

Post by layoutIfNeeded »

twic wrote: post #138
ceocoder wrote: post #91

Earlier quoted context omitted.

This might be a stupid question, but surely no one thinks of RabbigMQ as a database right? I’ve used it from 2012 to 2018 extensively, including using things like shovels to build hub spoke topologies, however not once did I think of it as anything but a message broker. Did I miss something huge?

I once worked on a system for notifying customers of events by posting to their APIs. Events came in on a Rabbit queue and got posted. If a customer's API was down, the event would go back on the queue with a header saying to retry it after some time. You can do some sort of incantation to specifically retrieve messages with a suitable header value, to find messages which are ready to retry. We used exponential backo…

Sounds like delay line memory.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#303

Post by danielscrubs »

tincholio wrote: post #285
OOPMan wrote: post #246

Earlier quoted context omitted.

As a skateboarder I've always found the name itself rather amusing as the term mongo has relatively negative connotations in skating.

It also does in Spanish, it's a (rather old, but still used) shortened version of "retard" (from "mongólico", originally used to describe people with Down's syndrome).

Same in Swedish

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#304

Post by keymone »

ceocoder wrote: post #93
wzy wrote: post #90

Earlier quoted context omitted.

I can't believe the one item that was so obviously added as a joke went right over head. It may be good idea to take a break from the computer and find something less stressful to do.

Perhaps that’s because some other message brokers are now being touted as databases[0][1], I remember seeing a thread about it on HN couple of days ago. [0] https://www.confluent.io/blog/okay-store-data-apache-kafka/ [1] https://dzone.com/articles/is-apache-kafka-a-database-the-20...

Watch this talk: https://m.youtube.com/watch?v=fU9hR3kiOK0

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#305

Post by HelloNurse »

kyllo wrote: post #128
madhadron wrote: post #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 f…

I was floored by this comment yesterday from one of their Developer Relations people: > Did any of you actually read the article? We are passing the Jepsen test suite and it was back in 2017 already. So, no, MongoDB is not losing anything if you know what you are doing. https://twitter.com/MBeugnet/status/1253622755049734150?s=20 Can you imagine saying the phrase "if you know what you are doing," in public, to your u…

Indirectly stating that they aren't good enough to use MongoDB properly could be offensive for thin-skinned developers, but it's only bad attitude.

I'm much more concretely worried by a software design for which the authors (not hostile critics) consider "if you know what you are doing" an acceptable safety and quality standard for data integrity.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#306

Post by kinghajj »

Thaxll wrote: post #136
thomascgalvin wrote: post #53

You can tell a lot about a developer by their preferred database. * Mongo: I like things easy, even if easy is dangerous. I probably write Javascript exclusively * MySQL: I don't like to rock the boat, and MySQL is available everywhere * PostgreSQL: I'm not afraid of the command line * H2: My company can't afford a database admin, so I embedded the database in our application (I have actually done this) * SQLite: I'm…

How MongoDB is dangerous or less consistant that PG? I have one for you: I can't use PG or MySQL because my app will go down if the master is down so then the entire backend fails. How do you do HA with default PG?

https://www.postgresql.org/docs/10/different-replication-sol...

Logical replication or synchronous multimaster replication may meet your needs.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#307

Post by coffeemug »

ianamartin wrote: post #212
erulabs wrote: post #186

I wonder if I'm the only sysadmin in the world who doesn't hate MongoDB. Yes, I wouldn't use it for new projects, and yes, I wish RethinkDB had taken its place, but it's not as horrible as people seem to think. Default configuration... If it weren't for RDS' doing PG-bouncer-style connection management, 95% of production postgres instances would probably fail. It innodb_buffer_pool_size wasn't set properly, plenty of…

RethinkDB is a better solution to every problem that MongoDB claims to solve. I wouldn't use it for everything. But once my need for a document store outgrows what's convenient and easy in Postgres with JSONB, I reach for Rethink. It's great. There's a Jepsen analysis of it a while back too that is quite positive. It's a shame that Rethink did so many things right and failed as a company while Mongo continues to do a…

Imagine how I feel about it :)

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#308

Post by lmm »

Xylakant wrote: post #299
neeleshs wrote: post #276

Earlier quoted context omitted.

Sends emails when scanned vs returned record ratio is greater than a threshold. Not quite sure how something like this would be different for MySQL/postgres. If an index is missing for you query pattern, wouldn't you create an index in MySQL/postgres?

> If an index is missing for you query pattern, wouldn't you create an index in MySQL/postgres? No. I’d consider adding an index. An index is not free, it comes at a cost and that cost may well be higher than the costs of not having that index. For example, if a reporting query that runs once every few hours is lacking an index, the cost of updating that index on every write (and the disk space/memory used) may well…

Secondary indicies can be a lot cheaper in a non-ACID database, where you can acknowledge a write when it is durably committed but index updates may not have completed.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#309

Post by HelloNurse »

marcan_42 wrote: post #301
tasuki wrote: post #297

Earlier quoted context omitted.

Why is storing json in a database important to you? Whenever I see json fields in PostgreSQL/MySQL, I know I'm most likely in for inconsistent data and a world of pain.

Why is storing all data normalized in a database important to you? Whenever I see an exceedingly complicated database schema, I know I'm most likely in for unfixable legacy DB warts and incessant schema updates for every little feature. Hyperbole aside, the best option often is somewhere in between. I find that a relational database with columns for primary keys/relations/anything used in WHERE statements in the norm…

It really depends on applications. In most databases I've seen, if information is unimportant it is just omitted and if it's important it's worth putting in a proper column to allow relational operations; and if important information is big it's usually unstructured or ad-hoc (e.g. log messages, PDF documents), not a "document" and particularly not JSON.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#310

Post by HelloNurse »

danielscrubs wrote: post #303
tincholio wrote: post #285

Earlier quoted context omitted.

It also does in Spanish, it's a (rather old, but still used) shortened version of "retard" (from "mongólico", originally used to describe people with Down's syndrome).

Same in Swedish

Same in most languages, but there's also Emperor Mongo in Flash Gordon stories, definitely alluding to Mongol conquering hordes.
Post reply on HN