February 18, 2008

ParAccel technical highlights

I recently caught up with ParAccel’s CTO Barry Zane and Marketing VP Kim Stanick for a long technical discussion, which they have graciously continued by email. It would be impolitic in the extreme to comment on what led up to that. Let’s just note that many things I’ve previously written about ParAccel are now inoperative, and go straight to the highlights.

Comments

5 Responses to “ParAccel technical highlights”

  1. Stuart Frost on February 21st, 2008 3:57 pm

    Curt,

    I’m confused by the comment that, in Amigo mode, the schema is the same on the OLTP SQL Server and on ParAccel. That seems to be incredibly limiting. Although it might be true for some very simple reporting applications, no data warehouse I’ve ever seen uses the same schema as the OLTP source system. Also, what if there are many source systems (which is the typical case)?

    If true, surely this would be unusable in the vast majority of real-world situations.

    Stuart

  2. Curt Monash on February 21st, 2008 4:27 pm

    Stuart,

    And thus you’ve neatly explained why not EVERY ParAccel customer buys Amigo mode.

    CAM

  3. Doug McGraw on March 17th, 2008 12:46 pm

    Curt,

    I’ve read comments (yours and others) about columnar databases being slow to retrieve whole rows; but, I don’t hear anyone saying “how slow”. Can you shed any light on this? Are we talking 10′s or 100′s of milli-seconds … or longer?

  4. Curt Monash on March 18th, 2008 2:34 pm

    Doug,

    If you’re retrieving N fields in a row, the base case is N * (the work of retrieving one row), because you have to look in N different places.

    Obviously, a big part of columnar DBMS design is figuring out ways to outperform the base case. But absent something like the TransRelational architecture (see the category for same) — or some other major deviation from a simple-minded columnar approach — it’s hard.

    That’s for single rows. Once you’re retrieving lots of blocks of data, then the factor can be diminished or go away entirely, and be outweighed by columnar’s inherent advantages (you’re not retrieving the WHOLE row, and compression may work better).

    CAM

  5. Load speeds and related issues in columnar DBMS | DBMS2 -- DataBase Management System Services on December 2nd, 2008 10:54 am

    [...] Please do not rely on the parts of the post below that are about ParAccel. See our February 18 post about ParAccel instead. [...]

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.