Intersystems Cache’ highlights
I talked with Robert Nagle of Intersystems last week, and it went better than at least one other Intersystems briefing I’ve had. Intersystems’ main product is Cache’, an object-oriented DBMS introduced in 1997 (before that Intersystems was focused on the fourth-generation programming language M, renamed from MUMPS). Unlike most other OODBMS, Cache’ is used for a lot of stuff one would think an RDBMS would be used for, across all sorts of industries. That said, there’s a distinct health-care focus to Intersystems, in that:
- 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.
Comments
2 Responses to “Intersystems Cache’ highlights”
Leave a Reply
From personal experience, I will suggest that you inspect their insert performance claims closely.
That performance might come from disabling transactions and using asynchronous disk writes or the file system cache. Which would put the configuration at exactly how other RDBMS vendors handle BLOBs. Which would explain why anyone would think to compare insert performance of records in one DBMS to that of BLOBs in another.
Having those configuration options is good. But let’s just say that I have been annoyed by the way they phrase various claims in their sales pitch.
They did have a good looking API for doing high speed data inserts via shared memory. But again, something that should be revealed as part of a performance comparison since use of this API involves tradeoffs.
Also, the event system that I saw at that time worked like this:
1) insert event as a record
2) fire the equivalent of a post-insert trigger
The triggers were coded in MUMPS, so it is possible that now they are coded in Java. I sort of liked their trigger mechanism, but it’s not really comparable to what a CEP engine does.
And note that all data in Cache is stored as text. Even numbers, which are automatically converted every time a calculation is done. I’m not judging this, just pointing out an interesting fact.
If you’re into the tech details, it’s fun to learn a about how Cache works. They have very interesting and sometimes unique approaches to handling DBMS functionality.
Hans,
You raise excellent points. I hope somebody from the company addresses them.
Thanks,
CAM