10 ms·
MongoDB is to NoSQL like MySQL to SQL - in the most harmful way
- hakcermani 13y agoWhat is this ? 'Lets bash mongodb' week ?
- threeseed 13y agoDoes this offer absolutely anything new ? No. Is this person objective and well respected ? No. Does this person understand why MongoDB/MySQL is popular ? No. Is anyone going to gain anything from this ? No.
- Gigablah 13y agoIs the comment above going to get downvoted? Yes.
- threeseed 13y agoOf course. Bashing MongoDB is quite the fun past time here on HN. Having evaluated nearly every database for my own startup I find it extraordinary that there such angst towards a technology. Sure MongoDB has its faults but so does everything and surely competition is good to keep everyone honest. I mean would PostgreSQL really have had HSTORE if MongoDB never existed ? At least stop rehashing the same tired arguments for everyone's sake.
- Gibheer 13y agoI'm sorry, but the hstore extension is around 3 years longer. first commit for hstore http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=642194ba0cdc0aada9c99bf7712fcae5f3ac86d1 http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;... Wikipedia states the first release of mongodb for 2009
- BadassFractal 13y agoThat's some gorgeous schooling right there, kudos to you sir.
- threeseed 13y agoRead the commits. That was when it was storing key, value pairs. HSTORE as most people know it is the JSON/V8 implementation.
- simonw 13y ago"I mean would PostgreSQL really have had HSTORE if MongoDB never existed?"
- pilif 13y agoHSTORE still is only storing key, value pairs. Nested HSTORE is something we might get in 9.4. JSON/V8 does allow nesting but doesn't allow indexes for arbitrary value access - something that MongoDB easily does. So depending on your use-case and the type of documents and queries you are dealing with, neither the current HSTORE implementation nor the current JSON implementation will work for you, while MongoDB's model might. But the reverse is true too: Some use-cases are highly relational and it would be really painful to do that with MongoDB due to the lack of easy joins (you have to do them in your application logic which means a lot more work as your requirements change). Pick the right tool for the job. Me personally, I prefer the immense flexibility for querying a relational data set over the flexibility of not having to deal with schemas. The reason is that it's much easier to change or add an SQL query than it is to re-format and re-duplicate all of my data followed by more or less manually implementing as good query plan in application code whenever the requirements change. But this is a pure matter of taste.
- davidw 13y ago> Is anyone going to gain anything from this ? No. Well, if it stops someone from using MongoDB without really thinking about whether they ought to, maybe it'll save someone some grief in the future.
- threeseed 13y agoIf this was an intelligent piece analysing the pros/cons of MongoDB and when it would be an optimal choice then I could understand it. But this is the equivalent of blog spam from a guy who is selling a SQL Performance book.
- goldenkey 13y agoMany articles regarding MongoDBs awful memory mapped simple b-tree data storage method have popped up on HN. Martin is merely talking about the politics of MongoDB; to call his links to polyglot methods and his information blog spam is dishonest to say the least. I thought it was a great post and I bet many other HNers who up voted it feel the same way.
- annnnd 13y ago> MongoDBs awful memory mapped simple b-tree data storage method You realise that they are using default kernel implementation? Awful indeed. :) If you are so anti-MongoDB, would you care to offer an alternative? It must support: - document-like storage (I already have schema on application layer), - simple use / administration, - hot backup, - single node operation. While this list is mostly outlining why MongoDB is a great DB for my current use case, I am also genuinly interested in better solutions (for that case). So, fire away... :)
- goldenkey 13y agoEverything you've mentioned is standard to SQL databases. If you have a schema you don't need NoSQL. Use an ORM for SQL for the language of your choice. Pretty much any db will run as a single node but you should never do that in practice, redundancy is security is stability
- lzman 13y agoAgreed. The second point definitely after reading his other blog posts. This also applies to the Diaspora coder who blamed MongoDb for her company's problems. And anybody else who's having a relational epiphany.
- simlevesque 13y agoI've heard that some people use the MongoDB syntax with postgresql using redis as caching, could someone comment on this idea ?
- johannh 13y agoSo he's saying MySQL is bad, and MongoDB (because of a statement on their home page) is kind of like MySQL, so MongoDB is also bad. Also there was some article about scaling it to "only" 100GB which means it damages NoSQL as a whole in the "most harmful way". Sorry but I don't really get the reasoning.
- ekimekim 13y agoThe reasoning is: 1. MongoDB and MySQL have similar market penetration 2. MongoDB and MySQL both have limitations (these statements are independent) Then, from 1 and 2, he concludes 3: In the same way that MySQL gives SQL a bad reputation, MongoDB gives NoSQL a bad reputation.
- choult 13y agoThe problem for MongoDB is that its limitations are far less understood by its users than with MySQL.
- goldenkey 13y agoMySQL is an awful implementation of SQL. MongoDB is even more pitiful of an implementation of NoSQL. It's a Fischer price database that had a global write lock until version 2.2. What exactly don't you understand about the analogous nature of two crumby data stores?
- mrmondo 13y agoNot to mention it is not fun to admin.
- lucian1900 13y agoIt still has a global write lock, but now it's only global to the database.
- goldenkey 13y agoI did not know this. That would be pretty awful for a high traffic service.
- egil 13y agoEarlier discussion: http://news.ycombinator.com/item?id=6481526 http://news.ycombinator.com/item?id=6481526
- Nodex 13y ago1. What point are you trying to make 2. Are you bashing MongoDB because it's hip to bash it. 3. Do you actually know what you're talking about when it comes to MongoDB / "NoSQL" solutions in general because I think not.
- kayoone 13y agoI have never really touched NoSQL for anything serious, yet i have worked with Riak, MongoDB and Redis. In the case of MongoDB i have worked with an ODM on top of it where i had to define a Schema and Object relations and was left wondering: What is the benefit of this anyway if i still define Schemas and relationsships ? Does it just make sense at a big scale when i would have to shard using MySQL ? Schema migrations arent that hard today in MySQL with a good framework, so i am not really sold on the benefits for smaller apps. If i can just save a JSON Object to it, thats cool (however Postgre is goot at that too), but in practice with server side validation and schemas i have to decode/encode anything anyway. Can anyone enlighten me on the real benefit ? Edit I see many benefits in using Redis though, just for its sheer speed and more as a smart memcached replacement though.
- goldenkey 13y agoThere really is no benefit to using NoSQL if your schema is well defined unless your queries don't use indexes an all you want is a stack of documents. SQL is faster for structures data when the queries rely on well defined indexes and well defined data types
- lucian1900 13y agoAbsolutely no benefit to Mongo. It's even really slow, so there's really no advantage at all. Redis, Riak and the like are actually useful for a change.
- raverbashing 13y agoCan you explain this a little better since you apparently know all three? I know Redis (and Mongo), not Riak, and Redis shines in certain aspects but depending on what you want it's not the right choice.
- annnnd 13y agoMongoDB slow? Could you post a benchmark to support this claim?
- 13y ago
- goldenkey 13y agoI think the biggest lesson here for us engineers is that we should watch and brace ourselves for similar tech buzz offerings like MongoDB. A few years when I went for interviews for startups, it was shameful that I didn't have experience and wasn't using MongoDB in my own products. I was a 'rusty spoon' for using resilient SQL. Funny how even engineers, a whole industry, can get swept up in using a subpar data store because it's the new cool piece of tech that makes it easier to have json you throw to a wall stick. I will never feel shamed again for not using some hot shot popular offering only because it makes development a tad bit easier. As engineers the end result is most important and we shouldn't sacrifice our platform stability just to ease our code editors and some minor migration frustrations. /endrant
- zimbatm 13y agoThe key argument is that nobody knew the performance characteristics. While developers looked at the API they where enchanted by it's perceived simplicity, but knew nothing about the behaviors of the database under load. Understanding the various tweaking parameters and failure modes is an even more important part of any database than the API in production.
- dmak 13y agoFrom my experience, as soon as you need some kind of relation with Mongo, you end up writing more application logic to create and maintain your relations. This probably means you should move to a relational database. For Mongo specifically, can anyone share a pragmatic use case where you did not run into problems with duplication?
- jzwinck 13y agoOne example is logs. People have logs, and lots of them. They're usually semi-structured (hopefully there is at least a timestamp and topic and severity in each record). You can put them in MongoDB, and relations are probably not a big concern.
- digitalzombie 13y agoElasticsearch or Solr would be better than Mongodb for Logs. Hell if you actually care about your log and want to search it use Solr or Elasticsearch NOT Mongodb. If you want to store even more data just use Cassandra and index it with Solr or Elasticsearch. Cassandra have faster write than read, it's perfect for logs. You can decentralize logging system too, there are architecture layout out there with elasticsearch and such (example: https://medium.com/what-i-learned-building/e855bc08975d https://medium.com/what-i-learned-building/e855bc08975d). MongoDB is a poor choice, in general for anything in my personal opinion.
- philbo 13y agoNot sure if it counts as a pragmatic use-case, but here's my example. I recently built a little webapp [1] to send email reminders about repositories that you've starred on GitHub. The motivation for it being that I have hundreds of starred repos on GitHub and can't remember what most of them are. Anyway, there is one thing I need to store in that database, users. Nothing else needs to be saved. You can accurately characterise it is a toy application that I built for fun rather than profit. But there are lots of those around and Mongo is often a good fit. If I don't need complex schemata or a huge dataset, why would I choose something else that is less easy to manage? [1] https://githubreminder.org/ https://githubreminder.org/
- dschiptsov 13y agoIf PHP is a fractal of bad design, then MongoDB is PHP of database world.) As for MySQL, Mongo marketing guys have learned the lessons from MySQL very well - there are nothing but "satisfied users", "good documentation" and "quickness and easiness" (any thinking, leave alone understanding aren't required) on their site and paid content - well-done "product", designed to trigger an ignorant consumer snap-judgement, the same way MySQL did at its time. They use the same sales strategy. http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
- rodgerd 13y agoAt least the MySQL guys eventually gave up trying to convince us that referential integrity is a crutch for sub-par programmers.
- dschiptsov 13y agoWhat referential integrity?) It is My free SQL, everybody's using it. Table-level locking? Never heard of them.)
- chris_wot 13y agoNot sure what you are referring to here, but MySQL definitely has referential integrity constraints, and InnoDB uses row level locking. Not sure what level of transaction isolation support is build in though.
- dschiptsov 13y agoThe InnoDB was not the default storage engine for quite a long time and it wasn't stable-enough for years.
- chris_wot 13y agoOK, I'm not a huge fan of MySQL, but InnoDB is what is used now. I'm only really interested in the latest releases of MySQL.
- Kiro 13y agoTired of this. I think MongoDB is the best thing ever!
- puzanop 13y agoNot surprised that a person who gets his salary with SQL work is unhappy with a competitor that does not use his favourite word...
- lucian1900 13y agoThis isn't really being fair to MySQL. It was pretty terrible when it started out (corrupted data, no joins, no transactions, silly locking, didn't support half of SQL, etc.), but we must not forget just how terrible Mongo was and still is. It shipped with unacknowledged writes as the default for a long time.
- smanuel 13y ago> The article is about handling MongoDB if it grows above 100GB. It gives me the impression that scaling MongoDB to that size is a serious issue. I don't think so. It gives me the impression that 10gen (MongoDb Inc.) has made a mistake how to present "handling MongoDb over 100GB". > example: global write lock up to release 2.2 Why are we still talking about this? It's not global write lock any more, okay? Stating previous inefficiencies doesn't bring much value to the table. > At this point it was inevitable to see MongoDB as a popular, yet poor representative of it’s species. Show me the real arguments! Show me the real arguments!
- spamizbad 13y ago> Why are we still talking about this? It's not global write lock any more, okay? Stating previous inefficiencies doesn't bring much value to the It's now a db-level lock, which is an improvement but not optimal. And its locking system in general isn't as sophisticated as, say, a recent version of Postgres, MSSQL, or Oracle. Neither is its query planner, where using an $or can cause it to scan all the documents in a collection despite the fact that you should technically be hitting indexed fields.
- annnnd 13y ago> ... despite the fact that you should technically be hitting indexed fields. Never had that experience - could you elaborate? Indexes in MongoDB are a bit different from SQL indexes, so if you are comparing to that, you are in for a few surprises. :)
- amix 13y agoMySQL was a great database that solved a problem. It did not solve it in a 100% complaint way, it did not have all the features that "dbms experts wanted", but in the early days it was very easy to started. In version 5+ they have fixed a lot of the issues and it is now on-par (or better) than most other databases. I also think they have focused on the right stuff: ease of use, easy way to fix performance issues, great ways to setup replication, great ways to take backups, not losing data, optimized to be used for the web etc. Also, most bigger properties (including Facebook and Google) use extensively MySQL. If Mongo is going to be like MySQL, then great!
- davidw 13y ago> but in the early days it was very easy to started It's easy to start a bicycle rolling down a steep hill too. It's only later that you find out whether the brakes, tires and handling characteristics are up to par... > features that "dbms experts wanted" Maybe they want those features because the know what they're doing, and think some of those features are pretty critical.
- amix 13y agoAnd you base this on what? MySQL is used to scale some of the biggest Internet properties in the world and it has been doing that for many years. Stop spreading FUD.
- smoyer 13y agoFUD is actually useful (engineering FUD rather than marketing FUD) ... if you pick MySQL because it's easy to get started, you need to know its pros and cons. Those scaling MySQL at the biggest Internet properties in the world ARE database experts - Facebook for instance has a custom cache and memcached in front of their MySQL instances [1], shards their data and also uses other database technologies where appropriate. People like Facebook’s Mark Callaghan will be successful using any reasonable database. [1] - http://gigaom.com/2011/12/06/facebook-shares-some-secrets-on-making-mysql-scale/ http://gigaom.com/2011/12/06/facebook-shares-some-secrets-on...
- 13y ago
- annnnd 13y agoCome on, give MongoDB a break. I use MongoDB and I am proud of it. And I have used numerous SQL DBs (MySQL, PostgreSQL, Oracle, MSSQL, SQlite) and HBase from noSQL camp, so I do have something to compare to. Yes, it was overhyped (and is underhyped now, at least on HN). Yes, it has its problems. Yes, it is not correctly positioned in people's minds (web-scale? not really). MapReduce on top of MongoDB, in a single-threaded JS engine - are you kidding me??? But it is useful tool nevertheless; one I am happy to have in my arsenal. MongoDB will NOT solve your scalability problems. Old news. It will even add some of its own problems on top of it. But man, is it nice to just fire that data into your database and forget about DB-level schemas... And when you need that data, it is just there. True, I have built an ORM on top of MongoDB so it manages the DB for me; but it was easy to do and is incredibly useful. I would have done it with MySQL too (actually, I did - and it was a PITA to build because of relational databases' rigidness). So please, stop bashing MongoDB for wrong reasons. It is an excellent and easy to use storage - when used for the right kind of problems. Nothing more, nothing less.
- chris_wot 13y agoHow did you build an ORM on top of MongoDB? And why?
- annnnd 13y agoSorry, poor choice of words... I have build an ORM on application level above MongoDB. This level lets me specify data model in a simple JSON and the system then automatically performs all (high-level) data input validations, displays a proper web form to the user,... There are actually many similar systems to mine, I just couldn't find one that would offer all the functionalities I needed. Note that DB is just a storage for me. It can't know enough to validate for example e-mails, because for DB they are just strings.
- chris_wot 13y agoThat's not an ORM, that's a data abstraction layer.
- smoyer 13y agoI think there's one other problem that affects most NoSQL systems - the perception that adopting a NoSQL means you don't have to think about your data. When designers and front-end developers want to develop a web application they can do one of two things; a) say "don't worry about the back-end, we'll just throw it in a NoSQL database" or b) learn to also be a back-end engineer. The idea that you don't need to worry about your data structure is deadly. Every successful project I've been involved with thinks seriously about the data model. ER diagrams with 160 tables aren't uncommon and knowing the structure of your most common queries helps you make sure that your database isn't over-normalized. There's a science to data systems after all. "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." - Frederick P. Brooks from The Mythical Man-Month. I quote or paraphrase this fairly frequently as I've come to believe it. If I understand your data structures, I can pretty easily tell what you might be doing with the system and I can read the code to see which parts you've implemented. But don't use this as an excuse to delay working on the rest of the application. There are Architecture Astronauts in the realm of database modeling too! "Normalize until it hurts, denormalize until it works!" - Unattributed adage. The key is to understand your data (and it will provide an amazing boost to the rest of the project). If you're worried about having your data-model perfect before you start coding, you should have started coding already. There are practices you can adopt that make refactoring your database more tenable. I recommend you read the "Evolutionary Database Design" article by Martin Fowler and Pramod Sadalage (http://www.martinfowler.com/articles/evodb.html http://www.martinfowler.com/articles/evodb.html), then adopt a workable technique as a team.
- bitdiddle 13y agoYes, this is often overlooked, and one of the main downsides to NoSQL databases. Schemas don't really go away they just get pushed into the application layer. When multiple apps use the same database, schema maintenance and evolution become a real issue. Perhaps it's because much of web scale data is arguably tissue paper data, more useful in the aggregate. Transactions and constraints on the data seem to be less a concern. In this regard I think key-value stores are preferred over document stores such as MongoDB and CouchDB. A key value store makes it clear where the semantics of the data belong.
- jed_watson 13y agoHonestly, I see very few thought-out or backed-up arguments here. The server-level blocking, the unacknowledged writes, silly defaults, etc are not only old news but have been behind mongodb for a while. You also get comments like 'it still has database level locking' but rarely is there an educated discussion about the work that's been done to yield locks as quickly as possible and the real-world impact of this design. People seem intent on punishing the platform for old mistakes (or immaturity) rather than providing a balanced view of it today. And comments like "Absolutely no benefit to Mongo. It's even really slow, so there's really no advantage at all." are just misleading without context, because it's at all true as an outright statement. I spent today at the MongoDB developers conference in Sydney, and heard the CEO speak about when they think mongodb is good vs when you should use RDBMS, heard them speak about their community and target market, and heard a lot of stories and strategies about how to prepare for scale, how to think about schema design, how to monitor and admin the database / clusters, etc. I'll just say that from hearing them in person, and hearing what people say about both the platform and the "marketing guys", you'd never know they were talking about the same company or product. My own company has had a lot of advantage from using MongoDB in recent projects over other technologies (we have a largely MSSQL background). No, we don't do 100GB+ "web scale" (yet). Yes, we build solutions to real world problems and make money. No, it's not a silver bullet. Yes, you should know what you're doing and read the docs. To any hackers / entrepreneurs who are thinking that MongoDB might work for them I'd say do some research, talk to people who've actually used it, and understand the benefits / limitations for yourself. But stay away from opinions not based in real experience (and anything that mentions problems from before version 2.4, it's nearly a year old people) or you might miss out on something good.
- jaxytee 13y agoNot to mention that the authors only critique of MongoDB was global write locking from version 2.2. The rest of his article was empty text speaking NOSQL databases his friends think are cool and statements equating too "MongoDB is bad. Why? Cause it is." All if this ends at his signature that mentions his scaling SQL book. Not like he has an axe to grind or anything.
- CalRobert 13y agoSheesh, what's with the MongoDB witch hunt? It seems like HN can't go 2 days without some disparaging of MongoDB. I get it. I'm an idiot for using MongoDB even though it suits my needs perfectly.
- chris_wot 13y agoI really don't see that the author put forward a convincing argument. He seems to be stuck in the 100GB data blog post, but he confuses NoSQL with literally "don't use SQL", which is really somewhat missing the point of so much of this space.
- nailer 13y agoI'm a long time (3 years) MongoDB user. My experience of the current state of the art: - The official documentation is clearly written by someone who doesn't speak English as a first language. - Their official driver (Node.JS 1.3.13) silently throws away exceptions. Both these have been acknowledged by MongoDB Inc (formerly 10Gen). I can't speak for you, but personally I do feel like an idiot for using MongoDB.
- treskot 13y agoThis discussion has happened before. MySQL is to SQL like MongoDB to NoSQL - https://news.ycombinator.com/item?id=6481526 https://news.ycombinator.com/item?id=6481526
- mcphilip 13y agoMy guess as to the rise of MongoDB usage is that the rapid application development needs of the startup world led to people deciding that representing application data as JSON across all tiers speeds up the early stages of development. Unfortunately, as soon as data needs to be used relationally, developers are finding themselves pigeonholed in an inappropriate persistence format. In short, developers that skip studying how their data might need to be queried in the future are to blame, not MongoDB.
- rainmaking 13y agoI never understood what Mongo brings to the table that ext4 doesn't.