The End of a DBMS Era (Might be Upon Us)
cacm.acm.org
cacm.acm.org
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.
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.