• This is a list of Monash Advantage members.
• All our vendor clients are Monash Advantage members, unless …
• … we work with them primarily in their capacity as technology users. (A large fraction of our user clients happen to be SaaS vendors.)
• We do not usually disclose our user clients.
• We do not usually disclose our venture capital clients, nor those who invest in publicly-traded securities.
• Included in the list below are two expired Monash Advantage members who haven’t said they will renew, as mentioned in my recent post on analyst bias. (You can probably imagine a couple of reasons for that obfuscation.)

With that said, our vendor client disclosures at this time are:

• Aster Data
• Cloudera
• CodeFutures/dbShards
• Couchbase
• EMC/Greenplum
• Endeca
• IBM/Netezza
• Infobright
• Intel
• MarkLogic
• ParAccel
• QlikTech
• salesforce.com/database.com
• SAND Technology
• SAP/Sybase
• Schooner Information Technology
• Skytide
• Splunk
• Teradata
• Vertica

That list includes the two I’m obfuscating, plus one more who just emailed to say a signed renewal contract is arriving this week. It does not include others who, less concretely, have said they will sign up soon.

Also, I guess there’s a bit of a gray area for Tableau. As far as I’m concerned, I’m doing an upcoming co-sponsored webinar just for Monash Advantage member Aster Data. Indeed, I declined to contract with or bill Tableau directly for its share,  because I had no good way to do that paperwork. But even so, Tableau is a cosponsor, was involved in the planning discussions and, behind the scenes, is surely footing part of the bill.

SAS users do a lot of data filtering, aka data preparation, in SAS. These have WHERE clauses, just like SQL. However, only some of them map to actual SQL WHERE clauses. SAS is now implementing many of the rest as UDFs (User-Defined Functions), one DBMS at a time, starting with Teradata. In addition, SAS users can write custom filters that get registered as UDFs. This capability will be released with SAS 9.2. (The timing on SAS 9.2 is in line with the comment thread to my prior post on SAS-in-the-DBMS.)

As a “wouldn’t it be nice” future, Keith talked about a generic SAS format for these extensions. Frankly, I’m not holding my breath. Getting SQL extensions adopted and robustly used is hard, even when they’re worthy (think of MODEL BY clauses or most of SQL/MM).

SAS users in many cases also wind up scoring data, using the same constructs that data filters do. Again, SAS is putting this in the DBMS, via generated UDFs, in the SAS 9.2 time frame. Benefits include performance and the saving of a recoding step. As with the filtering, Keith looks forward to a more generic format for this than UDFs, but my caveats above again apply.

Note: This all applies only to some SAS algorithms, not all. For example, an algorithm that involves a lot of iteration probably won’t run best within the confines of a DBMS.

So far we haven’t covered anything that is MPP-specific. But some further ideas are. First, while it’s not going to happen in 2008, SAS plans to refactor some of its algorithms – namely those that it is going to run in the database anyway – for massively parallel processing. (Counts and aggregations are obvious examples.) Second – and this is still just a research project — SAS would like to run a complete SAS server on a node of an MPP DBMS, at which point all those UDFs could be stored procedures instead.

While I had Keith on the phone anyway, I raised some general issues of SAS performance. Keith suggested that data mining/predictive analytics and forecasting rely on high volumes of data, which is consistent with the large fraction of data warehouse complex queries that are devoted to SAS extracts.

But then he went on to confuse me a bit On the one hand, he pointed out that optimization was classically much less about high volumes of data,and more lots of computations on the data. On the other, he mentioned the Kohl’s optimization project . Specifically, he cited it as an example of processing thousands of variables, and hence more columns than most DBMS today do a good job of supporting. From this I gathered that Kohl’s is using SAS’s own data management tool, SAS Intelligence Storage.

Finally, Keith expanded on that point, and opined that some major differences between SAS processing and OLTP lay behind a strong SAS/Intel relationship. Processors designed for OLTP assume short instruction pipelines, and replicate cache from process to process. But he prefers his chips to (also) be optimized for long instruction pipelines, in which data is passed sequentially through a long series of steps.

Keep getting great research about data warehousing, analytics, and related technologies. Get a FREE subscription by RSS or email!

Technorati Tags: SAS, data warehouse

The basic figures are about 2.3X performance and about 1.1X power consumption. Better performance comes from two sources: Doubling the number of cores (duh), and changing the memory design. The latter underscores a point that arose in my research on memory-centric data management: It’s not just raw CPU speed that’s important. At least for database processing, memory speeds, memory bus speeds, etc. are increasingly significant. (Or maybe they always were this significant, and I just didn’t realize it before.)

When I wrote recently of my belief that Intel is making a comeback, this DATallegro evidence was a big part of what I was thinking of.

This is the project for which I origially coined the term “memory-centric data management,” after realizing that the prevalent “in-memory DBMS” creates all sorts of confusion about how and whether data persists on disk. The white paper clarifies and updates points I have been making about memory-centric data management since last summer. Sponsors included:

• Applix, vendors of in-memory/memory-centric MOLAP tool TM1
• Progress Software, vendors of ObjectStore, an OODBMS that has more impressive references in-memory or otherwise memory-centric than it does in classical disk-based configurations, and also of the Apama stream processing products
• SAP, vendors of the BI Accelerator functionality of SAP NetWeaver, or whatever tortured name they want to give it this month — basically, that’s a very cool in-memory columnar data mart technology
• Solid Information Technology, vendor of hybrid in-memory/disk-based OLTP RDBMS. Historically focused on the embedded systems market, especially telecom and networking, they’ve recently been in the news because of a deal with MySQL that is designed to extend their reach.
• Intel, makers of the processors used to run a lot of the other sponsors’ products (including all BI Accelerator installations to date).

If there’s one area in my research I’m not 100% satisfied with, it may be the question of where the true hardware bottlenecks to memory-centric data management lie (it’s obvious that the bottleneck to disk-centric data management is random disk access). Is it processor interconnect (around 1 GB/sec)? Is it processor-to-cache connections (around 5 GB/sec)? My prior pronouncements, the main body of the white paper, and the Intel Q&A appendix to the white paper may actually have slightly different spins on these points.

And by the way — the current hard limit on RAM/board isn’t 2^64 bytes, but a “mere” 2^40. But don’t worry; it will be up to 2^48 long before anybody actually puts 256 gigabytes under the control of a single processor.