5 ms·

Most software developers have a negative impression of MongoDB, based on the many flaws that it had back in 2010. Among the people who did the best job of docum

Most software developers have a negative impression of MongoDB, based on the many flaws that it had back in 2010. Among the people who did the best job of documenting those flaws, was Kyle Kingsbury, in his Jespen series: https://aphyr.com/posts/284-jepsen-mongodb https://aphyr.com/posts/284-jepsen-mongodb But it is important to realize that the team at MongoDB has actually been working with Kingsbury, for several years now, and they have slowly and patiently fixed the problems he identified. Consider how the situation had evolved by 2017: MongoDB 3.4 Passes Jepsen – The Industry’s Toughest Database Test Jepsen Evaluation Demonstrates MongoDB Data Safety, Correctness & Consistency On February 7th 2017, Kyle Kingsbury, creator of Jepsen, published the results of his tests against MongoDB 3.41. His conclusions: "MongoDB has devoted significant resources to improved safety in the past two years, and much of that ground-work is paying off in 3.2 and 3.4. MongoDB 3.4.1 (and the current development release, 3.5.1) currently pass all MongoDB Jepsen tests….These results hold during general network partitions, and the isolated & clock-skewed primary scenario." https://www.mongodb.com/mongodb-3.4-passes-jepsen-test https://www.mongodb.com/mongodb-3.4-passes-jepsen-test MongoDB has become an excellent document-store database. If you are still repeating FUD from 2010, then you are simply out of date. It's time to come up to speed on the reality of 2018.

gshulegaard 9y ago
Well...to the best of my knowledge the Mongo DB BI connector in 2018 is still Postgres: https://www.linkedin.com/pulse/mongodb-32-now-powered-postgresql-john-de-goes/ https://www.linkedin.com/pulse/mongodb-32-now-powered-postgr... Has this changed?
- metheus 9y ago
  John radically overstates his case in that article based on incomplete information; note that none of the code he points to is even 1.0 code. Nonetheless, it’s accurate enough to say that the 1.0 BI connector used Postgres code. It was definitely the fastest way to deliver it. 2.x was built from scratch, it uses no Postgres whatsoever.
- kstirman 9y ago
  Yes this has changed. The BI Connector 2.0 is written in Go and uses the MySQL wire protocol: https://docs.mongodb.com/bi-connector/master/release-notes/ https://docs.mongodb.com/bi-connector/master/release-notes/
nevi-me 9y ago
I'm one of those people who come in and comment about MongoDB, positively. My first "stack" was LAMP, in 2012 when I learnt how to use it, it was: - a JSON store that works well with NodeJS - a geospatial database (yea, it has what I need) that was "easier" to work with - a database that made it easier for me to change my schema (if you just throw data at it, garbage in, garbage out). Over the years, I've followed development, and adopted new features to make my life easier. - I was one of the people who were excited about full GeoJSON support in the 2.* days, because that's something I depended on. - I've tailed the oplog for as long as I remember (never needed Redis), and have been learning about change streams (announced in 3.6) with the hope of submitting a PR to Apache Beam to support them. - I adopted a lot of the aggregation framework (Asya Kamsky from MongoDB personally helped me a lot) - The last time I migrated data from MongoDB was when I turned on WiredTiger in 3.0.* My little replica has been up for as long as I remember, the only time I have downtime is when restarting my server. When I start a new project these days, I still go to Mongo, because what held true in its early days still holds. It's quick to get something started. Yeah, there's $lookups, transactions in future; I've just leveraged features as they become available. I have Postgres in my stack, which runs TimescaleDB and is a backing store for my Gitlab instance. Would I use MongoDB professionally? It depends on the use-case. Over the past 2 years I've worked with Oracle, SAP HANA, Teradata, Hive+Impala, etc. From OLTP to OLAP, but once in a while when I find it quick to, I still use MongoDB, and when I have it my way, I don't later migrate elsewhere.
tensor 9y ago
For good or bad, even though they've fixed these problems, I still don't have any trust in them as a company and will never recommend or look at their product. For me, their early days behaviour has defined their values as a company, and those are values I don't trust or agree with. If they were willing to nearly scam people once, what is to stop them again in the future? Clearly their motive is money over quality and without a serious change of management I don't see why anyone should consider that they've changed.

gshulegaard 9y ago

Well...to the best of my knowledge the Mongo DB BI connector in 2018 is still Postgres: https://www.linkedin.com/pulse/mongodb-32-now-powered-postgresql-john-de-goes/ https://www.linkedin.com/pulse/mongodb-32-now-powered-postgr... Has this changed?

metheus 9y ago
John radically overstates his case in that article based on incomplete information; note that none of the code he points to is even 1.0 code. Nonetheless, it’s accurate enough to say that the 1.0 BI connector used Postgres code. It was definitely the fastest way to deliver it. 2.x was built from scratch, it uses no Postgres whatsoever.
kstirman 9y ago
Yes this has changed. The BI Connector 2.0 is written in Go and uses the MySQL wire protocol: https://docs.mongodb.com/bi-connector/master/release-notes/ https://docs.mongodb.com/bi-connector/master/release-notes/

nevi-me 9y ago

I'm one of those people who come in and comment about MongoDB, positively. My first "stack" was LAMP, in 2012 when I learnt how to use it, it was: - a JSON store that works well with NodeJS - a geospatial database (yea, it has what I need) that was "easier" to work with - a database that made it easier for me to change my schema (if you just throw data at it, garbage in, garbage out). Over the years, I've followed development, and adopted new features to make my life easier. - I was one of the people who were excited about full GeoJSON support in the 2.* days, because that's something I depended on. - I've tailed the oplog for as long as I remember (never needed Redis), and have been learning about change streams (announced in 3.6) with the hope of submitting a PR to Apache Beam to support them. - I adopted a lot of the aggregation framework (Asya Kamsky from MongoDB personally helped me a lot) - The last time I migrated data from MongoDB was when I turned on WiredTiger in 3.0.* My little replica has been up for as long as I remember, the only time I have downtime is when restarting my server. When I start a new project these days, I still go to Mongo, because what held true in its early days still holds. It's quick to get something started. Yeah, there's $lookups, transactions in future; I've just leveraged features as they become available. I have Postgres in my stack, which runs TimescaleDB and is a backing store for my Gitlab instance. Would I use MongoDB professionally? It depends on the use-case. Over the past 2 years I've worked with Oracle, SAP HANA, Teradata, Hive+Impala, etc. From OLTP to OLAP, but once in a while when I find it quick to, I still use MongoDB, and when I have it my way, I don't later migrate elsewhere.

tensor 9y ago

For good or bad, even though they've fixed these problems, I still don't have any trust in them as a company and will never recommend or look at their product. For me, their early days behaviour has defined their values as a company, and those are values I don't trust or agree with. If they were willing to nearly scam people once, what is to stop them again in the future? Clearly their motive is money over quality and without a serious change of management I don't see why anyone should consider that they've changed.