Thread: stonebraker diffs RDBMS
Two links here, comments anybody? http://www.computerworlduk.com/technology/applications/databases/news/index.cfm?newsid=5059 http://www.databasecolumn.com/ Robert
Robert, > http://www.databasecolumn.com/ This looks like a last-ditch attempt to drum up interest in Vertica. Since Vertica is in trouble and probably doomed, I'm not inclined to pay much attention to it ... -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
On 9/10/07, Josh Berkus <josh@agliodbs.com> wrote: > This looks like a last-ditch attempt to drum up interest in Vertica. Since > Vertica is in trouble and probably doomed, I'm not inclined to pay much > attention to it ... Interesting. Why do you say that?
On Mon, 2007-09-10 at 16:09 -0400, Robert Bernier wrote: > http://www.databasecolumn.com/ Stonebraker has been saying essentially the same thing for a few years now. Some more literate presentations of the same ideas can be found here: http://www.cs.brown.edu/~ugur/fits_all.pdf http://nms.csail.mit.edu/~stavros/pubs/hstore.pdf -Neil
Robert Bernier wrote: >Two links here, comments anybody? > >http://www.computerworlduk.com/technology/applications/databases/news/index.cfm?newsid=5059 > >http://www.databasecolumn.com/ > >Robert > > > OK, I'm being stupid here- can someone please explain to me the difference between a column-oriented database and a fully normalized row-oriented database? Most databases are insufficiently normalized, this I know (including mine). And this causes pain. But it seems to me that full normalized (aka column-oriented) databases also cause pain, just a different type of pain. Collecting rows I'm very likely to all want together onto the same page strikes me as being a signifigant performance advantage. Having to read in a page for every column- or worse yet, O(log N) pages for each column (as I have to traverse an index)- strikes me as being a huge performance hit. But maybe I'm not seeing something, and someone can enlighten me. Brian
Am 11.09.2007 um 14:34 schrieb Brian Hurt: > Robert Bernier wrote: > >> Two links here, comments anybody? >> >> http://www.computerworlduk.com/technology/applications/databases/ >> news/index.cfm?newsid=5059 >> >> http://www.databasecolumn.com/ >> >> Robert >> >> > > OK, I'm being stupid here- can someone please explain to me the > difference between a column-oriented database and a fully > normalized row-oriented database? I guess, these are questions belonging to core implementation decisions. With every select you make, whole rows are loaded depending on conditions you specify in your query. This is opposite to searching columns first, finding rows that meet all conditions in the results. For me it looks a bit like using an index for each field and everything, but that me be a very basic understanding of what is dicussed here. In the end, there will be reasons why RDBMS are such successful. The object DBs have been around for a while and are gaining momentum slowly but steadily. The performance argument has always been two edged for a basic decision on development directions. While performance increase of a magnitude might open a whole range of new applications it gets eaten up by hardware acceleration overtime. Novell had a really tough time when turning from Netware 3 to 4 partly because they made the base assumption that PC hardware will always be to slow for complex software. What was their success in Version 3 made them too slow when developing new features and they lost against Microsoft with their brand new but then performance encumbered Windows NT. You know what has happened meanwhile. Bye, Christian
On Mon, 2007-09-10 at 16:09 -0400, Robert Bernier wrote: > Two links here, comments anybody? > > http://www.computerworlduk.com/technology/applications/databases/news/index.cfm?newsid=5059 > > http://www.databasecolumn.com/ As Stonebraker himself points out, "one size fits all" isn't true. His claim than column-oriented databases can perform 50 times faster than row-oriented (i.e. us) is IMHO true, but only on certain queries and he neglects to comment that on many queries they suck really badly too. My advocated approach is to learn from the technique and include lessons learned into PostgreSQL, that way we have the benefits of multiple techniques as and when required. So, yes, one day I expect to include column-oriented techniques into the database server, but it probably won't be a straight implementation of verbatim Stonebraker... There is some discussion on -hackers on this now, but please everybody don't start a surge on this now or soon, we have a release to get out of the door. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
Hi, I still don't see the difference between column-orientation and vertical partitioning. Any idea? Best regards, Ileana