SCALE 8x: Relational vs. non-relational [LWN.net]

SCALE 8x: Relational vs. non-relational

Posted Mar 7, 2010 16:53 UTC (Sun) by bronson (subscriber, #4806)
In reply to: SCALE 8x: Relational vs. non-relational by kleptog
Parent article: SCALE 8x: Relational vs. non-relational

Or, what if your queries don't easily translate into SQL's SELECT and UPDATE model?

I had this last year: the data itself fit perfectly into tables with foreign keys. Problem is, we were trying to allow marketing people to slice and dice it in fairly arbitrary ways, and their needs would change from week to week.

This was typical data warehouse-type stuff. Compute the monetary total of all orders for customers from this region. If that's above a value provided by marketing, then what's the average zip code and standard deviation for the remaining customers who have dogs, etc. (you get the idea)

I wish I had done the whole thing in MongoDB using map-reduce. I think it would have been a lot faster, both to develop and to run. I wouldn't have to spend as much time figuring out which indices, counter caches, and denormalization that would be needed to make this week's reports complete in time.

So, even if your data model is nicely tabular, that doesn't mean your usage patterns will be!

(Log in to post comments)

Regarding hierarchical RDBMS

Posted Mar 11, 2010 10:35 UTC (Thu) by gvy (guest, #11981) [Link]

I've met at least two bright examples of non-relational RDBMS which did shine where My|Pg or Ora just would not:

Daylight for cheminformatics just blew off whatever I could even primitively benchmark with mysql/postgresql back then (2001/2002) by *orders* in speed, not even trying to compare the exact problem domain value (e.g. fingerprints);
GT.M (remember MUMPS?) and temporal model users (whether in hospital IT or business) might have a good laugh with "If the data being stored has a life independent of the specific application and needs to be available to new applications down the road, SQL-relational is probably the right choice".
There was e.g. a discussion on sql.ru describing the details of a migration off a "legacy" hierarchical system to Java and Oracle -- which "doubled the performance" (forgetting to mention the need to go dual Xeon 51xx and external storage from something like dual Pentium with SCSI).

Basically, if you have to do things like "this attribute holds a value changing the *meaning* of that attribute", then you just reinvented a hierarchical database where adding another leaf might be less pain and overhead. And you might have wanted to look a bit wider. :)