January 18, 2011

Architectural options for analytic database management systems

Mike Stonebraker recently kicked off some discussion about desirable architectural features of a columnar analytic DBMS. Let’s expand the conversation to cover desirable architectural characteristics of analytic DBMS in general.  But first, a few housekeeping notes:

OK. In my opinion, the four drop-dead requirements for an analytic DBMS are:

Depending on your use case, you might have additional make-or-break requirements. Possible areas include:

Other possibly important features — but ones that would usually go on “nice to have” rather than “must have” lists — include:

So what kinds of architectural choices (or major features) should one look to to support such features? On the performance side there are many candidates, including:

You can’t do much with an analytic database unless you get data into it in the first place. Thus, performance in writing and loading data are important, and there are a number of architectural decisions that can be helpful in those regards.

And of course, all of the above need to be implemented in the context of well-configured combinations of hardware, networking, and software.

Topics I know I’ve left out include advanced-analytics functionality, and in-memory processing (CEP or otherwise). Also missing are specifics of compression algorithms — or indeed of anything else. I’m sure there’s much else missing besides, so please point out the most glaring omissions in the comment thread below. :)

Related links:

Comments

5 Responses to “Architectural options for analytic database management systems”

  1. zedware on January 20th, 2011 11:07 am

    Good article.
    Where can I find a comprehensive comparison among the different analytical DBMSs?

  2. Curt Monash on January 20th, 2011 11:21 am

    I doubt there is one. As you can see from this post, it would be pretty long and detailed.

    Also, it would change quickly, as this is an area in which products are pretty young and show rapid progress accordingly.

  3. Analytic computing systems, aka analytic platforms | DBMS 2 : DataBase Management System Services on January 24th, 2011 1:28 am

    [...] I posted a long list of architectural options for analytic DBMS, I left a couple of IOUs in for missing parts. One was in the area of what is sometimes called [...]

  4. Mike Pilcher on February 10th, 2011 8:42 am

    I would like to add one more to your list. I think a lot of vendors are ignoring user concurrency. If we in the analytic community really want real-time access to information deployed in a mission-critical way, then we need to move out of silos of small scale analysts and data miners and into the enterprise. I believe we need to address this head on and as many analytic databases are moving from the architectural formats of OLTP, we should move away from the locking concepts that were essential for OLTP. In an analytic world we have to address technologically the ubiquity we claim. Generation Based Concurrency Control is one way, I am sure there are others, but there needs to be something to maximize user adoption.

  5. 大数据处理架构_前言 | Allen's World on April 16th, 2012 7:12 am

    [...] 分析型RDBMS架构:http://www.dbms2.com/2011/01/18/architectural-options-for-analytic-database-management-systems/ [...]

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.