7 ms·
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
by BillFinchDba 10y ago
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-optimal experience way back when, you'll see a mature product that is consistently improving and is demonstrably reliable. Can you give an example of another option you are referring to?
- digitalzombie 10y ago> 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 want time series there are few out there but it's a niche. Likewise if you want graph data then there are NodeJS, Titan, etc.. MongoDB at most company I worked with was use because they don't think about what type of data it is and what performance they want. They want to store unstructure data cause it's easy. I personally think it's a cop out, especially as a statistician/programmer.
- dijit 10y agoFor me, mongodb was like a document-store on tmpfs. And, I can't sell that to people I work with.
- elvinyung 10y ago> if you want graph data then there are NodeJS I think you meant Neo4j.
- mabn 10y agoWhat if I want filtering by several criteria (on a table with 1k columns) and simple aggregations, but I don't need full-text search* ? I'm still looking :( * I only want starts-with and contains on strings.
- ralfn 10y agoNot 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?
- hendzen 10y agoDo you not consider Stripe to be a competent team? Please, name some F500 companies using RethinkDB to power critical infrastructure. There are many using MongoDB. While Rethink is widely renowned among the HN set it is nonexistent in comparison when looking at actual deployments. The reigning HN view of MongoDB being a buggy mess is outdated. Yes, they overmarketed a buggy project in 2009. It didn't matter, because they built a product that developers loved (and continue to love) to use. RethinkDB didn't aggressively market itself, and look where it is now - defunct. Mongo used that momentum to raise money and hire an incredible engineering team, including Keith Bostic, one of the fathers of Unix, and Michael Cahill, the inventor of the transaction isolation mechanism used in Postgres. Sometimes you need to employ aggressive business tactics to get to a point where you have the engineering resources to build a world class project. Moreso when you need to catch up to millions of man hours spent building Oracle and MSSQL.
- dijit 10y agoah, 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.
- hendzen 10y agoThat specific point was in reply to the GP's statement that "competent teams" weren't using it in production.
- josephg 10y agoRight 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 that bet if you made it any day in the last 10 years. And in those 10 years mongodb has demonstrated again and again that they aren't up to the task of writing a reliable database. Even with their new storage engine they couldn't find the bugs alone. I think using mongo today for any mission critical data is an irresponsible choice. I'd seriously question the judgement of any senior engineer who picks it for a new project over rethinkdb or Postgres.
- laichzeit0 10y agoDo 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.
- nurettin 10y agoIn my experience, mongo lets you check the end result and try inserting again.
- deathanatos 10y agoHow 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.
- 10y ago
- radicalbyte 10y agoSQL Server and Oracle are hardly comparable. The issues you see there are more to do with backwards compatibility or performance impact of big new features than they are with the core stability.