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

MongoDB 3.4.0-rc3

jepsen.io

Post reply on HN
Print view View original

91–100 of 165 posts

Re: MongoDB 3.4.0-rc3

#91

Post by always_good »

laichzeit0 wrote: post #73
josephg wrote: post #56

Earlier quoted context omitted.

Right out of the box? Mongodb has been trying to get it right for 10 years now. Kyle says the storage engine they've used for most of that lifetime is fundamentally flawed, and they've only now, a decade on, managed to write something without known bugs to replace it. And maybe this time it's ok. Maybe this time there aren't any more layers of buggy crap in mongo yet to be found and fixed. Maybe. But you'd have lost…

Do you think MongoDB is a good choice (given how easy it is to use) when you only care that 99.999% of your data that you insert should end up in the database? That's my use case. Best-effort integrity. I mostly just want a DB can insert and query fast for documents and am not really concerned if I lose a few documents here and there.

Why wouldn't you just use anything else that can manage to insert/read data without losing it?

I don't really understand the angle of "can I get away with it anyways, tho?"

Re: MongoDB 3.4.0-rc3

#92

Post by beachy »

jlaustill wrote: post #11

This is great news. Historically I've accepted the risk of data loss and coded checks when needed. I will never rely on my database, regardless of which one I am using for complete data consistency. It is, however, nice to see strides being made towards even better robustness. Go MongoDB!

I'm sure they exist but I can't imagine any project where I would want to factor in data loss from my database.

At the very least I'd want to know exactly how much data loss we are talking about, which is probably harder to answer than just using a platform that doesn't suffer data loss in the first place.

Re: MongoDB 3.4.0-rc3

#93

Post by SEJeff »

hendzen wrote: post #88
takeda wrote: post #87

Earlier quoted context omitted.

In many ways MySQL is similar to MongoDB. Both started out being written by people who know nothing about databases and both threw away years of database research. Both gained popularity due to being accepted choice by web-based languages (PHP vs NodeJS) Both were faster than more established competition, only to turn out that both were losing data. Both turned out to be designed fundamentally wrong and had a replace…

You're comparing ISAM/MySAM (storage engine) to the MongoDB replication protocol. As a more relevant parallel MongoDB also replaced its original storage engine with one acquired from WiredTiger (BerkeleyDB founders). One big difference from a corporate strategy perspective is that MySQL let the replacement storage engine (InnoDB) fall in to the hands of Oracle. MongoDB was smart enough to make sure that they were the…

And virtually 100% of youtube, if we're talking web scale.

Re: MongoDB 3.4.0-rc3

#94

Post by mhoeller »

Good news to hear! We just finished a fairly big IoT project where we needed to ship a replicated database which was fast, easy to deploy and reliable. We tried other DBs but none was so stable to be shipped with a standalone application completely black boxed to the customer. I was septic in the beginning but after 800 installations in 2 month we have no complains. Also not from early adopters which run now for appr. a year.

Re: MongoDB 3.4.0-rc3

#95

Post by radicalbyte »

chx wrote: post #89
radicalbyte wrote: post #32

Earlier quoted context omitted.

Given their start point (a product unfit for public consumption) that is the absolute minimum they need to do. I at least will never trust Mongo for anything but a toy project. There are so many better options out there, options whose technical capabilities are as good as Mongo's marketing.

We built examiner.com on MongoDB in 2010. Yes, that was before the journal was introduced. Would you call a then Quantcast Top 100 site a "toy project"? It served well into 2016.

I said that I would only use it for a toy project. Or at least a project for whose requirements resulted in MongoDB being a good choice. For example a content site where losing some data doesn't matter and whose hot datasets would never expand above the memory available by my budget.

Given the projects I chose to work on, MongoDB would be a bad choice. So I would only use it for a toy project right now. In 3-5 years time I expect that it will be a very good choice, given that they've pretty much won and can hire all of the good engineering talent.

The parallels with MySQL are really astounding; I just hope that they don't end up being sold to Oracle or Microsoft.

Re: MongoDB 3.4.0-rc3

#96

Post by Fiahil »

edgan wrote: post #84
bogomipz wrote: post #39

Earlier quoted context omitted.

>"MongoDB receives a fair amount of criticism here but the company is a fantastic place to work" None of the criticisms I have ever seen or heard about MongoDB were related to Mongo Inc and their office culture but rather their product.

Actually, having been through their training, and dealt with their consultants. Their company culture is the problem. They had a pure-developer centric mindset, and no operations mindset. So at the time they had no good way to do backups. Their more modern solution is backups that they manage for you, which is even more crazy.

Yes. Mongo is an operational nightmare. I mean, who in their right mind would use a product where the recommended solution[0] to resync a stale replica (which happen all the time after a long netsplit) is to "perform an initial sync". Which, of course, mean "please remove everything and type this command". Crazy.

[0]: https://docs.mongodb.com/manual/tutorial/resync-replica-set-...

Re: MongoDB 3.4.0-rc3

#97

Post by h1d »

redtree wrote: post #53
rocky1138 wrote: post #40

Why would anyone use MongoDB when RethinkDB is available?

"Over a third of the Fortune 100 and many of the most successful and innovative web companies rely on MongoDB. " taken from their page : https://www.mongodb.com/mongodb-scale This should give people some insight on why MongoDB is being used in the industry.

You could replace the word MongoDB to "some crap C code from 20 years ago" but it wouldn't make you want to have it.

Re: MongoDB 3.4.0-rc3

#98

Post by radicalbyte »

deathanatos wrote: post #81
nurettin wrote: post #79

Earlier quoted context omitted.

In my experience, mongo lets you check the end result and try inserting again.

How do you expect to check the end result? The article's Jepsen analysis shows that both the v0 and v1 replication protocols (excepting the very latest version of v1 that appears to be in response to this) can result in acknowledged writes being lost. I.e., the DB tells you, for a write sent with a majority, that the write was successful — to a majority! Subsequently (and, if I understand the article, possibly not im…

It depends.

Given a small cluster of reliable nodes on a reliable network, these errors will occur extremely rarely. So rarely, in fact, that they'll be written off as "user error" by support.

If you're a startup building a system which has to quickly and reliably scale from 3 > 3000 nodes in a year then the whole thing is likely to explode in your face. Twitter style.

Now, if MongoDB was so superior that it was truly platform which would even enable that kind of scaling, then the decision is simple: just go for it.

The thing is, this isn't how the world works. When systems are built, very few people consider (or are capable of considering) the growth of the system. Frameworks and database are, by the rule, chosen arbitrarily. When scaling happens, the question is more "how can we scale what we have whilst having everything kind of work" than "how do we design a system which works correctly at scale".

Mongo's whole strategy is based around this. Make Mongo the default choice for the current generation of developers.

Fantastic market strategy.

Re: MongoDB 3.4.0-rc3

#99

Post by ClayFerguson »

These 'from the ground up' totally all-new-code approaches to DBs are just a scary proposition. Think of the thousands of man-years of effort that went into building MySQL, testing its codebase, and perfecting it's robustness (fail-proof-ness). What does MongoDB bring that couldn't have 'built on top' of MySQL codebase, and used MySQL transational layer as it's underpinnings. Sure, MongoDB gets all its performance gains from delaying writes to the DB (eventually consistent), caching in memory, and dispensing with ACID, however there is nothing about MongoDB that couldn't have been written to use the DB layer of MySQL at the point where it actually does its writes to disk. In this way, MongoDB would have revolutionized the world rather than mostly "fragmenting" the storage space.

I guess there are those who will say that even using batch-commits, that MongoDB could never have achieved the performance it currently does (by bypassing any ACID) if it was built on top of MySQL. But regardless, why not focus efforts on improving MySQL batch processing performance rather than throwing it all out, starting from scratch, and writing directly to disk. I know MongoDB became a success, but I think that is 'in spite of' their decision to start from scratch and not 'because of' it. Also think of the power that would be available if there were some relational table capability (true real MySQL ACID) right inside MongoDB whenever it was needed, if they were the 'same animal', rather than having to use two totally and completely separate DBs if you need NoSQL and also ACID in an app, which 99% of apps DO NEED, at some point, once an app grows beyond the round-one funding startup-toy phase and MongoDB falls flat in it's RDB capabilities.

Re: MongoDB 3.4.0-rc3

#100

Post by continuational »

mushi wrote: post #26
koolba wrote: post #19

Earlier quoted context omitted.

> I will never rely on my database, regardless of which one I am using for complete data consistency. I can't imagine developing any software that involves relationships between entities that does not have data consistency. Check constraints, foreign keys, and data type validation all provide a minimum sanity level of the underlying data that allows your mind to focus on more important things. Otherwise you're entire…

I think maybe the doubt is based on case like https://aphyr.com/posts/282-jepsen-postgres which all systems are subject to.

That's not a case of inconsistency. There are just three outcomes for a transaction: Committed, Aborted and Unknown.

The client will never experience Committed unless it really is committed, and thus never report that it was successful to the user.

Post reply on HN