5 ms·

Stonebraker: Send Relational DBMSs to the Home for Tired Software

18 points by mblakele 17y ago

Femur 17y ago
You know, every couple of weeks an article like this comes up on HN or Slashdot predicting the end of the RDBMS. I don't deny that special purpose data stores can offer great performance improvements in some applications. But there is a reason that RDBMSs are celebrating their 40th birthday (as the article mentions). They are flexible, cheap (except for Oracle and DB2) and easy to manage. My guess is that we will still be reading about the imminent death of the relational database another 40 years from now.
- michael_dorfman 17y ago
  You could be right. But Stonebraker is not "just another guy" predicting the end of the era of the RDBMS. He's one of the guys who invented the RDBMS. If he thinks he's seen something better, well, I think it's worth at least taking a look.
  - gaius 17y ago
    He is selling something (he claims to be) better - Vertica. I've no comment either way on whether it is, and I know who Stonebraker is and respect what he's done, but he has a vested interest here. Just like Netscape programmers needed to kill off their earlier work, Mosaic.
    - Paul_Morgan 17y ago
      he's also selling VoltDB (OLTP memory resident DBMS) and SciDB (Scientific Data).
    - michael_dorfman 17y ago
      I agree. And he's been selling post-relational stuff for a while-- this is not a new observation on his part. I'm not going to form an opinion on his word alone, but he's got big enough chops in my book to warrant taking what he says seriously, even if he has a vested interest.
- mlLK 17y ago
  Understood, this reads like anti-Oracle linkbait.
- rjurney 17y ago
  The reason you see these articles is that RDBMses are ill suited to take advantage of opportunities created by cloud computing.
  - anamax 17y ago
    RDBMs are perfectly consistent with cloud computing.
    - strlen 17y ago
      Why do you make this assertion? Other than with a proprietary solution (e.g. Oracle RAC), what options are there to easily add/remove capacity on demand from an RDBMS? Now, you can just add additional "shards" of a MySQL database, but that breaks the whole "R" of "RDBMS" (can't do joins across the shards). In addition, you're limited to a ring-style Master-Master replication scheme vs/ a grid/mesh. There's also MySQL NDB_Cluster engine, but I have never (to date) seen it in production (there are just too many limitations). Proprietary solutions like Oracle RAC may scale on demand, but require a DBA team. The cost overhead offsets any savings gained through on-demand provisioning of resources. Not to mention Oracle RAC (and even MySQL) aren't exactly friendly to commodity hardware (which is what both official cloud computing solutions and de-facto clouds used in high-tech companies' data centers are built on).
      - Femur 17y ago
        Oracle RAC is stupidly complicated to administer. You are correct in your statement that a RAC environment generally does require a DBA team and the cost overhead is significant. Further, Oracle has very stringent hardware and OS certification and you will not receive any support from Oracle on uncertified systems. However, I would not associate it with the "cloud" movement/paradigm/whatever. It is a cluster (the C in RAC stands for cluster) with 2 or more instances sharing memory structures across a network. To add another node to the cluster is excruciating; I would not classify it as dynamically scalable - the hallmark of cloud computing.
      - anamax 17y ago
spudlyo 17y ago
This is just a brief summary of the Michael Stonebraker's piece "The End of a DBMS Era (Might be Upon Us)" which appeared on HN a few days ago. As far as I can tell it adds nothing new, am I missing something?
mlLK 17y ago
I don't understand, I thought relational DBMS were left for the dogs many years ago. . .http://en.wikipedia.org/wiki/Dbms#End_1970s_SQL_DBMS http://en.wikipedia.org/wiki/Dbms#End_1970s_SQL_DBMS
tophat02 17y ago
Software Engineering would progress a lot farther as a discipline if we weren't so preoccupied with throwing out the "old" to make room for the "new". My definition of "legacy" code: code that is field-tested, has a low defect rate, and generally works.
SkyMarshal 17y ago
As long as they don't throw out the underlying idea that data can be deconstructed then reorganized into a form that adheres to mathematic principles, set theory and predicate logic in the case of RDBMS's, and from that you can perform logical operations on it that allow you to derive new, additional information from it. I think that was the major breakthrough of Relational Theory, hopefully that is built on, rather than thrown out. Speaking of which, Chris Date, Hugh Darwen and some others were talking about a significant extension or evolution of the relational database, called the transrelational database, several years ago. Anyone heard of any progress on that front lately?
- mblakele 17y ago
  This? http://www.dbms2.com/2005/11/12/transrelational-23/ http://www.dbms2.com/2005/11/12/transrelational-23/
  - SkyMarshal 17y ago
    Ah, too bad. Thx.
seldo 17y ago
It seems as a database engineer, I am going to have to bulk up my skills in non-RDBMS technologies, even if just to be able to say "yes, I am very familiar with <random non-SQL DBMS> and it's not an appropriate solution to this problem".
sophacles 17y ago
I think this article makes some good points. In fact there are times when I've been very frustrated at the "We can't to better than RDBMS" attitude many times. Particularly that time we were storing a tree in a table. Specialized data stores are very neat. I do however think there will always be a good place for the traditional RDBMS. For instance, there are times when I'm creating that I don't know what the layout of the data will need to be, and where the optimizations will be most needed, so I back an app with Postgres. Should I need to expand later, it will be easier as I have actual data to work with. I guess the point I'm trying to make is: unless you know for sure that your data will benefit from a different model (e.g. known performance needs, or a better conceptual mapping), not using an RDBMS seems like a premature optimizaton.
dkarl 17y ago
In the online transaction processing (OLTP) market, a lightweight main memory DBMS beats a row store by a factor of 50. I'm confused -- what does main memory vs. row store have to do with relational vs. non-relational?
- gnaritas 17y ago
  Everything when you're talking about real world implementations and not some abstract theory in your head.
wheels 17y ago
The actual article was already on here: http://news.ycombinator.com/item?id=680881 http://news.ycombinator.com/item?id=680881

18 points by mblakele 17y ago

Femur 17y ago

You know, every couple of weeks an article like this comes up on HN or Slashdot predicting the end of the RDBMS. I don't deny that special purpose data stores can offer great performance improvements in some applications. But there is a reason that RDBMSs are celebrating their 40th birthday (as the article mentions). They are flexible, cheap (except for Oracle and DB2) and easy to manage. My guess is that we will still be reading about the imminent death of the relational database another 40 years from now.

michael_dorfman 17y ago
You could be right. But Stonebraker is not "just another guy" predicting the end of the era of the RDBMS. He's one of the guys who invented the RDBMS. If he thinks he's seen something better, well, I think it's worth at least taking a look.
- gaius 17y ago
  He is selling something (he claims to be) better - Vertica. I've no comment either way on whether it is, and I know who Stonebraker is and respect what he's done, but he has a vested interest here. Just like Netscape programmers needed to kill off their earlier work, Mosaic.
  - Paul_Morgan 17y ago
    he's also selling VoltDB (OLTP memory resident DBMS) and SciDB (Scientific Data).
  - michael_dorfman 17y ago
    I agree. And he's been selling post-relational stuff for a while-- this is not a new observation on his part. I'm not going to form an opinion on his word alone, but he's got big enough chops in my book to warrant taking what he says seriously, even if he has a vested interest.
mlLK 17y ago
Understood, this reads like anti-Oracle linkbait.
rjurney 17y ago
The reason you see these articles is that RDBMses are ill suited to take advantage of opportunities created by cloud computing.
- anamax 17y ago
  RDBMs are perfectly consistent with cloud computing.
  - strlen 17y ago
    Why do you make this assertion? Other than with a proprietary solution (e.g. Oracle RAC), what options are there to easily add/remove capacity on demand from an RDBMS? Now, you can just add additional "shards" of a MySQL database, but that breaks the whole "R" of "RDBMS" (can't do joins across the shards). In addition, you're limited to a ring-style Master-Master replication scheme vs/ a grid/mesh. There's also MySQL NDB_Cluster engine, but I have never (to date) seen it in production (there are just too many limitations). Proprietary solutions like Oracle RAC may scale on demand, but require a DBA team. The cost overhead offsets any savings gained through on-demand provisioning of resources. Not to mention Oracle RAC (and even MySQL) aren't exactly friendly to commodity hardware (which is what both official cloud computing solutions and de-facto clouds used in high-tech companies' data centers are built on).
    - Femur 17y ago
      Oracle RAC is stupidly complicated to administer. You are correct in your statement that a RAC environment generally does require a DBA team and the cost overhead is significant. Further, Oracle has very stringent hardware and OS certification and you will not receive any support from Oracle on uncertified systems. However, I would not associate it with the "cloud" movement/paradigm/whatever. It is a cluster (the C in RAC stands for cluster) with 2 or more instances sharing memory structures across a network. To add another node to the cluster is excruciating; I would not classify it as dynamically scalable - the hallmark of cloud computing.
    - anamax 17y ago

spudlyo 17y ago

This is just a brief summary of the Michael Stonebraker's piece "The End of a DBMS Era (Might be Upon Us)" which appeared on HN a few days ago. As far as I can tell it adds nothing new, am I missing something?

mlLK 17y ago

I don't understand, I thought relational DBMS were left for the dogs many years ago. . .http://en.wikipedia.org/wiki/Dbms#End_1970s_SQL_DBMS http://en.wikipedia.org/wiki/Dbms#End_1970s_SQL_DBMS

tophat02 17y ago

Software Engineering would progress a lot farther as a discipline if we weren't so preoccupied with throwing out the "old" to make room for the "new". My definition of "legacy" code: code that is field-tested, has a low defect rate, and generally works.

SkyMarshal 17y ago

As long as they don't throw out the underlying idea that data can be deconstructed then reorganized into a form that adheres to mathematic principles, set theory and predicate logic in the case of RDBMS's, and from that you can perform logical operations on it that allow you to derive new, additional information from it. I think that was the major breakthrough of Relational Theory, hopefully that is built on, rather than thrown out. Speaking of which, Chris Date, Hugh Darwen and some others were talking about a significant extension or evolution of the relational database, called the transrelational database, several years ago. Anyone heard of any progress on that front lately?

mblakele 17y ago
This? http://www.dbms2.com/2005/11/12/transrelational-23/ http://www.dbms2.com/2005/11/12/transrelational-23/
- SkyMarshal 17y ago
  Ah, too bad. Thx.

seldo 17y ago

It seems as a database engineer, I am going to have to bulk up my skills in non-RDBMS technologies, even if just to be able to say "yes, I am very familiar with <random non-SQL DBMS> and it's not an appropriate solution to this problem".

sophacles 17y ago

I think this article makes some good points. In fact there are times when I've been very frustrated at the "We can't to better than RDBMS" attitude many times. Particularly that time we were storing a tree in a table. Specialized data stores are very neat. I do however think there will always be a good place for the traditional RDBMS. For instance, there are times when I'm creating that I don't know what the layout of the data will need to be, and where the optimizations will be most needed, so I back an app with Postgres. Should I need to expand later, it will be easier as I have actual data to work with. I guess the point I'm trying to make is: unless you know for sure that your data will benefit from a different model (e.g. known performance needs, or a better conceptual mapping), not using an RDBMS seems like a premature optimizaton.

dkarl 17y ago

In the online transaction processing (OLTP) market, a lightweight main memory DBMS beats a row store by a factor of 50. I'm confused -- what does main memory vs. row store have to do with relational vs. non-relational?

gnaritas 17y ago
Everything when you're talking about real world implementations and not some abstract theory in your head.

wheels 17y ago

The actual article was already on here: http://news.ycombinator.com/item?id=680881 http://news.ycombinator.com/item?id=680881