SQL vs. NoSQL

http://www.linuxjournal.com/article/10770?page=0,0

by namuorg • 14 years ago

78 44 14 years ago

linuxjournal.com

stevencorona4• 14 years ago

stopped reading the articled referred to amazon s3 a database. instant credibility killer. no thanks.

(p.s the amazon product you're looking for is dynamo)

genwin• 14 years ago

What prevents S3 from being used as a highly scalable NoSQL key-value store?

agilord3• 14 years ago

latency (and costs)

randomdata• 14 years ago

I have read a few posts over the years of people using s3 for exactly that. I don't have specific links anymore, but a Google search turned up an example: http://petewarden.typepad.com/searchbrowser/2010/10/how-i-en...

SeoxyS• 14 years ago

S3 has been around for a much longer time than Dynamo has been. Dynamo is a very recent introduction by Amazon. In fact, Dynamo did not even exist when this article was published. (Dynamo came out early '12, the article is from '10).

And when you think about it, S3 is just a massive distributed key-value store with simple key querying and an HTTP api.

stevencorona4• 14 years ago

Amazon's Dyanmo Whitepaper is from 2007, they have used it internally for a long time- it was inspired by BigTable.. not S3.

Source: http://www.allthingsdistributed.com/files/amazon-dynamo-sosp...

jedberg5• 14 years ago

I think you're the one who is mistaken. Amazon has multiple database products. S3 is one of them. In fact, some of the folks who developed S3 also developed BigTable for Google.

Dynamo is a new database product they have that is also a key value store.

stevencorona4• 14 years ago

Dynamo is not a new database product. Sure, their SaaS offering is new, but Dynamo has been used internally at Amazon since atleast 2007, when they published a whitepaper on it. Dynamo was inspired by BigTable.

Sure, when you break it down S3 is just a big key-value store, but Dynamo is a much closer comparison to BigTable.

http://www.allthingsdistributed.com/files/amazon-dynamo-sosp...

ndemoor• 14 years ago

S3 is also used as intermediary data storage when running Elastic MapReduce queries over data in your DynamoDB tables.

http://aws.typepad.com/aws/2012/01/aws-howto-using-amazon-el...

elchief• 14 years ago

I don't really get why HBase isn't bigger than it is. I mean, it's BigTable, right? And Facebook dropped Cassandra for it, IIRC.

Not trying to start a war here, I am not an interested party, I am just curious.

stevencorona4• 14 years ago

cassandra is a really solid product. it's actively developed and very stable.

from what i understand, facebook move to hbase for their messaging platform- which makes sense. cassandra's consistency model is weaker than hbase, and an eventually consistent model doesn't make sense for a real-time messaging platform.

heretohelp2• 14 years ago

Actually, eventual consistency for their messaging product makes a ton of sense, because any changes to states are a "push", so any "eventual consistency" is just messaging latency/propagation delay.

That aside, you don't appear to be familiar with how messaging got built.

It was built by a large team of Hadoop people, HBase was simply what they knew, there was no conscious decision to snub Cassandra beyond the fact that it wouldn't have leveraged their extensive HDFS experience.

Furthermore, it's trivial to tune the consistency levels in Cassandra to your needs, so there's no real reason to not use Cassandra just because of a "lack of consistency". Just use ALL or QUORUM, jesus.

erichocean3• 14 years ago

cassandra's consistency model is weaker than hbase

This is simply not true. What is true is that Cassandra supports weaker consistency models than hbase in addition to the strong consistency model that hbase supports (and in fact, requires -- you can't turn it off).

Hbase has it's place, but "consistency" isn't a good reason to pick Hbase over Cassandra. Rather, particular workloads can (currently) be done faster in Hbase than Cassandra, due to locality assumptions with how writes are done in Hbase, and the nature of those writes.

jedberg5• 14 years ago

Mostly because it doesn't seem to have a very vocal community behind it.

It is a really solid product, and some folks have built their entire business on it.

It's also used a lot in enterprise setups, but again, those folks don't typically go around talking about it.

Since it isn't a hot new trend, it stays off the radar of a lot of "startup" folks.

erichocean3• 14 years ago

Also, the overhead of Hbase for a small install is pretty high, whereas a single-node Cassandra cluster is extremely easy to set up.

There's no such thing as a single-node Hbase cluster, since it involves, at the very least, setting up Zookeeper.

This keeps Hbase out of the hands of tire kickers.

rck• 14 years ago

I think part of the issue might be that HBase is designed for lots of data. The architecture overview says that if you only have a few thousand or million rows, then a relational database may be a better choice:

http://hbase.apache.org/book/architecture.html#arch.overview...

Even if you plan on scaling to billions of rows of data, it may be easier to start with something else that works well for smaller data sets.

dj2stein9• 14 years ago

Only a fraction of companies can ever really outgrow the capabilities of a fully tuned RDMS. And only a fraction of those will choose HBase over its competitors. And so only people who have worked for such companies have any real experience with the product... and only a fraction of those are vocal about it on the internet.

MartinCron• 14 years ago

It's like the Drake Equation for word-of-mouth.

3amOpsGuy3• 14 years ago

I agree with what you say, but I think we also need to consider cost as well as capability of the underlying product.

Introducing cost massively changes how that equation stacks up.

"How many tps can I run given a budget in the form of these 6 available servers". Well the boxes are under spec for what you want to achieve with an RDBMS, but yeah no problem with XXX nosql product.

3amOpsGuy3• 14 years ago

>> Facebook dropped Cassandra for it

I guess there's a bit more to it than that. I understand the fb employees that took over were Hadoop guys so it made complete sense for fb to go in that direction.

The bit I don't get is why is hbase still a bit of a turtle. For example a recent paper linked to from here had random read and write workload running at 180k ops / sec on a 6 node Cassandra cluster but only 20k ops / sec for the same workload on hbase.

Lasher2• 14 years ago

Interesting that one of the original "noSQL" databases that is still going strong today, Pick and its variants, was not mentioned in the article at all.

Universe and JBase are both well supported on Linux and there are several multi-billion dollar (revenue) companies running their core business on it - I work for one of them.

itcmcgrath• 14 years ago

Both UniVerse and UniData are equally well supported on Windows, Unix and Linux. They have some interesting features that are still reasonably unique in the database world. E.g. Built-in transparent record encryption, including both key & index. http://2012.nosql-matters.org/cgn/wp-content/uploads/2012/06... Full disclosure: I'm the product manager for the databases.

Lasher2• 14 years ago

You're probably familiar with the Eclipse distribution management package then (not to be confused with the IDE), that's the app I was referring to. I've been using Universe since the Vmark days, ADDS Mentor and Sequoia before that. Pick type databases are sadly under-rated. Possibly because there's never really been any kind of marketing aimed at indy developers and/or students?

badclient• 14 years ago

I am presently researching these so-called NoSQL databases and one thing that I keep wondering is why can't all of these database still support a limited form of SQL-like language?

Almost any json document could be represented as a db table as far as I can see. Why can't I query using a common language instead of learning each of these NoSQL database's own way of doing simple stuff like returning documents of User object that have a gender field value as 'male'. In SQL, it would be something like "select * from users where gender='male". Why can't NoSQL databases support a query similar to that? Why do they require me to describe a similar request in their own unique syntax?

I sometimes get the feeling that coining a term like NoSQL is a marketing gimmick which hurts people actually trying to learn the nuanced differences but I am only getting started. Why can't we extend SQL to support "NoSQL"-specific cases instead of replacing it with nothing.

I get that a big part of SQL is joins and the philosophy of joins goes against the idea of NoSQL. The solution to that is to still accept SQL but just throw an exception when join is used with a link to educate the person on alternative implementations.

almost• 14 years ago

I believe some do offer SQL-like query languages.

But if all you support is lookup by key, or even just lookup by field, then SQL really isn't that useful in my opinion. And if your lookups are based on map-reduces that have to be pre-specified then I can't see any place for an SQL-like language at all.

SQL is ok for specify queries to relational databases, but I don't think it generalises to any type of store apart from maybe the very basics. And at that point what benefit are you getting appart from a slight, and misleading, sense of familiarity?

3amOpsGuy3• 14 years ago

Yeah Cassandra has CQL and it works pretty well, it's comfortable to use where the cassandra-cli is quite painful for anything other than the very beginning of a project.

I believe in earlier releases CQL was slower but now it seems fine. Also the most popular Cassandra client, hector, supports CQL, adopting CQL should be possible for a lot of Cassandra use cases.

4ad• 14 years ago

Disclaimer: I'm not a DB person, so take everything I say with a grain of salt.

I only used a few SQL and NoSQL products and have done it from statically compiled languages. The immediate benefit I perceived when using language constructs instead of SQL was type safety and compile time validation of the query. I hate the chained function calls, I find SQL easier to read, but I would not trade the type safety for a more pleasant syntax.

vampirechicken• 14 years ago

Joins are in SQL because SQL was developed to query relational databases, and the join is the fundamental assumption of the relational database.

I always find it sad that the new data storage engines define themselves under a banner that says "We don't care that everybody who learned how to query a database since 1988 needs to learn a new way because our way is better." Which wouldn't be so bad if it was uniform across engines, but it isn't. It's a new API for each engine.

That's a lot of yaks to shave when you already know SQL.

erichocean3• 14 years ago

> In SQL, it would be something like "select * from users where gender='male". Why can't NoSQL databases support a query similar to that?

They can and they do, e.g. Cassandra and CQL, which syntactically is the SQL you requested.

VLM• 14 years ago

A NoSQL discussion isn't complete without a link to the inner platform effect

http://en.wikipedia.org/wiki/Inner-platform_effect

Basically if your application domain is inherently relational or inherently "SQL" no "NoSQL", then building your own RDBMS in your application absolutely dooms you, unless you're not a "real" application writer but actually a RDBMS author.

I have having a conversation with a guy "I wish there was a library for (whatever nosql DB he was complaining about) I could link in to do transactions and indexing for me" my reply "yeah, its called postgresql". That's not trendy and buzzword compliant, he ended up annoyed with me. There's a "pragmatic programming" book "seven databases in seven days" which is a pretty good book and it describes polyglot database design a little toward the end... so you "need" a key-value store and indexed transactions and there's nothing that does both perfectly... Well, there's plenty of good free open source DBs, so install and use two DBs... its really not that hard.

agbell• 14 years ago

Found it: ( I hope its as good as the 7 languages one ):

http://pragprog.com/book/rwdata/seven-databases-in-seven-wee...

SQL vs. NoSQL

Related Stories