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

151–160 of 416 posts

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#151

Post by tehlike »

PacifyFish wrote: post #135
tehlike wrote: post #88

Earlier quoted context omitted.

I got my pm friend prototype his idea on mean stack, but when we got more serious, immediately transitioned to postgres and started using sequelize as the orm. Pretty good decision so far. I don't think they will have cases that won't scale with orm for foreseeable future.

How do you manage dev vs prod instances with sequelize? Specifically, do you use migrations for your local dB or just force sync it?

they use sequelize migrations for now, eventually we may want to go to something more advanced. take a backup, apply migrations has worked so far. force sync extremely harmful, sequelize is terrible for not being able to incrementally do schema changes. I don't think it can actually add a column, for example.

For us, as a result, it means anytime we add a new model or change a table, we write the table definition in more verbose api, and sometimes resort to sql commands for adding things like defaults in the migrations. (sequelize for some reason can not specify uuid default value for postgres, for example, so we set a default ourselves, even though we don't need one as we have time dependent uuid generator on the client to help with indices).

We kind of learned working around sequelize shortcomings :)

I am still looking for a tool that'd make incremental backups on postgres easier than it is, but for now things are ok.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#152

Post by kiwicopple »

jedberg wrote: post #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 j…

We[1] have done 50+ conversations with developers this year (mostly indie and small startups). You’re right about the ease of use. The top reasons are

  - they don’t know why, it was just the one they learned/heard about first
  - there is a lot of tooling for it
A lot of them even knew about the limitations of MongoDB but they still choose it.

We concluded that other databases need to start prioritising usability; something few developer tools usually care about.

[1] https//supabase.io

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#153

Post by dang »

kevinburke wrote: post #116
dang wrote: post #54

Earlier quoted context omitted.

Surprisingly, it seems not to have made the front page: http://hnrankings.info/23191439/ . There's clearly community appetite to discuss this, so we won't treat the current submission as a dupe.

“ Did HN's antispam measures get a lot more aggressive recently? The last handful of Jepsen reports have really struggled to make it to frontpage, despite significantly higher vote-to-age ratios than comparable posts. Once they're on FP, they reliably hit top 10, but Dgraph's (1/2) ” https://twitter.com/jepsen_io/status/1261640852666855426

Funnily enough I emailed aphyr earlier this afternoon to let him know that the current submission was at #1 on HN and that https://news.ycombinator.com/item?id=23285249 had strangely failed to make the front page despite all the upvotes it got. There wasn't any moderation in either case. Nothing has changed recently. There's just a lot more randomness than people assume...2000 submissions a day competing for the same 30 slots creates a lot of weird high-pressure effects.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#154

Post by jedberg »

cpuguy83 wrote: post #67
jedberg wrote: post #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 j…

I used it effectively to denormalize and combine some data from other services... sort of like a 2nd level, queryable cache. Worked very well for my needs. This was 7-8 yrs ago.

Yes, this is true, it's good as a cache since it values speed over durability. But since it's not built for that, you could potentially do better with an in-memory database like Redis.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#155

Post by jedberg »

collyw wrote: post #80
jedberg wrote: post #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 j…

Maybe it's just because I know SQL reasonably well but I don't even find Mongo particularly easy to use. Not for complex queries anyway.

I think the ease of use was more in the administration. It was (is?) super easy to set up and run (for small installations).

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#156

Post by scarface74 »

tpxl wrote: post #72
scarface74 wrote: post #40

Earlier quoted context omitted.

So now we shouldn’t ever trust a project because they don’t have good technical writers? I don’t have a dog in the Mongo fight. I haven’t done an implementation on top of it in years and probably the next time I do something with “Mongo” it will probably be AWS’s Document DB with Mongo support. That’s based on AWS’s own code and storage tier and doesn’t have the same characteristics as Mongo proper.

For what it's worth, Document DB doesn't support a lot of the Mongo API, such as $$ROOT in aggregations, and it can't use indices on (paraphrased) "SELECT * FROM x WHERE id IN [list]" if the list length is > 10. If you ask me, if there's something worse than Mongo it's Document DB.

Given a choice between the limitations of DynamoDB and DocumentDB, DocumentDB is still far more versatile and written on top of the same storage engine and is just as reliable.

And yes I know most of the data modeling tricks around using GSI’s and LSI’s.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#157

Post by jugg1es »

dustingetz wrote: post #145
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…

Datomic: I'm done already, send more work please

I've been working with a partner company that is using Datomic to back a relatively impressive product - but I don't really see much written about it. What has been your experience?

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#158

Post by philliphaydon »

cyral wrote: post #107
VWWHFSfQ wrote: post #99

Earlier quoted context omitted.

mysql's admin tools are still far superior than what's available for postgres

What tools are these? Curious as a Postgres user

As a PostgreSQL user. Pgadmin 4 is the worst.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#159

Post by capsulecorp »

m0zg wrote: post #126
ceocoder wrote: post #96

Earlier quoted context omitted.

Ah I see, we are going with “well technically it stores something therefore it is database joke”. Now I’m fully onboard :) Back when I worked in LA my CTO used to joke that most places use Microsoft Outlook as a database and Excel as BI tool.

You laugh, but I bet Excel produces orders of magnitude more real "business intelligence" than all other "BI" tools combined.

You bet, but I'd really love to see data that supports that.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#160

Post by winrid »

I worked at one company where the network traffic just on the MongoDB master was around 2gb/s. We had machines with terrabytes of memory, and Mongo worked fine - until we had some replica set nightmares. Mongo support is amazing, but when replication breaks it's very hard to diagnose (usually it was our fault, but it felt very fragile).
Post reply on HN