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

71–80 of 128 posts

Re: Failing with MongoDB

#71

Post by hello_moto »

cperciva wrote: post #48
hello_moto wrote: post #23

Earlier quoted context omitted.

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

Yes. But I think asking happy users to donate ultimately produces better code than asking unhappy users to pay for support.

So true. So true. I wish happy users would donate more as well.

Unfortunately when happy users get used to the culture of free and good quality software, they started to have a sense of entitlement (instead of donating). That if the software didn't provide exactly what they wanted, they starting to swear and whine instead of being... calm and helpful.

Re: Failing with MongoDB

#72

Post by hello_moto »

jeltz wrote: post #37
cperciva wrote: post #15

Earlier quoted context omitted.

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

I am really happy that this does not exist in the PostgreSQL community despite many of the core developers being consultants who live off solving their clients' problems with PostgreSQL. Maybe this is because it is a community project with no single company in control of it.

Unfortunately solid software projects do not get much love these days.

SQLite. FreeBSD. OpenBSD. PostgreSQL. Python (there are some, but Ruby took the thunder).

Re: Failing with MongoDB

#73

Post by InclinedPlane »

rkalla wrote: post #59
InclinedPlane wrote: post #56

Earlier quoted context omitted.

So what's the preferred alternative noSQL wise? MongoDB is flaky. CouchDB is a maintainability nightmare, so I hear. Riak? Cassandra? Or does everything else have some other equally huge down-side?

They all have their warts. For every story like this, there are petabyte deployments of your favorite datastore that work fine. For every X sucks article, ther is Y is awesome. In the nosql world the only way to choose is around the problems they solve... They are each specializing and optimizing for certain nitches. mongo is the most mysql-esque, but dosnt do things that redis, couch or cassandra do that you may nee…

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.

Re: Failing with MongoDB

#74

Post by hammerdr »

hello_moto wrote: post #65
Joakal wrote: post #40

Earlier quoted context omitted.

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?

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 way of those migrations. People aren't looking at NoSQL just because they cannot sit still but instead are looking to find a better experience with handling data.

I'm not sure if NoSQL is the right answer to that but let's give it a chance and see what happens when people are migrating MongoDB data in 3-4 years.

[1] http://www.zdnet.com/blog/btl/technology-budgets-2010-mainte...

Re: Failing with MongoDB

#75

Post by einhverfr »

gojomo wrote: post #58

Maybe there's a niche for "PostgreNoSQL", a layer atop Postgres that you start using like a NoSQL solution. (Perhaps, it's string keys and JSON blob values.) It's not very efficient, except for simple keyed lookups, but it works enough for a quick start. Then, as you use it, the system optimizes itself (or makes suggestions) based on actual access patterns. A subset of objects could be a formal, indexed table? Have i…

hstore?

Re: Failing with MongoDB

#76

Post by einhverfr »

Devilboy wrote: post #6
hello_moto wrote: post #4

Earlier quoted context omitted.

There are tons of reasons for that. Let me pull some of them from my butt: Reason #1: Devs aren't Ops. Reason #2: Devs need something new on their resume. Reason #3: Certain type of Devs would read blogs and get excited and skipping scientific mumbo-jumbo and directly take the blogs as _the_ source of truth. Reason #4: It's easy to bootstrap (schemaless, etc) your weekend project. Dealing with DB apparently is tediou…

Right there with you. The excuses I hear for not wanting to use a good 'ole RDBMS just does not make sense to me sometimes. CREATE TABLE too hard? Time consuming? Difficult? Those who do not study the history of databases are doomed to repeat it. Soon we'll add back row-level write locks, transaction logging, schemas, multiple indexes and one day they wake up with MongoSQL.

First of all, RDBMS's are not perfect for all jobs. They have serious shortcomings in some areas (semi-structured and unstructured data for example)

A lot of other stuff can be stored in an RDBMS but isn't really optimal for it. Ideally hierarchical directory servers LDAP don't run directly off a relational db.

So there are places for other forms of stores, from BDB to XML, but these cannot and should not replace RDBMS's for most critical tasks.

(Also there is room for real improvement in certain areas of relational constraints in RDBMS's today, but NoSQL moves the wrong direction there.)

Re: Failing with MongoDB

#77

Post by _delirium »

jeltz wrote: post #37
cperciva wrote: post #15

Earlier quoted context omitted.

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

I am really happy that this does not exist in the PostgreSQL community despite many of the core developers being consultants who live off solving their clients' problems with PostgreSQL. Maybe this is because it is a community project with no single company in control of it.

It also started out as a research project, so for the first 10 years or so of its life, the main incentives for the developers were whether it was producing interesting research papers, rather than number of users.

Re: Failing with MongoDB

#78

Post by rkalla »

InclinedPlane wrote: post #73
rkalla wrote: post #59

Earlier quoted context omitted.

They all have their warts. For every story like this, there are petabyte deployments of your favorite datastore that work fine. For every X sucks article, ther is Y is awesome. In the nosql world the only way to choose is around the problems they solve... They are each specializing and optimizing for certain nitches. mongo is the most mysql-esque, but dosnt do things that redis, couch or cassandra do that you may nee…

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 the cool thing to do was store data different ways, now that we have all these solutions that people are ready to use in production, they are demanding more and more secure/safe functionality from them.

In the last year Redis added the append log and flushing to disk. CouchDB rewrote the replication code in the last release and has always had a wonderfully redundant and safe file mutation model (can can copy the DB file while in use and still get a safe snapshot) and MongoDB has been responding aggressively to crashes and corruption since 1.7 after all the single-server durability fiasco around 1.5/6 that had everyone up in arms.

These data stores are really brilliant pieces of code with some wonderful deployments to prove their worth.

There is still work to be done, sure, but I am not aware of glaring deficiencies in these systems like I used to be a year or more ago where you could point at "Oh, the XYZ bug might get you" -- that just doesn't seem to be happening anymore.

I don't know a whole hell of a lot about Cassandra (I am one of the few humans that still doesn't grok the data model easily) but I remember data recovery bugs from a year ago in the issue tracker that all got knocked out to the point that 1.x is looking like a really awesome release for them.

At this point, I think it just depends on what you need.

Re: Failing with MongoDB

#79

Post by fdr »

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?

It has a pretty good user experience, except for all the details. But the model isn't bad; it should be learned from. On the other hand, there is no trade-off made by Mongo that I'm aware of that is not fundamentally unavailable to more mature projects in a tractable amount of engineering time, so the question comes down to "does Mongo shed its reputation for lulz soon enough" vs "do other projects witness and adapt".

Yet we've also seen in the past that shedding such a reputation is not strictly required to be popular. And marketing budgets do matter.

Re: Failing with MongoDB

#80

Post by einhverfr »

viraptor wrote: post #10
hello_moto wrote: post #4

Earlier quoted context omitted.

There are tons of reasons for that. Let me pull some of them from my butt: Reason #1: Devs aren't Ops. Reason #2: Devs need something new on their resume. Reason #3: Certain type of Devs would read blogs and get excited and skipping scientific mumbo-jumbo and directly take the blogs as _the_ source of truth. Reason #4: It's easy to bootstrap (schemaless, etc) your weekend project. Dealing with DB apparently is tediou…

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…

"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 about it up-front."

I can sort of sympathize with this a little. I used to use MySQL for schema prototyping and then move stable stuff to PostgreSQL back when PostgreSQL lacked an alter table drop column capability.

However today, this is less of a factor. Good database engineering is engineering. It's a math intensive discipline. Today I work often with intelligent database design approaches, while trying to allow for agility in higher levels of the app.

Don't get me wrong, NoSQL is great for some things. However it is NEVER a replacement for a good RDBMS where this is needed.

Post reply on HN