*The comment threads are the most informative parts of those posts.

I’m a little unclear as to the Netezza Migrator details, not least because Netezza folks don’t seem to care too much about Netezza Migrator themselves. That said, the core ideas of Netezza Migrator are: 

• Netezza Migrator is an enhanced (?) version of EnterpriseDB’s Postgres Plus Advanced Server DBMS. (Recall that Postgres Plus is PostgreSQL-based and fairly Oracle-compatible.)
• Netezza Migrator does not run on Netezza appliances, but rather on conventional computers off to the side.
• Netezza Migrator generally farms out queries to Netezza appliances, but can also manage data itself. (That latter part could supposedly come in handy for small tables one might want to execute stored procedures against.)
• Netezza Migrator does a better job of farming out queries (and also inserts/updates/loads) to Netezza appliances than an Oracle DBMS would. The two biggest examples of that are:
  • Oracle will farm out SELECTs, but not JOINs.
  • Oracle won’t invoke Netezza’s parallel/bulk load capabilities.

• Nothing in my original short post about Clustrix was actually incorrect.
• Clustrix plans to reveal actual production “name-brand” customers soon.
• The name of Clustrix’s software, or at least the guts thereof, is Sierra.
• Clustrix’s products have actually been in general availability since last quarter, with some versions at customer sites for 2 years. Development started 3 ½ years ago.
• Clustrix says its technology is for OLTP systems, which it calls “non-batch/non-analytic,” with mixed read/write workloads. All Clustrix’s example target markets are “internet verticals,” such as photo sharing, gaming, social media, e-commerce, etc.
• Clustrix’s heart is in SQL, as is most of its customer base. Clustrix Sierra’s key-value-store option has little or no performance advantage over Clustrix Sierra’s SQL option, nor any other advantage over SQL that came up in discussion.
• Clustrix Sierra is “wire-compatible” with MySQL, but doesn’t use MySQL code; Clustrix wrote all the code itself.
• Clustrix asserts that Clustrix Sierra supports the “vast majority” of MySQL features. Examples of MySQL features Clustrix doesn’t support at this time are full-text search and geospatial indexing.
• Indeed, Clustrix claims Clustrix Sierra can be used to replace MySQL with few or zero changes to existing applications.
• I specifically asked about referential integrity, which has a poor performance reputation in MySQL. Besides saying they supported it, Clustrix said that some customers actually use referential integrity in some of their less active tables.
• Clustrix Sierra is fully ACID-compliant, with no eventual consistency or RYW consistency story. The default number of copies of each datum is two, and they’re kept consistent via two-phase commit.
• Clustrix Sierra is fully parallel, with no “head” node. I forgot to ask how it was determined which queries would be addressed to and/or controlled by which nodes, but I presume there’s some sort of a load-balancing scheme.
• Clustrix says that because Clustrix Sierra uses MVCC (Multi-Version Concurrency Control), and thus reads and writes don’t block each other, global locks aren’t a major issue. (They’re rare or short or something – I have trouble seeing why they would be non-existent.)
• Clustrix says there’s a second class of locks and latches that are purely local and short-lived, for B-tree indexes and the like. (I didn’t drill down into those either.) I guess this means Clustrix Sierra is B-tree-centric, which makes sense for an OLTP-oriented system.
• Clustrix Sierra distributes data among nodes via consistent hashing (default), range partitioning, or “full distribution”(i.e., coping a – presumably small – table to each node). The choice of distribution plans is manual now; more automation is a future feature.
• Clustrix Sierra’s CBO (Cost-Based Optimizer) is, as one would hope, distribution-aware.
• Clustrix Sierra compiles query fragments and ships them off to the relevant nodes. A fragment might contain both instructions for SQL to be executed locally and for where data is to be sent next.
• Clustrix says that Clustrix Sierra does data migration and redistribution (e.g., when you add a node) transparently online, and further says that in practice this doesn’t cause a performance hit.
• As for Clustrix hardware:
  • Clustrix makes Type I appliances.
  • A Clustrix node contains 2 quad-core chips, 32 gigs of RAM, and 7 160 GB solid-state drives.
  • Specifically, Clustrix is using Intel SSDs, with a SAS interface.
  • Clustrix says solid-state memory isn’t really essential to the product design; it’s just cheap in terms of $/IOPS (I/O Per Second).
• A minimum Clustrix configuration is 3 nodes, for redundancy. After that you can add nodes one at a time. Clustrix says it built a 20-node system in-house, leading me to suspect that customers don’t have anything bigger than 20 nodes either.
• That 20-node Clustrix system was tested to show near-linear scalability. (In discussing this, Clustrix tends to forget to use the word “near”.)
• Clustrix has partnered with somebody to provide global 4-hour-response support. As of now Clustrix seems to be active mainly in North America and Europe.
• Clustrix is formed from the combination of two startups, which I’ve heard elsewhere were called Clustrix and Sprout. Exactly when the combination happened sounds a little different depending on who’s telling the story (one version has the predecessors still being separate well into 2008, but Clustrix implies the combination happened pretty much on Day 1).

• MUMPS, the original Intersystems technology, was focused on health care.
• The reasons Intersystems went object-oriented have a lot to do with the structure of health-care records.
• Intersystems’ biggest and most visible ISVs are in the health-care area.
• Intersystems is actually beginning to sell an electronic health records system called TrakCare around the world (but not in the US, where it has lots of large competitive VARs).

Note: Intersystems Cache’ is sold mainly through VARs (Value-Added Resellers), aka ISVs/OEMs. I.e., it’s sold by people who write applications on top of it.

So far as I understand – and this is still pretty vague and apt to be partially erroneous – the Intersystems Cache’ technical story goes something like this:

• Intersystems Cache’ is an object-oriented DBMS.
• The preferred language for talking to Intersystems Cache’ is Java.
• Intersystems claims Cache’ has good SQL performance, for most kinds of use-case.
• Intersystems Cache’ stores data in a kind of sparse hierarchy. It uses a lot of “common character count” compression, which sounds a lot to me like Patricia tries.
• Intersystems has recently bundled some BI/reporting tools into the Cache’ stack. Surely not coincidentally, Intersystems once told me that some of its ISVs paid more to Crystal Reports than to Intersystems.
• Intersystems Cache’ has had Sybase emulation for several years, and just added Informix emulation. Most but not all stored procedures from those other DBMS run against Cache’ as well.
• Intersystems Cache’ recently added a bunch of manageability, security, etc. features, the details of which generally inspired “Oh, you didn’t have that earlier?” reactions in me.
• Intersystems’ just did a revamp of the Cache’ object model to make it more Smalltalk-like, in which messages are set to parent rather than child classes when appropriate. Thus, when you recompile a class, you don’t also have to recompile all its children, and incremental recompilation is now near-instantaneous. (Put that one in the “Oh, you didn’t have that earlier?” category too.) Versioning will be better as well.
• In the latest release, Cache’ has added what Intersystems calls “Java Event Processing.” This doesn’t sound like CEP (Complex Event Processing), and I forgot to ask whether it was memory-centric at all. Anyhow, the idea is to bang objects into the database really quickly, having them be immediately available for SQL query. “Really quickly” means >10,000 objects/core/second, with one test at the European Space Agency getting up to 85,000. By way of contrast, Intersystems asserts (based on bake-offs) that RDBMS competitors have to insert into BLOBs to get competitive performance, with associated loss of queryability.

Finally, a few financial highlights:

• Intersystems did a little over $1/4 billion in revenue in 2009.
• 85% of that was Cache’.
• Revenue growth was slightly positive in 2009, and 15% in 2008.
• Headcount growth was 25% in 2009 and is planned to be big again in 2010, after being modest in prior years.

]]> http://www.dbms2.com/2010/01/15/intersystems-cache-highlights/feed/ 3 http://www.dbms2.com/2009/08/05/dataupia-is-officially-for-sale/ http://www.dbms2.com/2009/08/05/dataupia-is-officially-for-sale/#comments Wed, 05 Aug 2009 16:46:34 +0000 Curt Monash http://www.dbms2.com/?p=862 Dataupia marketing VP Samantha Stone — who by the way has been one heck of a trooper through Dataupia’s troubles — is joining the exodus from the company.  General graciousness aside, the heart of Samantha’s farewell email reads:

Unfortunately, we have had to reduce our burn rate as we seek an acquirer for our technology.

We have a group of loyal employees remaining on staff focused on current production customers and the acquisition efforts.

As part of the most recent staff reductions I will be leaving Dataupia.

Two years ago I wrote:

[Dataupia would] make a great acquisition for a BI company or DBMS vendor who could then say “Oh, no, this isn’t a DBMS appliance – it’s merely a data warehouse accelerator.” When you look at it that way, their chances of prospering look distinctly higher.

But at this point I think there probably would be more appealing ways for those vendors to meet the same needs.

]]> http://www.dbms2.com/2009/08/05/dataupia-is-officially-for-sale/feed/ 13 http://www.dbms2.com/2009/06/10/two-lessons-from-dataupias-troubles/ http://www.dbms2.com/2009/06/10/two-lessons-from-dataupias-troubles/#comments Wed, 10 Jun 2009 17:39:59 +0000 Curt Monash http://www.dbms2.com/?p=810 I’ve been beating my head against the wall trying to convince startups of two well-established truisms:

• Experience consistently shows that the demand for transparency/emulation features isn’t as great as entrepreneurs hope.
• If a startup’s competitors sell directly to enterprises, an indirect sales strategy rarely succeeds.

Maybe one or the other will learn from Dataupia’s example.

The article goes on to discuss difficulties Dataupia has had in raising another round of financing.  During Dataupia’s very long CEO search — which I kept hearing about from people who’d been approached for the job — it was obvious money wouldn’t come in until a CEO was found. But it seems that even with a new CEO, existing investors are reluctant to re-up without a new investor as well, and that new investment is slow in happening.

On the plus side, the article quotes Samantha as saying founder Foster Hinshaw is recovering well from his heart surgery.

• Articles
• Blogs
• Downloads
• Surprisingly, so far as I can tell, no forums

If you’re a Teradata user, you absolutely should check out Teradata DevX.  If you just research Teradata — my situation — there are some aspects that might be of interest anyway.  In particular, I found Teradata’s downloads instructive, most particularly those in the area of extensibility.  Mainly, these are UDFs (User-Defined Functions), in areas such as:

• Compression
• Geospatial data
• Imitating Oracle or DB2 UDFs (as migration aids)

Also of potential interest is a custom-portlet framework for Teradata’s management tool Viewpoint.  A straightforward use would be to plunk some Viewpoint data into a more general system management dashboard.  A yet cooler use — and I couldn’t get a clear sense of whether anybody’s ever done this yet — would be to offer end users some insight as to how long their queries are apt to run.

Key points include:

• This really is more like Oracle emulation than it is transparency, a term I carelessly used before.
• IBM’s Oracle emulation effort is focused on two technological goals:
  • Making it easy for an Oracle application to be ported to DB2.
  • Making it easy for an Oracle developer to develop for DB2.
• The initial target market for DB2’s Oracle emulation is ISVs (Independent Software Vendors) much more than it is enterprises. IBM suggested there were a couple hundred early adopters, and those are primarily in the ISV area.

Because of Oracle’s market share, many ISVs focus on Oracle as the underlying database management system for their applications, whether or not they actually resell it along with their own software. IBM proposed three reasons why such ISVs might want to support DB2:

• Oracle is expensive. In particular, IBM suggested it is more flexible on licensing terms for resale than Oracle is. I find that easy to believe.
• Hey, there’s a DB2 market or installed base out there of some size — why not address it?
• Acquisition-fueled expansion in applications makes Oracle a much bigger competitor to many ISVs (all around the world) than it used to be before. That one makes all kinds of sense.

And by the way — if I wanted an Oracle-emulating DBMS, I’d feel a lot happier about doing business with IBM than I would with EnterpriseDB.

IBM feels that DB2’s Oracle compatibility is a strict superset of EnterpriseDB’s, which it presumably has carried over more or less in its entirety. I didn’t press too hard for examples of what Oracle emulation DB2 offers and EnterpriseDB doesn’t, but IBM did say something about support for more programming languages. IBM was clear on one broad area where DB2 does not offer Oracle emulation, which is the specifics of various kinds of datatype support or other specialized data access methods. For example, IBM has its own syntax for querying text, geospatial, or XML data, and has not added support for Oracle’s alternative approaches.

*The looseness in that definition highlights a key reason these technologies don’t sell well — it’s hard to be sure that what you’re buying will do a good job of running your particular apps.

This subject comes to mind for two reasons. One is that IBM seems to have licensed EnterpriseDB’s Oracle transparency layer for DB2. The other is that a natural upgrade path from MySQL to Oracle might be a MySQL transparency layer on top of an Oracle base.

At first blush, the Oracle/MySQL possibility could break the mold. Migrating from one product to another product owned by the same vendor is a lot different than migrating from one vendor’s product to another’s. Users have tremendous familiarity with upgrades where one vendor controls both the start and end points of the transition.

On the other hand, the number of cases where a vendor has bought a DBMS product and then migrating a substantial user base over to another DBMS is approximately zero. The template for reasonably successful DBMS vendor consolidations — such as IBM/Informix or Oracle/RDB — is almost always to maintain and enhance multiple product lines side by side.

As for EnterpriseDB/DB2 — if you have an application running on Oracle, why port it to DB2? Unless IBM gets aggressive on its maintenance licensing terms, that won’t even get you much of a first-glance cost saving. And while it’s annoying to do DBA work for two database brands when one will suffice — if you have those Oracle apps already running, then you also already have the DBA resource to keep them going. No doubt there will be situations where this new offering is useful and welcome, but they’ll probably prove to be rather isolated edge cases.

A couple of years ago, I did make a theoretical argument that DBMS portability should become technically easier and hence more widely adopted. But since then I’ve seen very little practical evidence to back it up.

]]> http://www.dbms2.com/2009/04/22/dbms-transparency-layers-never-seem-to-sell-well/feed/ 10 http://www.dbms2.com/2008/07/07/enterprisedbf-oracle-compatibility/ http://www.dbms2.com/2008/07/07/enterprisedbf-oracle-compatibility/#comments Mon, 07 Jul 2008 12:12:43 +0000 Curt Monash http://www.dbms2.com/?p=457 Obviously, I’m poking around EnterpriseDB’s site this morning (in connection with their status as my client, actually). Anyhow, we all know that one of EnterpriseDB’s core claims is great Oracle-compatibility — but what exactly do they mean by that? I found a fairly clearly laid-out answer, as of last year, in this white paper and and — even more simply — in this blog post summarizing the white paper.