May 22, 2010

Notes on SciDB and scientific data management

I firmly believe that, as a community, we should look for ways to support scientific data management and related analytics. That’s why, for example, I went to XLDB3 in Lyon, France at my own expense. Eight months ago, I wrote about issues in scientific data management. Here’s some of what has transpired since then.

The main new activity I know of has been in the open source SciDB project.  

In other scientific data management news,

Finally, you surely are aware of the whole “Climategate” mess, in which major climate researchers’ email was hacked and many unkind conclusions were drawn. Well, one of the most technical parts of the disclosure was in a long series of Read Me files, in which an unfortunate programmer lamented about the difficulty of reconstructing published results from files at hand. These turned out to illustrate a classic problem that SciDB or alternatives are meant to solve:

Comments

3 Responses to “Notes on SciDB and scientific data management”

  1. Michael on May 26th, 2010 4:17 pm

    Why has interest from “web analytics users” receded recently? Could this be due to the increased interest in Hadoop/Cassandra and similar products?

  2. Curt Monash on June 3rd, 2010 6:11 am

    Michael,

    SciDB is for analytics; Cassandra is for OLTP, hold the “T”, which I called HVSP in http://www.dbms2.com/2010/03/13/the-naming-of-the-foo/.

    Hadoop is a closer competitor, as are RDBMS, MapReduce-enabled or otherwise.

  3. Michael McIntire on July 31st, 2010 1:27 pm

    What is driving the move to hadoop and other non-relational platforms is the cost and culture of RDBMS implementations.

    The culture problem is related to data management systems forcing data to be transformed into a private and internal form, and all the process that fronts it. Dimensional Modeling is an example. Let’s stop physicalizing dimensional design because that’s what RDBMS products support.

    On the cost front, generating data declines at roughly the inverse of moore’s law, not counting non-native per transaction data growth (I’m collecting more and more data about every event).

    On the analytics side of this problem – there are many more scans of the full dataset to get a single metric, so this function cost grows non-linearly in relation to the data size.

    So – Data costs are declining at the same rate of hardware. Data Analytics costs are RISING per unit of data. Put quite simply, at the upper end of the data size spectrum – data owners cannot afford to buy data management software.

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.