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

81–90 of 128 posts

Re: Failing with MongoDB

#81

Post by einhverfr »

zzzeek wrote: post #20
viraptor wrote: post #10

Earlier quoted context omitted.

Why do I get the feeling that you're an op and look down on development people? If that's really true, try to start developing some project and see how you like frequent schema changes, trying to synchronise schemas with peers, resolving relation issues when merging features, etc. On the other hand if you abstract your interaction with data enough, you can change the whole backend later once it's stable and not care…

> On the other hand if you abstract your interaction with data enough, you can change the whole backend later once it's stable and not care about it up-front. have to disagree with this. By forcing yourself to work with a data layer so abstracted that you can't even reference whether you're dealing with a JSON document or a set of twelve joinable tables, you're going to write the most tortured and inefficient applica…

And you lose the ability to do data constraints well. Put clearly: Declarative data constraints (including referential integrity, but also check constraints and the like) are the single most important features of RDBMS's for most applications.......

Re: Failing with MongoDB

#82

Post by olefoo »

rkalla wrote: post #60
jethroalias97 wrote: post #22

Earlier quoted context omitted.

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.

It isnt packaged and marketed as cleanly. It takes hunting and learning on your own to get good with couch, and map reduce is no where as easy to get started with as mongo queries (although the addition of unql may improve things next year). Also there is no single, central steward and authority on couch. All of this stymies traction and confidence even though the tech is great.

Which all sounds rather like Postgres. It's harder to use because you have to know what you're doing, and it's not as popular even though it's better on some axes that are significant if you're building something solid.

Re: Failing with MongoDB

#83

Post by andrewflnr »

rkalla wrote: post #78
InclinedPlane wrote: post #73

Earlier quoted context omitted.

Have there been any new entrants in the last few years? Seems like innovation has stalled a bit and stabilization / improvement hasn't caught up yet.

Good question -- as far as new, mature NoSQL solutions on the scene, I just became aware of OrientDB which sort of baffles me with it's functionality. It looks like this amazingly functional blend of MySQL and NoSQL: http://www.orientechnologies.com/orient-db.htm Other than that, I actually think these solutions have been stabilizing exactly because of what you say: innovation is slowing down/stalling. 1-3 years ago…

Orient looks cool. Thanks for the tip. It doesn't look like it will support any other languages though (like Python), which stinks.

Re: Failing with MongoDB

#84

Post by einhverfr »

mrkurt wrote: post #29
hello_moto wrote: post #21

Earlier quoted context omitted.

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…

That's what prototyping and peer review are for,

I write up a schema, send to everyone else on the team, get feedback. If users are invovled get it from them too.... take in all the feedback, write up a new draft, wash, rinse, repeat until running out of shampoo (i.e. feedback).....

Once things are pretty stable, do a prototype, address any oversights, do the real thing.

It's not rocket science.

Re: Failing with MongoDB

#85

Post by jethroalias97 »

rkalla wrote: post #60
jethroalias97 wrote: post #22

Earlier quoted context omitted.

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.

It isnt packaged and marketed as cleanly. It takes hunting and learning on your own to get good with couch, and map reduce is no where as easy to get started with as mongo queries (although the addition of unql may improve things next year). Also there is no single, central steward and authority on couch. All of this stymies traction and confidence even though the tech is great.

This is true. I think couchdb tries to be all things to all people rather than just focusing on being a great data store. It's a database like mongo, it's a mobile database like sqlite, you can use it to host apps with couchapp, you can use it as a map-reduce cluster like hadoop, etc. I would rather have just a solid no-sql database that solves that problem. I like couch better than mongo for the reasons I mentioned, but I know couch also has problems and still haven't found a good third option.

Re: Failing with MongoDB

#87

Post by LeafStorm »

ehthere wrote: post #50
mnutt wrote: post #44

Earlier quoted context omitted.

You say that like it's a failure on the devs' part, but that's kind of like blaming regular users for not switching to Linux because they don't like editing network configuration files.* It's masking the problem that there are real developer-friendliness issues with the existing databases. And taunting users will not get them to switch back. * but then Linux distros get network autoconfiguration and suddenly it's obv…

Every major RDBMS has both command-line and GUI interfaces to create and change schemas. What exactly is missing in the dev-friendlyness department?

The effort required to get something like Postgres running in the first place. With Redis and CouchDB, it's juts `sudo pacman -S redis|couchdb`, maybe edit the config file, `sudo rc.d start redis|couchdb`. With Postgres you have to create databases, users, etc. etc. While all this stuff is critical in production, it's really not something that you should have to do to just code some stuff.

Re: Failing with MongoDB

#88

Post by einhverfr »

Joakal wrote: post #40
hello_moto wrote: post #21

Earlier quoted context omitted.

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…

As a startup, change of minds is pretty normal to the point that it's far more better to have the tools to quickly implement it rather than plan/document it well. The only documentation is the general gist behind the database. If it prototypes well, then further refine it with ER diagrams for future maintenance. Why is planning everything without validation better than above?

Disagree here. Figure an hour of planning saves 10 hrs dev time and 100 hrs bugfixing.

That doesn't mean spending months planning. It does mean doing your best to plan over a few days, then prototype, review, and start implementing. If things change, you now have a clearer idea of the issues and can better address them.

The worst thing you can do is go into development both blind and without important tools you need to make sure that requirements are met--- tools like check constraints, referential integrity, and the like.

Re: Failing with MongoDB

#89

Post by einhverfr »

hammerdr wrote: post #74
hello_moto wrote: post #65

Earlier quoted context omitted.

small to medium changes? find a better migration tools. large changes? throw away and start over; tools like Rails can help you get up and running really quickly. I rarely see people go back and fix the mess.

To be frank, you're talking out of your ass. Maintenance takes up about 50% of all IT budget [1]. Most individual pieces of software will spend 2-6 times (considering the average life cycle of an in production software product to be 2-4 years) more money on being maintained than being developed. Data migration is a massive problem for any organization with data sets at any scale. RDBMS, in general, has gotten in the…

Integration issues are best handled with good API's. Migration issues are a bigger issue but one thing that good use of RDBMS's give you is the ability to ensure your migrated data is meaningful. Not sure you can do that with KVM-type stores.

Re: Failing with MongoDB

#90

Post by nakkiel »

LeafStorm wrote: post #87
ehthere wrote: post #50

Earlier quoted context omitted.

Every major RDBMS has both command-line and GUI interfaces to create and change schemas. What exactly is missing in the dev-friendlyness department?

The effort required to get something like Postgres running in the first place. With Redis and CouchDB, it's juts `sudo pacman -S redis|couchdb`, maybe edit the config file, `sudo rc.d start redis|couchdb`. With Postgres you have to create databases, users, etc. etc. While all this stuff is critical in production, it's really not something that you should have to do to just code some stuff.

Well, this is completely bogus. Setting up a new user on PostgreSQL takes me roughly 30 seconds. Now if you use the stock system-db user mapping for dev environment, it's something you do only when you install your system. Mine has been installed for 3 years now.
Post reply on HN