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

Failing with MongoDB

blog.schmichael.com

Post reply on HN
Print view View original

21–30 of 128 posts

Re: Failing with MongoDB

#21

Post by hello_moto »

viraptor wrote: post #17
hello_moto wrote: post #14

Earlier quoted context omitted.

I've been dev since I graduated. I had been everything else during my intern (dev, qa, test-automation developer, tools dev, build engineer, integration engineer, etc). Are you saying that Rails schema migration can only solve 10% of your migration needs? That kinda suck bro.

Migration tools are great once you stop changing the schema very often like it happens when a project starts. This of course depends on the project... if you can have a full design from the start, it's probably going to work too. If you don't know the exact requirements or way to get there - not so much.

If you change your schema once every 2-3 days, something wrong with whomever leading the software project. That's like writing a software with zero planning or lack of knowledge for the problem domain.

I don't care if it is a startup or not. Come up with a very simple idea, draw the models in ER diagram, implement that stuff.

It's very hard to imagine that tomorrow suddenly all relationships need to be changed. Even if that is the case, scrap your Repository/Entity model and start from the beginning.

Nothing can help you much if the fundamentals are wrong.

Re: Failing with MongoDB

#22

Post by jethroalias97 »

BarkMore wrote: post #3
nomongo wrote: post #2

Why is a database that fails so easily and most of the time even loses data so popular? Is it really all just a huge marketing budget?

The the data model contributes to it's popularity. A document store with indexes on document fields is very convenient for several types of applications.

It's interesting that couchdb gets little love (as evidenced by google trends), but it has document storage by index, easy enough to install, copy on write so has no global lock, sharding with bigcouch, and all client access is entirely REST... it may be couch is a little hard to grok, I dunno.

Re: Failing with MongoDB

#23

Post by hello_moto »

cperciva wrote: post #15
hello_moto wrote: post #9

Earlier quoted context omitted.

Not a bad business strategy. Kinda like MySQL back then right?

Sadly, it seems that "give them free crap and then charge for fixes" is a very common business model in the open source world.

Better than asking for big pile of money and give back crap and charge way more for fixes isn't it? :)

Re: Failing with MongoDB

#25

Post by gmcquillan »

amalag wrote: post #13

If your data is easily modeled relationally, go for relation, if you are going to change it constantly and is not a natural fit for a relational model, Mongodb is worth a shot. From this article, sounds like their data is pretty seriously relational. Mongodb has been pushing the ops side of their product, but I can agree it has failings there. To me the advantage is the querying and the json style documents.

I'm not sure you read the article fully, because relationships were never described in the article. Instead, it was high read/update load which caused problems.

Mongo, on paper, should be an ideal candidate for this job; but, due to complications with the locking model and with its inability to do online compactions, it's failing.

Re: Failing with MongoDB

#26

Post by wisty »

jethroalias97 wrote: post #22
BarkMore wrote: post #3

Earlier quoted context omitted.

The the data model contributes to it's popularity. A document store with indexes on document fields is very convenient for several types of applications.

It's interesting that couchdb gets little love (as evidenced by google trends), but it has document storage by index, easy enough to install, copy on write so has no global lock, sharding with bigcouch, and all client access is entirely REST... it may be couch is a little hard to grok, I dunno.

Couch doesn't have great documentation, and doesn't have official native client drivers. Oh, and it's slow (though you can tune it, and it doesn't crumble under load).

Re: Failing with MongoDB

#27

Post by rhizome »

viraptor wrote: post #7
nomongo wrote: post #2

Why is a database that fails so easily and most of the time even loses data so popular? Is it really all just a huge marketing budget?

If I never expect the dataset to grow past 1GB and a single server, why would I use anything else? It doesn't really fail - none of the issues described were "failures" really. [edit: just to be clear, it didn't crash and burn, I don't think performance issue == failure] The data loss was not confirmed either: "There appears to be some data loss occurring" and in small deployments you can just use transaction log. Th…

The data loss was not confirmed either: "There appears to be some data loss occurring"

Oh, this mystery is a failure all right, and even the most charitable interpretation would call it a misfeature.

Re: Failing with MongoDB

#28

Post by Devilboy »

viraptor wrote: post #17
hello_moto wrote: post #14

Earlier quoted context omitted.

I've been dev since I graduated. I had been everything else during my intern (dev, qa, test-automation developer, tools dev, build engineer, integration engineer, etc). Are you saying that Rails schema migration can only solve 10% of your migration needs? That kinda suck bro.

Migration tools are great once you stop changing the schema very often like it happens when a project starts. This of course depends on the project... if you can have a full design from the start, it's probably going to work too. If you don't know the exact requirements or way to get there - not so much.

If you don't know the requirements to the point that you can't even design a data structure for your project... A schemaless database is NOT going to save you.

Re: Failing with MongoDB

#29

Post by mrkurt »

hello_moto wrote: post #21
viraptor wrote: post #17

Earlier quoted context omitted.

Migration tools are great once you stop changing the schema very often like it happens when a project starts. This of course depends on the project... if you can have a full design from the start, it's probably going to work too. If you don't know the exact requirements or way to get there - not so much.

If you change your schema once every 2-3 days, something wrong with whomever leading the software project. That's like writing a software with zero planning or lack of knowledge for the problem domain. I don't care if it is a startup or not. Come up with a very simple idea, draw the models in ER diagram, implement that stuff. It's very hard to imagine that tomorrow suddenly all relationships need to be changed. Even…

Everything else in a software project changes frequently, especially during the early days. "Fundamentals" don't help you know more ahead of time and it's really nice to be able to quickly adjust when you come across something you hadn't anticipated.

I tried building a small side project with Postgres about 8 months ago (after not really doing rdbms stuff for 18 months before) and was amazed at how inflexible it felt, and how much frustration used to seem normal.

Re: Failing with MongoDB

#30

Post by FooBarWidget »

nomongo wrote: post #2

Why is a database that fails so easily and most of the time even loses data so popular? Is it really all just a huge marketing budget?

Not all data is important enough that small losses are unacceptable. Analytics data that can be inferred from other sources, for example. Furthermore MongoDB supports autosharding while most (all?) SQL databases do not.
Post reply on HN