Aster Data nCluster Version 4.6
The main thing in Aster Data nCluster Version 4.6 is Aster’s version of hybrid row-column store technology. Technical highlights include:
- Aster Data is simply taking the number of storage options in nCluster up from 1 to 2 – you now can store a table either in the Aster Data nCluster row store or column store.
- In fact, you can store parts of a table in the Aster Data nCluster row store and other parts in the Aster Data nCluster column store. I‘m a bit foggy on the details of that – Aster makes discussions of partitioning more complicated than they need to be — but it definitely sounds pretty flexible. Edit: See comment thread below.
- Anything you can do with the Aster Data nCluster row store you can also do with the Aster Data nCluster column store. In particular, that includes all of Aster Data’s analytic functionality.
- The same is true vice-versa. There is no columnar-oriented kind of compression in Aster Data nCluster at this time.
So Aster Data has now joined Greenplum/EMC among row-based analytic DBMS vendors with hybrid row-column stores. Oracle will join them some day, and the same probably applies to other row-based vendors as well. Similarly, Aster Data will probably join Oracle some day in having columnar compression. And so this all fits the model:
- Aster Data has an impressively competitive analytic relational DBMS, considering the youth and size of the company.
- Aster Data is a leader in extending its analytic relational DBMS by integrating in other analytic processing capabilities.
Aster Data’s nCluster Version 4.6 slide deck has a couple of cool use case slides, which I got permission to post. Taken together, they tell a story in which you might want to store raw data in rows, derived data in columns, and additional derived data also in rows. Slick.
In other Aster Data news, I spoke with Aster’s new CEO Quentin Gallivan last week (making it two calls with Aster while I was on vacation). He didn’t say anything that made me cringe in horror, which is pretty much the best that can be expected at this stage of his tenure, at least given his lack of background in closely-related technology areas.* Former CEO Mayank Bawa is going to be head of all services, with a title of “Chief Customer Officer” to match co-founder Tasso Agyros’ title “Chief Technical Officer.” I expect that to go well.
*Somehow, former execs of the big DBMS companies aren’t doing well in the DBMS start-up CEO searches. Truth be told, I can’t think of anybody that’s getting overlooked too badly. Some folks I thought could be major stars coming out of less-than-top jobs at Oracle in the 1990s haven’t really hit it big as CEOs – e.g. Dennis Moore, Nimish Mehta, or Polly Sumner. And not a lot of candidates come to mind from more recent generations of execs. Perhaps this underscores just how different Oracle’s business now is from that of Aster Data, Vertica, Infobright, or ParAccel, to name four analytic DBMS vendors that recently changed CEO.
Comments
4 Responses to “Aster Data nCluster Version 4.6”
Leave a Reply
Curt, a good post on our 4.6 release. I just wanted to provide some clarity on the details of “you can store parts of a table in the Aster Data nCluster row store and other parts in the Aster Data nCluster column store”. We call this partitions. Applications and admin tools query the parent table as a logical whole and our database optimizer ensures that only the right partitions are scanned. The important aspect here is that partitions of the same parent can be stored independently on disk. E.g. one partition could be stored as in a row format and a second partition of the same parent stored in a column format. This enables administrators to select row or column format storage at the partition-level. This is what we mean when we say that you can have a hybrid row and column table.
To clarify compression for the nCluster column store, we do have compression—same as other hybrid row and column DBMSs, where standard compression is available for the column store. We offer multiple versions of LZ (Lempel-Ziv) and gzip compression, any of which you can choose on a table-by-table or partition-by-partition basis. Compression is available for both the row store and column store within nCluster, with column tables by their nature typically providing better compression ratios compared to row tables using the same compression techniques.
For folks that are interested in more technical details on our hybrid row and column DBMS, there is a good blog post today from Tasso Argyros, our CTO at http://bit.ly/dCuGPR
Stephanie,
Thank you for the detailed and PROMPT comment! That’s also a good link to Tasso’s post.
Do I recall correctly that your very rough figure is that columnar storage is worthwhile whenever the fraction of data needed in a query is 40%ish or less?
——————————–
All,
Stephanie emailed me the info above, and then posted it as a comment WITHOUT waiting to be prodded. Yay her!
One point in the email I don’t see in her comment, however, is that this partitioning is only into sets of rows. You can’t split a table vertically, store some of it row-wise (e.g., an address or composite key), and some of it columnarly.
CAM
[…] Quentin Gallivan — and had dinner with Mayank Bawa — my previously favorable views of Aster Data’s management transition are […]
[…] http://www.dbms2.com/2010/09/15/aster-data-ncluster-version-4-6/ […]