tag:blogger.com,1999:blog-8489991802309187017.post6858880209654875964..comments2023-07-12T23:51:00.904-07:00Comments on The ElastiCube Chronicles: Columnar RDBMS, Gourmet Fast Food and Santa ClausElad Israelihttp://www.blogger.com/profile/07558330790219988349noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8489991802309187017.post-34910149523333117782013-01-20T20:54:01.760-08:002013-01-20T20:54:01.760-08:00correlation DBMS (CRDBMS)correlation DBMS (CRDBMS)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8489991802309187017.post-40517027385684104252012-02-22T16:57:41.893-08:002012-02-22T16:57:41.893-08:00Interesting. I've always thought of column-bas...Interesting. I've always thought of column-based data storage as just "a table turned on its side" (obviously in very simple terms) - and hence still a table - done for the purpose of allowing faster queries on tables that would in a row-based RDBMS have a LOT of rows, with the entirety of a row having to be read off disk to answer a query that only needed data from one column (eg select count (male) from gender where state = 'CA') - very fast in a columnar database like Sybase IQ, especially if bitmap indexed. Or Vertica for that matter.<br /><br />But in my mind, still a table... but of course, perhaps that begs the question of defining a table - and then relating that definition to an accepted definition of an RDBMS.<br /><br />And to throw some chilli sauce into the gourmet, in Greenplum a DBA can actually partition a table and then specify one partition to use row-based storage and another to use column-based - depending on what kind of queries are expected over (say) recent data vs historical data. To the user issuing SQL, it's just one table.Mark Burnardnoreply@blogger.com