Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Migrated Away From MongoDB

svs.io

Post reply on HN
Print view View original

91–100 of 213 posts

Re: Why I Migrated Away From MongoDB

#91

Post by flatline3 »

stickfigure wrote: post #77
yxhuvud wrote: post #68

Earlier quoted context omitted.

The problem with your argument is that all problem will look like it will have polymorphic and ambigous data until you have mapped it out properly. What the post you replied to was basically an advice for new projects and developers to fully map out the problem and see where things are going. It is a lot easier to start strict and organized and back down to less strictness with looser rules where you need it, than to…

Perhaps for "new developers". If the question is "as a neophyte developer, which should I learn first, Postgres or MongoDB?" then I would tend to lean towards SQL as well. But that isn't the proposal. The problem is the old cliche that if all you have is a hammer, everything looks like a nail. "Just start with a hammer" is bad advice because with enough effort and willingness to cause collateral damage, you can almos…

You failed to address the parents point entirely: it's a lot easier to start strict and loosen restrictions later, than it is to start loose and add restrictions.

Re: Why I Migrated Away From MongoDB

#92

Post by tonynero »

The guy is getting such hate on the comments on his site, yet his opening line is that his choice was ill thought. Let him express his issues right?

I choose MongoDB for my last side project and while it was awesome working schema-less and developing the client facing part of the project was certainly quicker to deliver, i feel pretty lost on the analytics/BI side of it and couldn't say it better than him: "Not having JOINs makes your data an intractable lump of mud"

So coming from a relational/SQL background I found MongoDb awesome upfront, but frustrating later on... and yes I'm off to learn http://docs.mongodb.org/manual/applications/aggregation/

Re: Why I Migrated Away From MongoDB

#93

Post by sray »

gaius wrote: post #81
sray wrote: post #41

Earlier quoted context omitted.

Can you explain your reasoning? Isn't high scalability one of MongoDB's key features?

When you go to the supermarket, you may see products calling themselves "quality" or "luxury" or similar. Words like "powerful" and "scalable" are like that.

Thanks, but you didn't really explain anything. In what specific ways does it fail to scale well?

Re: Why I Migrated Away From MongoDB

#94

Post by jeffdavis »

stickfigure wrote: post #43
rbranson wrote: post #14

I'm no fan of MongoDB, but this same advice goes for any NoSQL data store. I am an Apache Cassandra contributor and community MVP, but my advice stays the same: it's best just to start with a SQL database and go from there. Read some books and learn it well: the "SQL Cookbook" from O'Reilly is great, and so is "The Art of SQL." Premature optimization continues to be the root of all evil.

it's best just to start with a SQL database and go from there. This is bad advice. It's best to understand your problem domain and use the tools that are most appropriate. You see a lot of two types of posts on HN: * "I picked a NoSQL database for a problem domain with a better relational fit." Those posts look like this one. * "I picked an RDBMS for a problem domain with a better NoSQL fit." Those posts are usually…

"It's been stated many times already: Use the right tool for the right job."

The problem with that argument is that things change, and it's not always obvious what problems you will need to solve when you start a project.

RDBMSs are backed by extensive theory as well as decades of product hardening, development of expectations and best practices, and battle-tested in production environments. They are explicitly designed as general-purpose systems. That means that when your needs change and you need to adapt, an RDBMS likely provides features that make that transition work smoothly and avoid breaking applications.

At this time, those things are not true of MongoDB, so it is somewhat more specialized. That's OK, but it means that you need to be more careful about using it than, say, postgres. Trying to put MongoDB on equal footing with postgres and say "choose the right tool" is an oversimplification.

I think it's perfectly reasonable advice to start with SQL unless you have specific reasons that you think something else will be a better fit.

Re: Why I Migrated Away From MongoDB

#95

Post by pnathan »

zemo wrote: post #67
gaius wrote: post #48

Earlier quoted context omitted.

The thing with the NoSQL guys is that many of them seem not to be in a position to make an educated comparison. For example, an, uhh, enthusiastic MongoDB advocate recently informed me that MongoDB was superior to Oracle because in Oracle you had to poll a table to see if it changed. Except, no, that isn't actually true: http://docs.oracle.com/cd/B19306_01/appdev.102/b14251/adfns_... - and that document is from 2005.…

MongoDB is disproportionately liked by the inexperienced. There are things to like about it, and being able to have sparse secondary b-tree indexes on arbitrary data is, overall, pretty rad. For prototyping, being able to just toss some shit in there, especially when your data comes from an external service and you're not in control of your incoming data (very common these days), it works great for simple use cases a…

What I like about Mongo is that it's very free-form; I can splat some data in there and not be too concerned about it until later on. I don't really like dealing with file systems for holding data.

Of course Mongo ain't the best at relational data... :o

Re: Why I Migrated Away From MongoDB

#96

Post by Klinky »

sray wrote: post #93
gaius wrote: post #81

Earlier quoted context omitted.

When you go to the supermarket, you may see products calling themselves "quality" or "luxury" or similar. Words like "powerful" and "scalable" are like that.

Thanks, but you didn't really explain anything. In what specific ways does it fail to scale well?

A few of the major issues I've seen around are the global write lock which is starting to get taken care of. The reliance on the OS to cache instead of intelligently caching based off data. Poor fail over support. Sharding not being a "turn key" solution like it was supposedly advertised as, misconfiguring it can lead to poor performance. Bringing extra nodes online can take a long time for data to migrate over to the new nodes.

Re: Why I Migrated Away From MongoDB

#97

Post by taligent »

jamesli wrote: post #17

I am both a database guy and a software engineer. Being a software engineer, i kind of understand the hype behind NoSQL. Being a database guy spending years in studying how database engine works under the hood, many NoSQL implementations make me wonder how powerful marketing can be. In general, I love the ideas behind NoSQL. I can still feel the excitement when reading the BigTable and MapReduce papers. HBase, Hadoop…

> Being engineers, we must understand the implementation and be full aware of its limitations, instead of believing their marketing materials.

And as engineers we must understand that most other engineers do take their role seriously and evaluate products on their merits.

Implying that they are falling for "marketing" just because you don't agree with their choice and then lecturing them for their choice doesn't make you come across well.

Re: Why I Migrated Away From MongoDB

#98

Post by stickfigure »

flatline3 wrote: post #91
stickfigure wrote: post #77

Earlier quoted context omitted.

Perhaps for "new developers". If the question is "as a neophyte developer, which should I learn first, Postgres or MongoDB?" then I would tend to lean towards SQL as well. But that isn't the proposal. The problem is the old cliche that if all you have is a hammer, everything looks like a nail. "Just start with a hammer" is bad advice because with enough effort and willingness to cause collateral damage, you can almos…

You failed to address the parents point entirely: it's a lot easier to start strict and loosen restrictions later, than it is to start loose and add restrictions.

I'm not sure what this has to do with SQL vs NoSQL. There are myriad differences between storage systems which have little to do with referential integrity constraints or data validation.

Polymorphic structures are a PITA to model in relational tables, but they fit very well in schemaless, document-oriented NoSQL systems. This has nothing to do with data validation.

Rapidly changing schemas are a PITA in RDBMSes, especially with a large cluster of servers. It's usually very easy to alter schemas on-the-fly with NoSQL systems. This has nothing to do with data validation.

On a related point, the database is a crappy place to put data validation anyways. It can only do the most primitive forms of validation (is this an integer? is the FK reference valid?). Application level-validation gives you the full power of a modern programming language and all the data you could possibly want to fetch. Yeah, "senior discount" is a float... but it should only be given to people over age 65.

The fact that the OP managed to insert "111" into a column instead of 111 means he is using crappy tools. My datastore api guarantees that integer fields in my (statically typed) classes are written as integers. I never have this problem, nor have I ever taken down my GAE (NoSQL) applications for maintenance.

Re: Why I Migrated Away From MongoDB

#99

Post by ozataman »

blaines wrote: post #82
gregjor wrote: post #75

Earlier quoted context omitted.

I don't know if there's a use case. I have never had one come up in my own projects. I do sometimes need to manage a large number of documents (unstructured data) but I have found the Unix file system sufficient for those, maybe augmented by metadata in the database. I've worked on big applications with big databases where DB operations and aggregations started to get too slow but so far I or someone smarter on the t…

Respectfully, I believe your comment is not very open minded. I believe the obvious answer is "Of course there's a use case!", just like there's obviously a use case for RDBMS, NoSQL (Mongo, Cassandra, BigTable, Redis, etc) serves a purpose. I'll give you a couple examples. Google stores a huge amount of data in BigTable [1] which is fundamental for the operation of Gmail at scale. Another, Facebook initially used Ca…

I'm not sure if Cassandra and Bigtable are "document" databases in the same vein as MongoDB. These guys are more like turbo-charged key-value stores - which is quite different. They trade in the ability to manipulate data for an ability to scale out linearly and have no singular point of failure (and of course various other trade-offs). Cassandra nicely gives you composite columns and column-key sorting, but that's about all you're going to get.

Re: Why I Migrated Away From MongoDB

#100

Post by wamatt »

gregjor wrote: post #42

You were fortunate to recognize that MongoDB was the wrong tool for your job, and lucky to be able to move to Postgres instead of continuing to throw your time and effort away. I see the ad hominem "you're an ignorant idiot" attacks already started, along with advice like using regexes to do case-insensitive searches. Watching the NoSQL "movement" encounter the problems RDBMSs fixed 20 years ago and then hand-wave an…

> Watching the NoSQL "movement" encounter the problems RDBMSs fixed 20 years ago and then hand-wave and kludge them away is frustrating.

But but but.... NoSQL is cool ;)

Post reply on HN