×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Is the Relational Database Doomed?

ScuttleMonkey posted more than 5 years ago | from the just-more-tools-in-the-bucket dept.

Databases 344

DB Guy writes "There's an article over on Read Write Web about what the future of relational databases looks like when faced with new challenges to its dominance from key/value stores, such as SimpleDB, CouchDB, Project Voldemort and BigTable. The conclusion suggests that relational databases and key value stores aren't really mutually exclusive and instead are different tools for different requirements."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

344 comments

Gosh, I wish I could answer this question (-1, Offtopic)

Gizzmonic (412910) | more than 5 years ago | (#26849363)

But I really don't know anything about databases! Why don't you ask me about the history of the World Wide Wrestling Federation? I know a lot more about Big John Studd, the Hulkster, and (my favorite) Macho Man Randy Savage! He'll beat your database in a best of 3 falls match at SummerSlam! OH YEAH!

new record (5, Interesting)

hguorbray (967940) | more than 5 years ago | (#26849365)

that's efficient -a summary that refutes the inflammatory headline

I'm just sayin'

Re:new record (4, Funny)

Jah-Wren Ryel (80510) | more than 5 years ago | (#26849477)

Yeaah. Only if you did not know the meaning of the '?' symbol.

Re:new record (4, Insightful)

bFusion (1433853) | more than 5 years ago | (#26849547)

Well the '?' means that there's a question. The summary gave the conclusion to that question.

?'s meaning - literal and implied (5, Insightful)

qbzzt (11136) | more than 5 years ago | (#26849859)

In headlines, "?" implies that something is a serious question, whose answer is likely to be yes. One that makes it worth spending the time to read the article.

Imagine the headline said "Does Obama Smoke Crack?" and the article had a bunch of stuff about the president, with a last paragraph saying: "There is absolutely no reason to thing that President Obama has ever smoked crack."

Re:?'s meaning - literal and implied (0)

Anonymous Coward | more than 5 years ago | (#26850257)

In headlines, "?" implies that something is a serious question, whose answer is likely to be yes. One that makes it worth spending the time to read the article.

You seem to be implying that all those things are false about the article. Yet after reading the article it is quite apparent that your implication is incorrect.

Re:?'s meaning - literal and implied (1)

qbzzt (11136) | more than 5 years ago | (#26850479)

You're right - I should have used "summary" instead of "article", since the headline was the headline for the slashdot summary.

Re:?'s meaning - literal and implied (4, Insightful)

digitig (1056110) | more than 5 years ago | (#26850485)

In headlines, "?" implies that something is a sensationalized question, whose answer is "almost certainly, no".

Fixed that for ya.

Re:?'s meaning - literal and implied (0, Offtopic)

rthille (8526) | more than 5 years ago | (#26850529)

Welcome to the post FauxNews world, where questions like:
Obama a Muslim?
Obama a Socialist?
George W. Bush Great President or Greatest President?

Are the height of journalistic integrity!

Re:new record (0, Troll)

Anonymous Coward | more than 5 years ago | (#26849559)

Next Slashdot article: Is Jah-Wren Ryel a child molester?

Re:new record (4, Funny)

eln (21727) | more than 5 years ago | (#26850135)

Next Slashdot article: Is Jah-Wren Ryel a child molester?

There's no evidence Jah-Wren Ryel has ever molested children, and no reason to suspect he would ever do so. Bandying about accusations like that would likely ruin his life forever.

However, since child molestation is such a big political issue these days, as a responsible news site I believe we need to have equal representation from both sides of the argument and let our viewers decide.

Is the flat file doomed? (1, Funny)

Anonymous Coward | more than 5 years ago | (#26850023)

You should have seen how quickly flat file usage flatlined when relational databases came out. I mean *nobody* uses plain text files anymore. Can you imagine not having your crontabs in a SQL DB?

Re:new record (5, Funny)

julesh (229690) | more than 5 years ago | (#26850099)

that's efficient -a summary that refutes the inflammatory headline

I'm just sayin'

Nah. Efficient would be if the summary were "No."

Here's a match.. (3, Interesting)

Slicker (102588) | more than 5 years ago | (#26850277)

Relational databases need to die. I loved them and preached the goodness of them 10 years ago, but they are just too rigid for contemporary needs. I've learned better ways of organizing and filtering data.. but the old RDBMS school is too canonical (stubborn) and self-indulging to realize that needs are changing and their model doesn't fit.

We need efficient attribute/value models. We need to stop referencing data by where it is and start referencing it by what it is. There is too much data that needs to exist in different views, based on policy--not explicit placement.

Dumb-tags (attributes without values) like those used with Delicious bookmarks are also broken. They are too vague.

My own approach is that every attribute may have any number of value instances. Each value instance may, in turn, have sub-attributes. So you can look up data based on its characteristics even with disregard for its name. For example: /mycompany/mailserver1/ip of zone = infirewall

This returns all IP addresses under the "zone" attribute while also under the mailserver1 attribute that is under the mycompany attribute.

When validating instances of the "ip" attribute, it looks backward in the path because it is extremely quick that way.

The data server's sole responsibility is storing and retrieving information (not just data) in context (aka filtering).

Sorting is the responsibility of the client. This makes sense because there are an infinite number of algorithms one could have for sorting data (e.g. alphabetic mixed case, ASCII order, etc). To facilitate this, I wrote a method to return the number of values that would be returned if the values were requested. If too big a bite for the client, it can re-request the size of a smaller chunk, segmented according to the client's ordering method. This is useful for scale, in any case. Processing in chunks makes sense whether over a network of limited capacity or from directly form disk with limited memory.

And--this is a columnar approach like Google's BigTable is.. That means you get 10+ times faster read performance.

Matthew

Re:new record (0)

Anonymous Coward | more than 5 years ago | (#26850293)

It's a story posted by ScuttleMonkey. Did you actually expect him to do a good job? He's probably one of the worst editors on here...

WTF? (1)

E IS mC(Square) (721736) | more than 5 years ago | (#26849381)

Headline: Is the Relational Database Doomed?

Summary: "The conclusion being that relational databases and key value stores aren't really mutually exclusive and instead are different tools for different requirements."

WTF?

Re:WTF? seconded (1)

patiodragon (920102) | more than 5 years ago | (#26850385)

As long as there is data that is related, I predict a form of relational database.

Genius! I know, pure genius.

Re:WTF? (2, Insightful)

Lord Ender (156273) | more than 5 years ago | (#26850401)

If "key/value" databases do become more popular, they certainly might eat in to relational database mindshare. 90% of web applications use RDMSs merely as persistent data storage--the fact that they are "relational" doesn't matter at all; the fact that a separate SQL language is needed to get the data (rather than using language-native data structures as an interface) is even a negative for RDMs.

As a web app developer, I'm excited that something other than SQL is getting attention. RDMSs won't go away because they have properties data miners, for example, need. But they aren't ideal for the simple persistent data stores most apps call for.

Yes, but not soon. (3, Interesting)

pwnies (1034518) | more than 5 years ago | (#26849419)

The flexibility offered in key/value databases is simply too good of a feature to pass up. However, do you really think you can get people to give up MSSQL? It'll be nice for smaller projects, but corporations wont even consider it for a number of years.

Re:Yes, but not soon. (3, Interesting)

SanityInAnarchy (655584) | more than 5 years ago | (#26849503)

do you really think you can get people to give up MSSQL?

In favor of MySQL, PostgreSQL, SQLite, even Oracle, yes, I do.

corporations wont even consider it for a number of years.

You must have some specific corporations in mind, because I've known many corporations to use each of the above technologies. In fact, SQLite is one of the most popular databases ever.

No, the reason it's not soon is because these other ones (CouchDB) aren't mature, and the ones that are (BigTable) aren't available at any price.

Re:Yes, but not soon. (1, Funny)

Anonymous Coward | more than 5 years ago | (#26849969)

Sleepycat made a good key/value pair database but that isn't what we're talking about.

Re:Yes, but not soon. (5, Informative)

Eravnrekaree (467752) | more than 5 years ago | (#26850223)

Actually i read TFA, and I just couldnt make sense of the benefits offered by the key value thing. You basically should be able to get the same benefits with a relational database system with a query that does a lookup on a single column index. This would involve searching the b-tree for that column, which would yield a row data address of some sort, to either a linked list of cells or a list of addresses of those cells. Once the single b-tree is done it is then very fast to find the other column values in that row. The b-tree or other index lookup also has to be done with the key value pair, the relational is just a collection of multiple key value indexes.

There is the issue of having a variable number of pieces of data linked to a certain key. But you can do this in relational too. Just create a table with an id column, value type column and value column. A well designed relational, if you do a query on the id column, the b-tree will lead to data which has all of the row data addresses in the database that match the id. EAch of those rows will contain a different data type/data payload for the id. This is again pretty much as fast as a simple single index database.

No (1)

Azarael (896715) | more than 5 years ago | (#26849425)

It isn't up for debate that tupple stores are a very useful tool. That being said, they aren't a silver bullet for *ALL* data storage situations. For types of data that are inherently tabular, I really doubt that 40 years of RDBMS development will be trumped by a tuple store. When you move to hierarchical data though, things are reversed.

Karma Whoring (-1, Troll)

jgtg32a (1173373) | more than 5 years ago | (#26849427)

Re:Karma Whoring (2, Insightful)

Anonymous Coward | more than 5 years ago | (#26849529)

This isn't digg. Posting that doesn't guarantee you +5

Re:Karma Whoring (0)

Anonymous Coward | more than 5 years ago | (#26849899)

This is.

What you need here is a quote from Monty Python. It always gets the poster a +5 here. (Yes, it's not Karma whoring due to funny mods not contributing but I would assume funny was what GP was after too). And XKCD strips are very common ways to get +5 too. As are bash.org quotes. And those are just +5 funnies. I could count a lot of ways to get nearly certain insightful mods on any Linux related article, etc...

So get rid of your elitism. There are a lot of stupid mods here, too.

Top 25 Reasons the Relational Database is Doomed (5, Funny)

MillionthMonkey (240664) | more than 5 years ago | (#26849433)

Someone type this up and submit it to Digg.

Re:Top 25 Reasons the Relational Database is Doome (0)

Anonymous Coward | more than 5 years ago | (#26850307)

This is slashdot, it was on digg a week ago and reddit a week before that.

Hey! (4, Insightful)

MightyMartian (840721) | more than 5 years ago | (#26849453)

Hey, read my article! Just to make sure you do, I'll pull a Dvorak and put in some incredibly sensational headline about how RDBMs are dewmed!!!!!! BWAHAHA, feed my advertisers!!!!

(Tune in ext week, when I write about how C programming is going to become extinct in the light of fantastic new development tools like C# and Ruby on Rails!!!)

Re:Hey! (5, Insightful)

dkleinsc (563838) | more than 5 years ago | (#26849567)

Especially when the claim is as ridiculous as this one.

There's a reason relational databases took over the world of databases: They provide a good combination of flexibility and structure to efficiently represent data. Which is what databases are supposed to do.

Re:Hey! (5, Insightful)

Just Some Guy (3352) | more than 5 years ago | (#26850065)

There's a reason relational databases took over the world of databases: They provide a good combination of flexibility and structure to efficiently represent data.

Especially since so many databases really are inherently relational. The textbook example of 1-customer:n-invoices, 1-invoice:n-items plays out quite a bit in the workplace.

Free Traffic (1)

nurb432 (527695) | more than 5 years ago | (#26849695)

And people complain that i don't go read the articles and rely on summaries.

This is one of the reasons.

Completely off topic (0)

Anonymous Coward | more than 5 years ago | (#26849485)

Is anyone else experiencing a long delay when loading the Slashdot homepage, like a couple of seconds during which the browser is unresponsive? I'd like to know if there's something I can do about it besides blocking the offending script and reducing Slashdot to an unusable shadow of itself. I don't intend to dive into 400 KBytes (!) of minified Javascript code to find what the hell it is doing.

Re:Completely off topic (0)

Anonymous Coward | more than 5 years ago | (#26849627)

I find it blocks on network a fair bit before showing the headlines - 'waiting for images.slashdot.org' etc.

Voldemort! (3, Funny)

GreatRedShark (880833) | more than 5 years ago | (#26849553)

There's a db called Project Voldemort? That's awesome! I'm switching to that just for the name! I think my manager is a Harry Potter fan so getting approval shouldn't be too hard.

Re:Voldemort! (4, Funny)

youthoftoday (975074) | more than 5 years ago | (#26849613)

A Harry Potter fan? Voldemort? Surely the name is the one thing that'll *prevent* approval?

Re:Voldemort! (4, Funny)

the_B0fh (208483) | more than 5 years ago | (#26849791)

**SPOILER ALERT**

In book 8, it turns out that good ol' Voldy is actually Harry's older brother. They had a tearful reunion, and Voldy now works for Harry.

Re:Voldemort! (1)

MightyMartian (840721) | more than 5 years ago | (#26849889)

Nah, in book 8, Voldemort returns, lops of Harry's hand in a big fight scene, then tells Harry that he's really his father. In book 9, Harry gets mad at Dumbledore's animated picture for deceiving him, to which Dumbledore admits "Tom Riddle was my friend, when I first knew him he was already a great Quidditch player, but I was amazed by how strong the magic was in him."

Re:Voldemort! (5, Funny)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#26849641)

The name might be cool; but the length of some of the commands will really get to you. How many times do you want to type AVADA_KEDAVRA TABLE?

Re:Voldemort! (1)

hansamurai (907719) | more than 5 years ago | (#26849825)

CREATE_TABLE customer_balance (
id INTEGER AUTO_INCREMENT,
balance WINGUARDIUM_LEVIOSA,
PRIMARY KEY (id)
);

Re:Voldemort! (1)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#26849961)

Be careful, if we keep this up, we'll enjoy the honor and/or terrible burning shame of having defined the official backend database for Lolcode [lolcode.com] applications.

Re:Voldemort! (5, Funny)

jollyreaper (513215) | more than 5 years ago | (#26849945)

The name might be cool; but the length of some of the commands will really get to you. How many times do you want to type AVADA_KEDAVRA TABLE?

Better than PokemonDB. Then you have to jump on top of your desk and shout "Customer Table, I select you!" every time you run a damn query.

Re:Voldemort! (1)

Palshife (60519) | more than 5 years ago | (#26850101)

Well, considering that the database process dies as soon as you type it, you only have to type it once.

Enough with the death of the relational DB (5, Interesting)

Mr. Underbridge (666784) | more than 5 years ago | (#26849561)

This same basic story keeps getting submitted from the same group of people who are generally trying to sell non-relational-DB stuff. This is an ad. Move along.

Re:Enough with the death of the relational DB (0)

Anonymous Coward | more than 5 years ago | (#26850091)

Yes, this is crap. The same thing was said 10 years ago (if anybody remembers that long ago) about XML. XML was going to replace RDBMSes. Didn't happen.

Re:Enough with the death of the relational DB (0)

Anonymous Coward | more than 5 years ago | (#26850333)

If it's actually useful and gets some media coverage, then oracle, mssql and others will add support for it, and all the original developers will be SOL.

In my mind KVP stores seem to be a sop for the modern cheap HashMap-wielding programmer who can't even grok objects and relationship models.

99.9% of databases... (3, Interesting)

Ckwop (707653) | more than 5 years ago | (#26849585)

99.9% of database claim to follow the relational model.

The rest have scalability problems that 99.9% of developers will never see throughout their entire careers.

So the answer is a simple, emphatic, no.

Finally the OODB people will (5, Insightful)

thammoud (193905) | more than 5 years ago | (#26849587)

Leave us RDBMS dinosaurs alone. String Name/Value pairs, that is a great innovation. In other news, Sun will be dropping all types from the Java object system and rely on the VOID type. Idiots.

Yeah (1)

Spazmania (174582) | more than 5 years ago | (#26849645)

The conclusion being that relational databases and key value stores aren't really mutually exclusive and instead are different tools for different requirements.

In related news, black is not white.

Re:Yeah (3, Funny)

idontgno (624372) | more than 5 years ago | (#26849853)

Is white the new black?

No, it isn't, black is the new black, and whiten and black are not really mutually exclusive. And.... I made you look. Thanks for the pageviews, suckers!

A great open source implementation (5, Funny)

thammoud (193905) | more than 5 years ago | (#26849647)

Map db = new HashMap();

beginTransaction(); // Synchronize on the map
db.add("key", "value");
commitTransaction(); // Just serialize the fucker to a file. The idiots using this won't know the difference.

Re:A great open source implementation (1)

julesh (229690) | more than 5 years ago | (#26850141)

commitTransaction(); // Just serialize the fucker to a file. The idiots using this won't know the difference.

You've come across prevayler then?

Re:A great open source implementation (1)

ADRA (37398) | more than 5 years ago | (#26850535)

Its better than the Image viewer that I once played with. It created all metadata and image thumbnails into a purely memory database.

It then stored the database to disk as a large set of insert statements instead of using some sort of disk based storage container. Needless to say, said application ran like a frigging slug. With larger sets of thumbnails, it'd simply run out of memory and die horribly.

It's like facebook...only slashdottier (1, Interesting)

Anonymous Coward | more than 5 years ago | (#26849659)

Ugh, yet another superficial blog post pimped out on slashdot. The guy doesn't have a solid technical grasp about data system and what really constitutes the difference between a system like BigTable or SimpleDB versus an RDBMS. Instead of talking about the differences in transaction management, consistency guarantees, etc. he comes up with brilliant ideas like RDBMSes are slower because they are more consistent.

Enough with the bad blog posts already, it's like facebook, only less interesting.

Re:It's like facebook...only slashdottier (1)

MightyMartian (840721) | more than 5 years ago | (#26849709)

Enough with the bad blog posts already, it's like facebook, only less interesting.

No, it's more like porn, except it doesn't have naked people doing things to themselves and each other.

Re:It's like facebook...only slashdottier (1)

poot_rootbeer (188613) | more than 5 years ago | (#26850017)

"Enough with the bad blog posts already, it's like facebook, only less interesting."

No, it's more like porn, except it doesn't have naked people doing things to themselves and each other.

It's kind of like a car, if the car didn't have a fuel gauge or any springs inside the passenger seat...

ah, stupid. (2)

tjstork (137384) | more than 5 years ago | (#26849775)

The big dumb thing about key store values is that they are actually just a subset of relational algebra in theory and are thus readily implementable in a relational database in fact. If you really wanted to have a database just do key / store values, you could quite easily do that in any rdms.

Re:ah, stupid. (3, Insightful)

poot_rootbeer (188613) | more than 5 years ago | (#26849993)

If you really wanted to have a database just do key / store values, you could quite easily do that in any rdms.

Sure, but it's not likely that a key/value store implemented within a general-purpose RDBMS can achieve the same raw performance that a system designed to do nothing but implement a key/value store -- nor the distributability, for that matter.

Re:ah, stupid. (0)

Anonymous Coward | more than 5 years ago | (#26850137)

as long as you don't mind all values being the same type, or serialized/unserialized to a string.

Summing up (0, Redundant)

godrik (1287354) | more than 5 years ago | (#26849813)

I do not believe someone dared to write this down : "If you don't need a relationnal database then relational database are unefficient". Waouh, this is rocket science guy! You should apply for the Fields medal.

It is obvious that if you do not need a structured and coherent base but a big hash table with property, then you do not need a Relationnal Database.

This is an old argument which will not fly (5, Informative)

bogaboga (793279) | more than 5 years ago | (#26849855)

It has been suggested before that the life of the relational DB is coming to an end. I must say that while I agree with this statement: -

Relational databases scale well, but usually only when that scaling happens on a single server node. When the capacity of that single node is reached, you need to scale out and distribute that load across multiple server nodes. This is when the complexity of relational databases starts to rub against their potential to scale.

I disagree with the following statement: -

Try scaling to hundreds or thousands of nodes, rather than a few, and the complexities become overwhelming, and the characteristics that make RDBMS so appealing drastically reduce their viability as platforms for large distributed systems.

I submit that the complexity can be managed and that's why we have jobs.

I am an IT consultant at a major bank and we keep all kinds of data. Data that many find useless and is spread across 27 [major] nodes. Total records in our biggest table number about 57 million with 49 rows. I can tell you that data querying and integrity maintaining are a breeze if the schematic design is correct in the first place.

We are always designing and testing different scenarios. In cases where we have had to change the schema, it has been simple if one knows what to do.

I must say that Open Source DBs have worked for us though we rely on products from IBM and Oracle.

Our philosophy is: If it works in PostgreSQL, it will even do wonders on DB2 or Oracle. I do not see how we can do away with the relational DB. Whoever designed it in the beginning did a marvelous job.

Ridiculous (3, Insightful)

Eravnrekaree (467752) | more than 5 years ago | (#26849877)

Really rational is the best way to take a data set and be able to access it in various ways. Many of the other concepts are indeed regressions and reintroduce problems a relational database solves. Relational allows you to able to display and view data in various different ways and apply the dataset in new ways, ways that may not have originally been a part of the original design of the application. Every time we hear someone harp about some new database technology that reintroduces all of the problems of the past, but relational is still the best and most versatile way to store your data in a way that allows for query flexibility.

Is the automobile doomed? (3, Insightful)

Renegade Iconoclast (1415775) | more than 5 years ago | (#26849895)

Turns out, there's something called a "skateboard." You can use it to travel as far as the Quickie Mart, with nothing but your feet to propel it.

In conclusion, skateboards and automobiles aren't the same thing, so probably not.

Always doomed and never dead (1)

MyMistake (620068) | more than 5 years ago | (#26849937)

I keep hoping that someday I'll read a Slashdot article headlined, "Is xxx doomed?" and the answer is... Yes!
So far... no.
Maybe we could see something like, "Is this the year that the Linux desktop doomed?"

some stories you could submit (1)

Xtifr (1323) | more than 5 years ago | (#26850459)

I keep hoping that someday I'll read a Slashdot article headlined, "Is xxx doomed?" and the answer is... Yes!

Feel free to submit any or all of the following:

Is CP/M doomed?
Is Microsoft Word for OS/2 doomed?[*]
Is pets.com [wikipedia.org] doomed?
Is the passenger pigeon doomed?
Is T-Rex doomed?
Is Shoemaker-Levy [wikipedia.org] doomed?

Get any of these accepted, and your wish will come true. :)

[*] Note, I own a copy of this, but I still suspect it's pretty doomed.

Project Voldemort? (1)

Talderas (1212466) | more than 5 years ago | (#26849949)

Seriously? Get the Harry Potter out. Out now!

Re:Project Voldemort? (0)

Anonymous Coward | more than 5 years ago | (#26850421)

And here I thought Project Voldemort was the new garbage collector for C++.
Objects would create horcruxes and as long as there is at least one horcrux left the object wouldn't be collected.
I would keep talking but I have a Sourceforge account to create.

Supid people who don't understand data (4, Informative)

mlwmohawk (801821) | more than 5 years ago | (#26850079)

The relational database is not going anywhere and nothing in that article is based on any firm understanding of managing data.

Is the notion of a "join" obsolete? No, but it is typically impractical in a high volume system. You would probably use denormalization as a strategy.

Scaling many nodes? OK, you still gotta put your data "in" something.

key/value indexing? yawn. select val from keyvalue_tab where key = foo;

The value can be basically anything, and most "relational" databases have good object support as well as XML, JSON, etc.

So we can establish that a SQL relational database can do *everything* a simpler system can do. Now, think about ALL the things you can do with your data in a real database.

What is the point of using a limited and less functional system? A good system, like Oracle, DB2, PostgreSQL, etc (!mysql of course) will do what you need AND allow you do do more should you be successful.

The problem with data is two fold: Managing read/write/deletes and finding what you are looking for. These problems have been solved. A good database will do this for you. Want to store object? XML, JSON, binary objects, or a specialized database extension works perfectly.

Re:Supid people who don't understand data (5, Insightful)

sl0ppy (454532) | more than 5 years ago | (#26850285)

The relational database is not going anywhere and nothing in that article is based on any firm understanding of managing data.

no, the relational database is not going anywhere, you are correct. but, that does not mean that there aren't instances where a non-relational database, with the addition of map/reduce, aren't extremely useful.

non-relational databases have been around for decades, and are in use for quite a number of applications involving rapid development and storage of very large records. couple this with map/reduce, and you have the ability to scale quickly with very large datasets.

scaling quickly is a very difficult problem to solve with an RDBMS - you either need to continue to throw more hardware at the problem, to the point of diminishing returns, or re-architect your data at the cost of possible significant downtime, while still attempting to serve up the data in a timely manner. i've been deep in the bowels of oracle RAC, fighting to get just 5% more speed out of a query over a billion rows and realizing that i have to start over with a new schema, just to squeeze more data out. compare that to simply adding another machine and letting the map functionality run across one more cpu before returning it for the reduce.

Is the notion of a "join" obsolete? No, but it is typically impractical in a high volume system. You would probably use denormalization as a strategy.

once again, correct, but having to denormalize to a snowflake or a star isn't always the best solution. you're taking the best parts of the relational database model, and throwing them out - normalization, referential integrity, just to squeeze more out of something that may not be the best tool for the job.

do you hammer with a wrench? i have before, and i managed to hurt my thumb.

Not (1)

dedazo (737510) | more than 5 years ago | (#26850107)

As an architect I tend to see databases are fancy storage systems, and in general they annoy me. I love object databases and distributed key-value pair store mechanisms. But even as jaded as I am I can see that the RDMBS isn't going anywhere any time. There are a lot of things that alternative storage systems simply cannot do well.

As for the Google argument (i.e., "bug Google does it and it works"), I've heard it a few times in meetings where a bright-eyed company executive is trying to make a case for their use. My response is usually "yeah, all you need now is to hire people like the ones that work at Google", at which point the argument is usually dropped. Making applications work with storage systems like that take an engineering mindset that's simply different than the talent at the average Fortune 500. RDBMS are pretty good at masking crappy development practices.

Ignorant doomspeaking. (1)

Jonas Buyl (1425319) | more than 5 years ago | (#26850109)

There are plenty of solutions yet to be explored to handle that problem without having to dump the relational database model. One I think of right now might be to view a server park as a hard drive, view a table like a file and apply all that filesystem technology to a problem that rises today. We can for example apply the UNIX inodes filesystem so you can efficiently store a database with great scalability.

Some credibility... (3, Insightful)

jernejk (984031) | more than 5 years ago | (#26850187)

form the article: "For example, a relatively simple SELECT statement could have hundreds of potential query execution paths, which the optimizer would evaluate at run time. All of this is hidden to us as users, but under the cover, RDBMS determines the "execution plan" that best answers our requests by using things like cost-based algorithms." So, you have no idea how optimizers work and how you can access tuning information, and you'd like to tell us RDBMSs are bad? Get of my lawn! (yay, I'm getting old)

Re:Some credibility... (2, Funny)

jernejk (984031) | more than 5 years ago | (#26850275)

no, really.. this is utter crap: so called benefit: "The first benefit is that they are simple and thus scale much better than today's relational databases. If you are putting together a system in-house and intend to throw dozens or hundreds of servers behind your data store to cope with what you expect will be a massive demand in scale, then consider a key/value store." but then:"Bugs in a properly designed relational database usually don't lead to data integrity issues; bugs in a key/value database, however, quite easily lead to data integrity issues." and then it just goes on on how RDBMSs are really cool... oh, I got it, it was really written by Oracle reverse marketing department!

He can't even explain relations correctly... (3, Informative)

iamhigh (1252742) | more than 5 years ago | (#26850195)

Does that example of a relational DB have a serious error, or is that just me? Why have make key in two tables?

He lost cred right then.

Re:He can't even explain relations correctly... (1)

reginaldo (1412879) | more than 5 years ago | (#26850331)

Not really an error. If make is an attribute of model, then landing it in the model table is fine, the grain is still at model level. If model is an attribute of car, then landing make in the car table is fine as well for the same reason.

Basically it negates the need for a multi-table join to get a make for a car.

Re:He can't even explain relations correctly... (1)

iamhigh (1252742) | more than 5 years ago | (#26850407)

True, you *could* put it in either and it would make sense, but not both. If it's in the makemodel table, you don't need it in the car table. The point of a relational db is to normalize data, removing duplicate data, right? If the Plymouth Neon changes to a Chrysler (or if it was something that would change more often) you then have to change it in 2 tables. If one gets updated incorrectly, you have conflicting data, thus rendering everything screwed up.

Not buying it. (5, Interesting)

reginaldo (1412879) | more than 5 years ago | (#26850203)

In theory, I agree the most costly actions in a database are joins. It seems like the key/value model is a great solution to this, on the surface. However, what the key/value model does is push the cost to the application layer. Instead of ensuring relational integrity and conformity in the database, suddenly all app code has to do this on the frontend. Also, instead of managing this process in a single place, suddenly this process is distributed among multiple methods. Sure, the DB is more scaleable, but suddenly the app is a mess.

Not the only one thinking this is silly... (1)

micromuncher (171881) | more than 5 years ago | (#26850321)

...or at least an attempt at bad advertising or pursuasive writing (cognitive justification.)

OODBMS have been pushing this, and many of them are pushed as light weight key-value stores.

http://en.wikipedia.org/wiki/ODBMS [wikipedia.org]

This isn't new, like OpenDoc's Bento
http://en.wikipedia.org/wiki/OpenDoc [wikipedia.org]

That became IronDoc
http://linuxfinances.info/info/oodbms.html [linuxfinances.info]

The problem with any of it is that relational databases rule the enterprise space. You cannot get away from them, and they are far from dead, because you will always have business people wanting to do ad hoc reports, and those are best done against denormalized models (where object stores tend to get super normalized which is just bad for reporting because cross table joins are the most expensive thing you can do in any database.)

Yay.

hell no (1)

Thaelon (250687) | more than 5 years ago | (#26850389)

There are still multi-billion dollar businesses operating the core of their business on COBOL systems, and they're decades older than relational database technology.

So don't bet on it.

RDBMS don't scale! (1, Funny)

Anonymous Coward | more than 5 years ago | (#26850489)

Quick someone tell CCP!

Relational DBs will be around for a long time... (1)

terryfunk (60752) | more than 5 years ago | (#26850517)

it will be a long time before the death of Relational DBs.

People will make them work regardless. It is a bit like COBOL, there's lots of it out there and it will be maintained for years to come...put it in the bank.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...