ParAccel Update

Not long ago I had the pleasure of speaking with Kim Stanick of ParAccel to get an update on what they've been doing and where they're headed. Here are the highlights from my notes.

Business News


Company Growth


Unlike many (or even most) companies, ParAccel grew last year, doubling from roughly 30 to 60 employees.

POCs


ParAccel spent its first year of operation focused largely on competing effectively in POCs. They now measure POC lengths in days rather than weeks, and are actively engaged in multiple concurrent POCs in the field. In addition, POC sizes are growing, and now range between 10TB and 100TB systems, with tests often performed in both in-memory and on-disk configurations. To me, the combination of POC speed (days), location (in the field), size (100TB) and flexibility (memory vs. disk) is a sign that the product has matured rapidly.

I saw a handful of selected results from POCs with a variety of customers (retail, financials, entertainment, etc.), but the quote that really jumped out at me concerning POCs was "unbeaten on performance". The performance results I saw were impressive (though I honestly don't expect them to show me the unimpressive ones). To their credit, there were a couple queries in the POC results where ParAccel was not faster, and those were not redacted. A good sign if you ask me. Cynically, however, I have to wonder: if they're not getting beaten on performance, where are they getting beaten? ;-)

Reference Customer


Late last year ParAccel announced its first (as far as I'm aware) reference customer, namely Merkle. Interestingly Merkle selected ParAccel to replace an in-house data cleansing/integration application, not for reporting/analytics purposes. Said application hasn't been fully ported by Merkle yet, however, so I have a hard time calling this a big win yet. Reportedly, however, Merkle is finding analytic uses for their PA system in the interim. I wonder where they'll ultimately land.

More information about what Merkle has done with ParAccel is available in this TDWI webinar if you're interested.

EMC Partnership


ParAccel's partnership with EMC appears to be serving them well. EMC is inviting them to POCs, which can't be a bad thing. This makes imminent sense, really, as any deal won by one of the database vendors with embedded storage (e.g. Netezza, Exasol, Dataupia, etc.) means a deal with no money in it for EMC. I don't know yet, however, how many of those POCs ParAccel has won, though I think there has been at least one.

Technical Tidbits


Though our conversation was sales-and-marketing heavy, I did glean a few interesting technical tidbits.

• ParAccel compiles queries. Given the obvious connection between ParAccel and Netezza this isn't really surprising though.
• ParAccel supports SQL extensions via "custom C functions". I look forward to learning more about this.
• ParAccel uses a proprietary interconnect protocol to reduce packet loss and improve the performance of inter-node communications.
• ParAccel's support for Microsoft and Oracle SQL extensions is strong enough that POCs often involve "no rewriting of SQL".

More information is available in a soon-to-be-released "technical overview" whitepaper. I got a peek, and it's well worth reading - check it out when it becomes available.

Parting Thoughts


I tend to put more emphasis on how somebody says something than what they actually say; something like 90% of interpersonal communication is non-verbal, after all. And while it's certainly a VP of Marketing's job to put on a good face, Kim's general demeanor struck me as unusually relaxed and quietly confident. That, together with their forthrightness about situations where ParAccel isn't faster than the competition, gave me the sense that things are going pretty well for ParAccel. Companies who are confident about their strengths generally don't hide from their weaknesses, in my experience.

Only time will tell.

Kognitio Lands Semi-interesting Client

Kognitio announced yesterday that the National Center for Genome Resources has "deployed Kognitio's WX2 purpose-built database". I find this semi-interesting for two reasons:

• "Deployed" is very different than "selected"
• I'm a bit tired of hearing about "enterprises" who have "selected" a particular MPP database for this that or another. This isn't really Earth-shattering news either, but at least it's a bit different.

Now, I don't know the first thing about genome research, but I do know that at least one MPP vendor has added functionality specifically for genome research clients. As such I wondered whether Kognitio had done the same to close the NCGR deal. When asked, however, the folks at Kognitio said that "NCGR [is] using pure SQL as they migrate over". I'm not sure that means that NCGR is doing the same old boring SQL stuff as everybody else or that MPP databases have finally matured to the point that you can write the complex (and often ugly) SQL queries that mature OLTP systems have been supporting for years. My guess is that the answer is somewhere in the middle.

Like I said... semi-interesting.

Confessions of an Old SQL Hacker: I Like ANSI Joins

For longer than I care to remember, I've been writing joins like so:

SELECT col1, col2 -- Boo on "SELECT *"!
FROM T1, T2
WHERE T1.x = T2.x

Over the last six months or so, however, I've found myself forced to used outer joins (which are evil, but that's another story) and thus having to write queries like this:

SELECT col1, col2 -- Seriously, "SELECT *" is for rookies
FROM T1
LEFT OUTER JOIN T2 ON(T1.x = T2.x)

Then, to keep things consistent (think self-Romanism) inner joins obviously get written like this:

SELECT col1, col2 -- Did you really think I was going to use "SELECT *"?
FROM T1
INNER JOIN T2 ON(T1.x = T2.x)

What's shocking about this is that I find myself liking this syntax. It's much clearer, at least in my opinion, especially when joining more than two tables or when there's more than one join criteria between two tables. Further, it separates the join criteria from the "filter" criteria, i.e. what's in the WHERE clause is only what belongs in the WHERE clause. Consider:

SELECT col1, col2 -- You get the point
FROM T1, T2, T3, T4
WHERE T1.x = T2.x
AND T2.x = T3.x
AND col3 = 'foo'
AND T3.x = T4.x
AND T2.y = T3.y

vs.

SELECT col1, col2 -- I hope you do anyway
FROM T1
INNER JOIN T2 ON(T1.x = T2.x)
INNER JOIN T3 ON(T2.x = T3.x AND T2.y = T3.y)
INNER JOIN T4 ON(T3.x = T4.x)
WHERE col3 = 'foo'

See the difference? Join criteria are forced to be grouped together logically, and the WHERE clause is cleaner. It's hard not to like it.

And it beats the hell out of the old Oracle outer join syntax. 'nuf said on that subject - you either know what I'm talking about or wouldn't believe that I was quoting real syntax. Anyway...

There you have it. I like the ANSI join syntax. I admit it.

I guess you can teach an old dog new tricks.

Vertica Offers Two-Day Training Class in April

I must be blind, because I can't find a link to this anywhere on Vertica's site, but... Vertica is offering a two-day training program in early April that looks very interesting. For details see http://www.vertica.com/vertica-training.

Given my proximity to Billerica I might just have to go to this... I just have to convince my CFO to pay for it. :-P

Things That You Just KNOW Ain't Gonna Happen

I received an interesting email from a database vendor this morning. Shortly afterword I received another from the same vendor that said this:

Dear Thomas

I believe you received this communication in error. I would kindly ask that you delete it immediately.

Sorry for the inconvenience.


I hadn't exactly scrutinized the original email, but you can be damn sure I went back and read it after I got that second one.

(Did you really think I would just blithely delete it? Please.)

It was all pretty positive and interesting stuff. I look forward to them releasing it publicly.