These articles are getting really fashionable lately, but the thing is that for many applications, a relational store is what fits your model. And RDBMS systems scale for most purposes. The things that don't scale are basically things that other systems don't have as features.
Key-value stores: you can only query by the key. So, you can say "give me article 7", but you can't say "give me articles by author 5". That's a huge limitation and doesn't allow you to make many applications. Now, key-value stores definitely have their place. For some purposes, they allow you to get better speed and scalability. However, I wouldn't want to be running my whole site off it alone.
Column based databases: these are wonderful for data warehousing and map-reduce like operations. However, that comes at a cost, namely random access. If your data is stored as 1,John;2,Adam;3,Samantha;4,Amanda you're easily able to grab all the columns for a person. However, if it's stored (as in a column database) as 1,2,3,4;John,Adam,Samantha,Amanda it becomes difficult to reconstitute a random row since the data isn't stored together. And what are you likely to be doing with your web application? Sure, I might want to analyze all the values in a column sometimes, but more often than not, I'm going to want to get the data for a row.
This isn't the end of the RDBMS. It's just more useful and a better tool for a lot of what we do. And we don't just have to use one tool. We can easily use key-value stores to supplement an RDBMS where the key-value store is a better tool - like caching. There's a reason that RDBMS systems are so widely used on high-profile sites including to power Facebook, Wikipedia, and WordPress.com (the 4th, 7th, and 20th most visited sites on the web worldwide). An RDBMS isn't the only tool they use, but it's good at data storage that needs to be accessed randomly. Sure, it needs to be supplemented by other techniques when you get to high volume so that operations that don't need an RDBMS don't use it, but there's a reason that Flickr, Craigslist, Twitter, Digg, LinkedIn, del.icio.us, LiveJournal, StumbleUpon, and many more of the largest sites use them.
I think the article is (as titled) about the end of _a_ era, not _the_ era. I don't think this article is saying the RDBMS is dead (the author works for Vertica, which I believe is a column-store RDBMS). He is saying that the era of the "row based physical model for everyone" era is over.
Ideally a RDBMS should have logical-physical seperation, and be able to support both row and column based stores (or any physical strategy at all) in the same DB. I think the author is just saying that the next stage on this path will have various competing RDBMS physical implementation strategies as they have such big performance impacts.
I don't think that these different storage method DBMS's are the end point, but a way point to RDBMS technology that can mix physical strategies while keeping the logical relational model intact.
Am I the only one who is getting tired of, "I found a new thing! The old thing is dead!"
Pretty much everything I've ever needed to do was easily accomplished with a DBMS with alternate indexing, either BTree or bitmap transaction. If I run into a jam, I'd be glad to take a look at additional options. I won't get rid of my DBMS any sooner than I'd get rid of my car just because of the advent of the personal helicopter.
Except here, the guy who is saying "the old thing is dead!" is one of the guys who invented the "old thing."
Stonebraker was among the first to implement a functioning relational database, and I don't think you can underestimate the importance of the Ingres papers to the field.
He's marketing his variations on the RDBMS - Vertica/C-Store, VoltDB & SciDB. Twelve years ago he was talking about Object Relational databases supplanting the RDBMS.
Are the new non-SQL databases agile? As my users require new ways to query and glean information from the data, will they grow with it? I'm not sure. What if down the road my users want to perform join-like behavior, aggregates and other things that SQL does so well?
10 comments
[ 2.9 ms ] story [ 45.9 ms ] threadKey-value stores: you can only query by the key. So, you can say "give me article 7", but you can't say "give me articles by author 5". That's a huge limitation and doesn't allow you to make many applications. Now, key-value stores definitely have their place. For some purposes, they allow you to get better speed and scalability. However, I wouldn't want to be running my whole site off it alone.
Column based databases: these are wonderful for data warehousing and map-reduce like operations. However, that comes at a cost, namely random access. If your data is stored as 1,John;2,Adam;3,Samantha;4,Amanda you're easily able to grab all the columns for a person. However, if it's stored (as in a column database) as 1,2,3,4;John,Adam,Samantha,Amanda it becomes difficult to reconstitute a random row since the data isn't stored together. And what are you likely to be doing with your web application? Sure, I might want to analyze all the values in a column sometimes, but more often than not, I'm going to want to get the data for a row.
This isn't the end of the RDBMS. It's just more useful and a better tool for a lot of what we do. And we don't just have to use one tool. We can easily use key-value stores to supplement an RDBMS where the key-value store is a better tool - like caching. There's a reason that RDBMS systems are so widely used on high-profile sites including to power Facebook, Wikipedia, and WordPress.com (the 4th, 7th, and 20th most visited sites on the web worldwide). An RDBMS isn't the only tool they use, but it's good at data storage that needs to be accessed randomly. Sure, it needs to be supplemented by other techniques when you get to high volume so that operations that don't need an RDBMS don't use it, but there's a reason that Flickr, Craigslist, Twitter, Digg, LinkedIn, del.icio.us, LiveJournal, StumbleUpon, and many more of the largest sites use them.
Ideally a RDBMS should have logical-physical seperation, and be able to support both row and column based stores (or any physical strategy at all) in the same DB. I think the author is just saying that the next stage on this path will have various competing RDBMS physical implementation strategies as they have such big performance impacts.
I don't think that these different storage method DBMS's are the end point, but a way point to RDBMS technology that can mix physical strategies while keeping the logical relational model intact.
Am I the only one who is getting tired of, "I found a new thing! The old thing is dead!"
Pretty much everything I've ever needed to do was easily accomplished with a DBMS with alternate indexing, either BTree or bitmap transaction. If I run into a jam, I'd be glad to take a look at additional options. I won't get rid of my DBMS any sooner than I'd get rid of my car just because of the advent of the personal helicopter.
Except here, the guy who is saying "the old thing is dead!" is one of the guys who invented the "old thing."
Stonebraker was among the first to implement a functioning relational database, and I don't think you can underestimate the importance of the Ingres papers to the field.
RDBMS era will never end as long as corporations need to store data efficiently.
Most web pages don't need the power of a RDBMS and they go well enough with whatever is fashionable.
An invoice is a row, a purchase order is a row, an employee paycheck is a row, a product is a row, etc.