6 ms·
Is MongoDB going to fix their scalability, performance, JOIN, and data type support problems with the money? Seems like a bad investment to me since a lot of de
by rpedela 13y ago
Is MongoDB going to fix their scalability, performance, JOIN, and data type support problems with the money? Seems like a bad investment to me since a lot of developers are starting to move away from it because of those problems and others.
- throwawayyyz 13y agoI'm pretty sure their download numbers say otherwise. One or two HN threads complaining about MongoDB every month are not a good indicator for their future success.
- crazytony 13y agoIn the short term it's probably inversely proportional: more 'complaints' means more people on the platform (or at least experimenting with the platform). In the long term we're all dead anyway.
- AlisdairO 13y agoYeah. FWIW, working at $BIGCORP, I'm starting to hear buzz around Mongo from quite a few not-very-technical people. I'm pretty negative on Mongo as a technology, but there's no doubt that it's generated a lot of attention.
- ddorian43 13y agowhat are the data type problems?
- jzwinck 13y agoWell, some of us have been asking for a native high-resolution time type for three years: https://jira.mongodb.org/browse/SERVER-1460 https://jira.mongodb.org/browse/SERVER-1460
- rudiger 13y agoCan't you just store it in a regular 64-bit integer and know it's a datetime from your application's logic? What do you gain with a native, high-resolution datatime type?
- bqe 13y agoAutomatic timezone conversion and the ability to add and subtract dates without first dropping to your 64-bit into. Think DATE_SUB(date time, INTERVAL 1 HOUR) from MySQL for instance.
- rpedela 13y agoSupport for arbitrary-precision decimal. Known as numeric/decimal in Postgres. This can be a problem for financial and scientific applications.
- spongle 13y agoYep we canned it because of that, plus it was unreliable and our code and architectural review scared the shit out of us.
- joelhaasnoot 13y agoFor every developer you hear that has problems with Mongo, there are probably 5 that are fine with certain downsides.
- orthecreedence 13y agoYou're right. It's easy to compile, configure, and start on a dev VPS. It's easy to fill with data and easy to query. This is the sweet spot: when MongoDB is on a dev VPS and you're building a small product around it. Most devs don't have to worry about the next step. Then you push everything live. If you're lucky enough to get any real traffic, everything other than 99% read crumbles. You scramble to shard but realize that sharding just doesn't work well, and is incredibly complicated to set up. Then you start losing data...because the drivers are programmed to not fucking check if the data you sent was actually written (yes, I know, this is fixed). Ok, you set your driver on your flopping app to validate writes, and BAM there goes 80% of the write performance 10gen promised you. The solution? Just add more shards!! Ok, so now I have 4 shards, each with 3 repsets + 3 config servers. 4 * 3 + 3 = 15. Fifteen servers to handle what one MySQL server could do in its sleep. Conclusion: MongoDB is terrific as a write-only, developer friendly database that you will never have to scale, ever.
- nasalgoat 13y agoI wish I could upvote this comment more. I have to run over a hundred instances of MongoDB to equal the performance I could get from ten Postgres boxes, but now we have such massive lock-in on MongoDB we can't easily refactor.
- jeltz 13y agoWould it be possible for you to write a wrapper and use the Mongo API against another DB?
- nasalgoat 13y agoThe main issue is it being a JSON document store, and our application being designed around that and using the very specific MongoDB queries that involves. Any wrapper would likely be worse than just keeping MongoDB.
- omni 13y agoCan you point me to an article that explains why you would want JOINs in a NoSQL database to begin with? I thought the entire point was to denormalize your data. I keep seeing this point brought up, but it reads to me like a misguided complaint stemming from misunderstanding how to apply the tech.
- rpedela 13y agoUsing hierarchical data structures takes care of the most common use case of JOIN (i.e. "SELECT * FROM a, b, c"). This is a win for MongoDB. However there are times when you want to JOIN multiple hierarchical data structures [1]. Or use a different type of JOIN. [1] http://tebros.com/2011/07/using-mongodb-mapreduce-to-join-2-collections/ http://tebros.com/2011/07/using-mongodb-mapreduce-to-join-2-...
- mason55 13y agoSo JOIN in your application. Or use a different DB. MongoDB isn't correct for every use case and they would never claim it is.
- ArbitraryLimits 13y agoAm I just too old for HN now? I can understand calling something that holds your data and makes it so you don't have to do JOINs a database. I can understand calling something that holds your data and does JOINs for you a database. I'm having trouble calling something that holds my data and makes it so I have to "JOIN in my application" anything but a file system.
- untog 13y agoI don't know, what is the definition of a database? I'd be surprised if it mandated joins.
- gaius 13y agoActually, if you speak to them, they do claim that. Then they backtrack when you call them on it, but I've heard guys from 10gen as they were known then claim their product was a drop-in replacement for Oracle.
- yapcguy 13y agoHow does CouchDB compare? What are the latest thoughts on this?
- moox 13y agoIf you're having issues with scaling and performance, you're most likely using MongoDB the wrong way or for the wrong reasons.
- gfodor 13y agoBegging the question. If this is true anyone having trouble with mongo for legit reasons can be labelled as "using it for the wrong reasons."
- vdaniuk 13y agoAka "no true Scotsman" fallacy
- moox 13y agoHe could also be using it the wrong way. Although MongoDB has faults, most of them are well known and developers are warned. MongoDB is far from being perfect, but the most common reason people hate on MongoDB is because they did things the wrong way or for the wrong reasons.
- sandGorgon 13y agonobody ever got fired for choosing: 1. Oracle 2. SQL Server 3. MongoDB
- mattdeboard 13y agoOh but I wish they had
- throwaway8199 13y agoMongoDB accounted for ~90% of my startup's downtime in its first year of existence. We switched away to MYSQL and suddenly scalability concerns retreated into the future.