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

81–90 of 165 posts

Re: MongoDB 3.4.0-rc3

#81

Post by deathanatos »

nurettin wrote: post #79
laichzeit0 wrote: post #73

Earlier quoted context omitted.

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.

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 immediately), the write can be lost.

Re: MongoDB 3.4.0-rc3

#82

Post by nurettin »

hendzen wrote: post #70
josephg wrote: post #60

Earlier quoted context omitted.

Rethinkdb is still the new database on the block, and never really found it's feet. Look up Postgres, Cassandra, Kafka, Riak, MySQL/Mariadb or MSSQL. (Or dare I say it, oracle). All of those tools have a long history of reliability and solid engineering.

Ha! MySQL having a long history of reliability... Son have you heard of MyISAM?

Ah, early 2000s and the table level lock during inserts but lightning fast reads. Postgres was still a fledgling back then.

Re: MongoDB 3.4.0-rc3

#83

Post by bogomipz »

omginternets wrote: post #42
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.

Exactly, which makes ... >The team at MongoDB really cares a lot about making the best database product possible. ... some what ironic.

Right I would hope that that would be implicit :)

Re: MongoDB 3.4.0-rc3

#84

Post by edgan »

bogomipz wrote: post #39
tbrock wrote: post #12

MongoDB receives a fair amount of criticism here but the company is a fantastic place to work. I'm proud that I was able to learn and grow as a developer alongside all of those who have been trying (and succeeding) to make a great database. The team at MongoDB really cares a lot about making the best database product possible. I knew it when I was there and still think so after I've left.

>"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.

Re: MongoDB 3.4.0-rc3

#85

Post by lotyrin »

hendzen wrote: post #65
dijit wrote: post #62

Earlier quoted context omitted.

ah, the "x uses y so it must be good" fallacy I should note that I work for a multi-national gaming company and we use software that is ABSOLUTELY not fit for purpose, but once you have a hard dependency on something and the cost of muddling through is _less_ than the cost of a rewrite then you're going to be stuck supporting it. This is the reality of technology in enterprise.

That specific point was in reply to the GP's statement that "competent teams" weren't using it in production.

I don't think it should be taken as given that there's a correlation between competency and the size of an organization that a team exists within, and I don't think such a correlation, when combined with large organizations' usage of MongoDB would challenge the assertion that there exists an anticorrelation between team competency and use of MongoDB.

Looking at the numbers, larger organizations straight-forwardly seem like they should be more likely to eventually hire mediocre talent, survive despite having done so, and more likely to have adopted any given tool.

Re: MongoDB 3.4.0-rc3

#86

Post by hendzen »

lotyrin wrote: post #85
hendzen wrote: post #65

Earlier quoted context omitted.

That specific point was in reply to the GP's statement that "competent teams" weren't using it in production.

I don't think it should be taken as given that there's a correlation between competency and the size of an organization that a team exists within, and I don't think such a correlation, when combined with large organizations' usage of MongoDB would challenge the assertion that there exists an anticorrelation between team competency and use of MongoDB. Looking at the numbers, larger organizations straight-forwardly see…

You speak of "correlation" and "looking at the numbers" but provide no data. What exactly is your point?

Re: MongoDB 3.4.0-rc3

#87

Post by takeda »

hendzen wrote: post #70
josephg wrote: post #60

Earlier quoted context omitted.

Rethinkdb is still the new database on the block, and never really found it's feet. Look up Postgres, Cassandra, Kafka, Riak, MySQL/Mariadb or MSSQL. (Or dare I say it, oracle). All of those tools have a long history of reliability and solid engineering.

Ha! MySQL having a long history of reliability... Son have you heard of MyISAM?

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 replacement engines that are more reliable (ISAM/MyISAM vs InnoDB and v0 vs v1).

Both still have quirks due to bad decisions in the past, but which can't be easilly fixed due to breaking compatibility.

Re: MongoDB 3.4.0-rc3

#88

Post by hendzen »

takeda wrote: post #87
hendzen wrote: post #70

Earlier quoted context omitted.

Ha! MySQL having a long history of reliability... Son have you heard of MyISAM?

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 acquirer, which puts them in control of their own destiny.

If MongoDB is heading along the path of MySQL, that's a pretty good path to be on considering that MySQL is used as the store of record at Facebook, Twitter and some parts of Google.

Re: MongoDB 3.4.0-rc3

#89

Post by chx »

radicalbyte wrote: post #32
jasondc wrote: post #15

Bigger news is that Jepsen tests are now part of the MongoDB continuous integration suite: https://evergreen.mongodb.com/build/mongodb_mongo_master_ubu... Open and available for everyone to see, for every build of MongoDB. Is there another database that has this much transparency? (for every build)

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.

Re: MongoDB 3.4.0-rc3

#90

Post by lotyrin »

hendzen wrote: post #86
lotyrin wrote: post #85

Earlier quoted context omitted.

I don't think it should be taken as given that there's a correlation between competency and the size of an organization that a team exists within, and I don't think such a correlation, when combined with large organizations' usage of MongoDB would challenge the assertion that there exists an anticorrelation between team competency and use of MongoDB. Looking at the numbers, larger organizations straight-forwardly see…

You speak of "correlation" and "looking at the numbers" but provide no data. What exactly is your point?

The point? How do you draw a line from "Fortune 500s use Mongo" to "Mongo is used by competent teams"?

I specifically challenge that you can do so, given a model of a large organization as being necessarily more diverse (regressing to the mean of general competency, more likely to have facts like "org Y uses tech X" being true) and more robust to survive failures as it grows.

We don't have data, but we can still model (if nothing else, to think about what data we would need).

Post reply on HN