Live data from Hacker News

MongoDB 3.4.0-rc3

jepsen.io

71–80 of 165 posts

Re: MongoDB 3.4.0-rc3

#71

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.

In the same NoSql space as mongo db? I can't remember not even one that passed fully jepsen test. Can you post some links to the better NoSql options?

Rethink and Cassandra both fare far better in Jepsen.

Depending on the exact requirements Postgres (in the right configuration) and Redis are better options.

I'd argue that for 90% of MongoDB users - the group whose requirements were met by MySQL/MyISAM - would be better served by Postgres or MySQL with a proper storage engine.

Re: MongoDB 3.4.0-rc3

#72

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.

I think you're going to end up on the wrong side of this one, if you're not willing to change your opinion based on new info. It's a big deal, his second to last sentence in the intro: > While the v0 protocol remains broken, patches for v1 are available in MongoDB 3.2.12 and 3.4.0, and now pass the expanded Jepsen test suite.

I'll change my opinion once they've actually fixed it. The same way my opinion of MySQL changed when it finally matured (around 5.0 when they added proper transactions).

Re: MongoDB 3.4.0-rc3

#73
post #56

Earlier quoted context omitted.

I think if you look back objectively, there are very few database platforms that were absolutely "fit for public consumption" right out of the box. Look at all the SQL Server shops out there (mine included) that won't even roll out a new version of SQL Server until it hits SP 1 at a minimum... For MongoDB, If you look forward based on what they are doing now rather than at how early adopters may have had a sub-optima…

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.

Re: MongoDB 3.4.0-rc3

#74

Earlier quoted context omitted.

I think if you look back objectively, there are very few database platforms that were absolutely "fit for public consumption" right out of the box. Look at all the SQL Server shops out there (mine included) that won't even roll out a new version of SQL Server until it hits SP 1 at a minimum... For MongoDB, If you look forward based on what they are doing now rather than at how early adopters may have had a sub-optima…

> Can you give an example of another option you are referring to? That depends on the data. What type of data you have and what you want to do with it. MongoDB isn't data specific and it claim to fame is flexible data structure. If you want fast write and look up with very little relation Cassandra is good. If you want searchable text document then anything that is base on Lucene is good (ES, Solr, Raven). If you wan…

> if you want graph data then there are NodeJS

I think you meant Neo4j.

Re: MongoDB 3.4.0-rc3

#75
post #61

Earlier quoted context omitted.

MongoDB wins on performance, big time. https://www.amon.cx/blog/rethinkdb-reviewed-by-a-mongo-fan/

A database that doesn't need to guarantee data integrity will always be faster. How is the performance with the new v1 protocol? (still faster, I'm sure)

Sorry if this is a stupid question. But how important is guaranteed integrity, in practice? (BTW, is what you're referring to considered transactions?) Obviously, for things like banking you need guarantees, but I'm not sure how often reads/writes to mongodb just disappear out of thin air.

Re: MongoDB 3.4.0-rc3

#76

Earlier quoted context omitted.

In the same NoSql space as mongo db? I can't remember not even one that passed fully jepsen test. Can you post some links to the better NoSql options?

Rethink and Cassandra both fare far better in Jepsen. Depending on the exact requirements Postgres (in the right configuration) and Redis are better options. I'd argue that for 90% of MongoDB users - the group whose requirements were met by MySQL/MyISAM - would be better served by Postgres or MySQL with a proper storage engine.

Cassandra testing on Jepsen. Interesting definition of "fare far better in Jepsen" https://aphyr.com/posts/294-jepsen-cassandra

Re: MongoDB 3.4.0-rc3

#77
post #53

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.

thats an old stat - its over 50% of the Fortune 100 now

Re: MongoDB 3.4.0-rc3

#78
post #46

Earlier quoted context omitted.

I think if you look back objectively, there are very few database platforms that were absolutely "fit for public consumption" right out of the box. Look at all the SQL Server shops out there (mine included) that won't even roll out a new version of SQL Server until it hits SP 1 at a minimum... For MongoDB, If you look forward based on what they are doing now rather than at how early adopters may have had a sub-optima…

Not the OP, but RethinkDB is superior in many ways including stability, integrity and the feature set for pretty much every use case you would consider using MongoDB. But with Jespen tests MongoDB can finally be considered a contender. Its not like competent teams were using it in production. Right?

> Its not like competent teams were using it in production. Right?

I've heard that about 1000 times a day for 6 years. Usually the person stating it is snickering as if they are clued into some unknown secret.

Mongo does work in production at many shops, and in many forms. Sometimes it's used as the main database, sometimes it's used to house specific slices of data, etc.

Re: MongoDB 3.4.0-rc3

#79
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.

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

Re: MongoDB 3.4.0-rc3

#80

Earlier quoted context omitted.

I think you're going to end up on the wrong side of this one, if you're not willing to change your opinion based on new info. It's a big deal, his second to last sentence in the intro: > While the v0 protocol remains broken, patches for v1 are available in MongoDB 3.2.12 and 3.4.0, and now pass the expanded Jepsen test suite.

I'll change my opinion once they've actually fixed it. The same way my opinion of MySQL changed when it finally matured (around 5.0 when they added proper transactions).

Er, to be clear, they have actually fixed those issues in the v1 protocol. There may be other bugs, but I haven't been able to find them yet.
Post reply on HN