Comments on: Open issues in database and analytic technology http://www.dbms2.com/2010/02/01/open-issues-in-database-and-analytic-technology/ Choices in data management and analysis Thu, 09 Feb 2012 13:48:12 +0000 hourly 1 http://wordpress.org/?v=3.0.3 By: Quick thoughts on Sybase/Aleri | DBMS2 -- DataBase Management System Services http://www.dbms2.com/2010/02/01/open-issues-in-database-and-analytic-technology/#comment-158229 Quick thoughts on Sybase/Aleri | DBMS2 -- DataBase Management System Services Thu, 04 Feb 2010 18:51:58 +0000 http://www.dbms2.com/?p=1507#comment-158229 [...] is a potentially powerful combination, if they can effectively address the point I just made about integrating disparate latencies. That said, I’m not expecting a lot, because the CEP industry always disappoints [...] [...] is a potentially powerful combination, if they can effectively address the point I just made about integrating disparate latencies. That said, I’m not expecting a lot, because the CEP industry always disappoints [...]

]]> By: Curt Monash http://www.dbms2.com/2010/02/01/open-issues-in-database-and-analytic-technology/#comment-157903 Curt Monash Tue, 02 Feb 2010 19:55:02 +0000 http://www.dbms2.com/?p=1507#comment-157903 RC, Please see some of the other posts in the category here for graph datatypes. An index for graphs would probably be a big materialized view that concatenates 2 or 3 or whatever edges at once. Better than nothing, but exponential in the number of hops. Whether real-life graphs let you store them in clever ways to get significantly better performance than that is an open question. Cogito used to claim it could, but didn't do too much in the way of delivering. RC,

Please see some of the other posts in the category here for graph datatypes.

An index for graphs would probably be a big materialized view that concatenates 2 or 3 or whatever edges at once. Better than nothing, but exponential in the number of hops.

Whether real-life graphs let you store them in clever ways to get significantly better performance than that is an open question. Cogito used to claim it could, but didn’t do too much in the way of delivering.

]]> By: Azeem Jiva http://www.dbms2.com/2010/02/01/open-issues-in-database-and-analytic-technology/#comment-157901 Azeem Jiva Tue, 02 Feb 2010 19:48:44 +0000 http://www.dbms2.com/?p=1507#comment-157901 I agree that I/O is the big bottleneck for most analytic. Whether that's in the cloud or a big Oracle database with solid-state disks. Getting at terabytes or petabytes of data isn't easy and as core counts go up processing that data gets harder if you can't feed the cores fast enough. I agree that I/O is the big bottleneck for most analytic. Whether that’s in the cloud or a big Oracle database with solid-state disks. Getting at terabytes or petabytes of data isn’t easy and as core counts go up processing that data gets harder if you can’t feed the cores fast enough.

]]> By: RC http://www.dbms2.com/2010/02/01/open-issues-in-database-and-analytic-technology/#comment-157865 RC Tue, 02 Feb 2010 13:39:17 +0000 http://www.dbms2.com/?p=1507#comment-157865 You think it is possible to make the RDBMS more suitable for relationships analytics by adding a new kind of index type? You think it is possible to make the RDBMS more suitable for relationships analytics by adding a new kind of index type?

]]>