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

411–416 of 416 posts

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#411

Post by kyberias »

erulabs wrote: post #394
kyberias wrote: post #283

Earlier quoted context omitted.

> just that they shouldn't be scoffing/laughing at tools Why on earth would that be a problem? Why are you sensitive about tools? Do the tools have feelings?

Tools are just tools. Imagine scoffing at someone using a hammer, when in your less experienced opinion, they should be using NewHammer3.1. Tools are means to an end. I much prefer working with people who care about the product and the business than what tools they used to build said product/business. I'm looking for "hey, you could save a lot of time by using tool Y", rather than "You people are idiots for even cons…

No. I can certainly imagine anyone scoffing at someone using a hammer when they are trying to dig a hole in the ground screaming "Tools are just tools!"

So yes, writing a website with assembler raises eyebrows and it is quite OK to ridicule bad languages such as PHP.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#412

Post by vosper »

squeaky-clean wrote: post #326
vosper wrote: post #318

Earlier quoted context omitted.

My claim isn’t that indexes are a bad idea. The comment I replied to suggested that Mongo’s marketing targets people who don’t want to learn how to use indexes; my claim is that the reality of the hosted product is that it frequently suggests that you add indexes (presumably doing so helps with Mongo Corps hosting margins, as well as with performance [which is laughable even with indexes])

> my claim is that the reality of the hosted product is that it frequently suggests that you add indexes But it auto-suggests what index to use and has a button for you to immediately apply it. I'd say it definitely intends for you to avoid learning how indexes in MongoDB work. The index suggestions it makes are often terrible. > performance [which is laughable even with indexes] It really depends on your use-case an…

> But it auto-suggests what index to use and has a button for you to immediately apply it. I'd say it definitely intends for you to avoid learning how indexes in MongoDB work. The index suggestions it makes are often terrible.

Heh, yeah, you're right. So I guess it's the worst of both worlds: they try to not have you learn about indexes, but they give you terrible index suggestions, so when those don't work out you still end up having to learn about indexes :)

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#413

Post by phyzome »

kuschku wrote: post #296
risyachka wrote: post #260

Earlier quoted context omitted.

Can you elaborate? I've seen benchmarks and from their website what I understood is that it can handle really massive reads and writes, tens (maybe hundreds) thousands of ops per second, but personally never tested to this extent.

We're using it in Quassel, and as soon as you go over ~3-4 parallel write/read threads, it starts locking up completely, sometimes taking 30 seconds for simple queries that should really take milliseconds. The big issue is that sqlite does full db locking for any operation, so during any write you can't just easily read at all. This can be fixed with WAL mode, but WAL mode is broken in uts early versions, and new ver…

As long as you're only doing reads, though, you can forego the locking and it's pretty nice!

Definitely would not use in a read/write situation for a web API for various reasons, though. :-)

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#414

Post by erulabs »

kyberias wrote: post #411
erulabs wrote: post #394

Earlier quoted context omitted.

Tools are just tools. Imagine scoffing at someone using a hammer, when in your less experienced opinion, they should be using NewHammer3.1. Tools are means to an end. I much prefer working with people who care about the product and the business than what tools they used to build said product/business. I'm looking for "hey, you could save a lot of time by using tool Y", rather than "You people are idiots for even cons…

No. I can certainly imagine anyone scoffing at someone using a hammer when they are trying to dig a hole in the ground screaming "Tools are just tools!" So yes, writing a website with assembler raises eyebrows and it is quite OK to ridicule bad languages such as PHP.

You must know that's a fairly ridiculous reading of what I wrote...

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#415

Post by hinkley »

gav wrote: post #101
1123581321 wrote: post #70

Earlier quoted context omitted.

As someone who chose MySQL and provides direction to developers who really like Postgres, and who also uses Postgres for fun, I do find myself having to both defend MySQL as a prudent option and convince them that I know anything at all about Postgres or computer science. :)

I tend to find people who argue with me against MySQL bring up things that haven't been true in a long time such as Unicode or NULL handling. I'd probably choose Postgres over MySQL for a new project just to have the improved JSON support, but there's upsides to MySQL too: - Per-thread vs per-process connection handling - Ease of getting replication running - Ability to use alternate engines such as MyRocks

Does that mean they fixed “utf-8” or that everyone is just supposed to know that it’s fucking bullshit and always has been?

You can’t cut corners like that without inviting questionS about the character of the primary committers. The pecking order in software is about trust.

People don’t let that stuff go easily, which is why you still see people harping on MongoDB. Once someone is labeled a liar And a cheat, everything they say that doesn’t add up is “guilty until proven innocent.”

The utf-8 situation is on top of a bed of half truths. Things like publishing benchmarks with backends that don’t support isolation. A cornerstone of a good DB is handling concurrent access efficiently and correctly. Drawing attention to other benchmarks is a lie by omission. Better than just being incorrect for a decade, certainly, but still sketchy.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#416

Post by jwr »

neximo64 wrote: post #336
jwr wrote: post #327

If you're looking for MongoDB done right, it does exist and it's called RethinkDB. For some reason it didn't catch on and become popular — but it's nicer, and most importantly, it doesn't lose your data. Data point: I have been running my production system (a fairly complex SaaS) on RethinkDB for the last 4 years.

RethinkDB is no longer supported, its major caveat.

Yes. Although the degree of "support" always depends on how much you pay for it :-) I doubt MongoDB is "supported" in the way most people understand that word.

From my point of view, RethinkDB is not regularly developed and improved. There is progress, but it's slow. Which is a pity, because it's a really good database, and one that tries really hard to be correct above all else.

The only other correct distributed database with strict serializable guarantees that I know of is FoundationDB, which nowhere near as easy to use as RethinkDB is (but it's somewhat easier with their document layer, which pretends to be MongoDB, just done right).

Post reply on HN