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

NoSQL: Why it's So Damn Sticky

roadtofailure.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: NoSQL: Why it's So Damn Sticky

#31

Post by strlen »

mattmcknight wrote: post #19

It's a lot easier to get behind a no than a yes. As long as NoSQL is expressed as a negative, it's a very big tent. Even DBAs and relational model types have some complaints about SQL. As soon as it turns into "we're using Project Voldemort, can you figure out how to hook a reporting tool up to it tomorrow?", you find a lot less consensus.

Part of "NoSQL" is right tool for the job. You use a data warehouse for reporting which can be Hadoop+Hive/Pig or it can be a traditional OLAP solution e.g., Oracle DWH, you use Voldemort for low-latency serving. The two are differently problems. Even with an RDBMS, you shouldn't be using the same instance for reporting as you do for OLTP: that's what ETL and data warehousing are about.

I should add that HBase and Cassandra support integration with Hadoop and Hive/Pig, but all the usual warnings about the load of reporting jobs against a serving database apply-- one solution (with Cassandra) that I've heard is to place a the "reporting" machines on a different network e.g., on a different vlan in your own datacenter or in a different EC2 availability zone.

Re: NoSQL: Why it's So Damn Sticky

#32

Post by ntoshev »

Retric wrote: post #28
jbyers wrote: post #4

"Error establishing a database connection" Perfect.

Nahh perfect would have been if they hat stopped at: Technically, any database could support SQL as a language Or even added: , but what we are really talking about is half finished databases with limited capabilities that happen to suite a specific need. The reality is SQL is in no way a limitation on a database design, however by lowering the bar you can build a useful prototype which at some point might become a d…

They are not half finished databases (ok, some of them are), they are just databases that operate under a different set of constraints and optimize accordingly.

Re: NoSQL: Why it's So Damn Sticky

#34

Post by cturner »

daleharvey wrote: post #20
cturner wrote: post #13

AltDB and NoSQL are stupid labels. These names put people into the perspective of relational databases and then show them something totally different. The consumer then has difficulty understanding the topic. These labels bundle CouchDB into the same category as heavier-than-relational OO databases. A much better grouping label would be 'map cloud'.

I find "data stores" much easier to understand and isnt a loaded term.

That includes filesystems and RAM. And relational databases, which is something that the phrase needs to distinguish from.

Re: NoSQL: Why it's So Damn Sticky

#36

Post by gaius »

jbooth wrote: post #24
gaius wrote: post #18

Earlier quoted context omitted.

Well, there is also the widespread belief that "if MySQL doesn't do it, it's impossible for any RDBMS to". When people say "scalability" or "sharding" for instance, this is what they're complaining about.

Every single database sharding project I've seen has been a gigantic pile of workarounds and insanity, even if/when people got it to function properly. How about "if MySQL doesn't do it, then much more expensive databases might do it poorly after a whole bunch of effort"

How about "buying native support for partitioning and hash joins is cheaper than hacking it up in MySQL"?

I regularly work on DBs of 10s of teras with NO sharding or any of that nonsense.

Re: NoSQL: Why it's So Damn Sticky

#37

Post by RyanMcGreal »

cturner wrote: post #34
daleharvey wrote: post #20

Earlier quoted context omitted.

I find "data stores" much easier to understand and isnt a loaded term.

That includes filesystems and RAM. And relational databases, which is something that the phrase needs to distinguish from.

How about non-relational data stores?

Re: NoSQL: Why it's So Damn Sticky

#38

Post by cturner »

RyanMcGreal wrote: post #37
cturner wrote: post #34

Earlier quoted context omitted.

That includes filesystems and RAM. And relational databases, which is something that the phrase needs to distinguish from.

How about non-relational data stores ?

I thoughtfully offered response to your question here in my original comment above, before you'd posted your comment.

Re: NoSQL: Why it's So Damn Sticky

#39

Post by jbooth »

gaius wrote: post #36
jbooth wrote: post #24

Earlier quoted context omitted.

Every single database sharding project I've seen has been a gigantic pile of workarounds and insanity, even if/when people got it to function properly. How about "if MySQL doesn't do it, then much more expensive databases might do it poorly after a whole bunch of effort"

How about "buying native support for partitioning and hash joins is cheaper than hacking it up in MySQL"? I regularly work on DBs of 10s of teras with NO sharding or any of that nonsense.

How much does that cost? How does it compare to 40k for 10 commodity servers at 4k each and no license fees?
Post reply on HN