*I could be wrong in those guesses; as small companies go, McObject is unusually prone to secrecy games.

As best I understand:

• eXtremeDB is something like an in-memory object-oriented DBMS, designed to be embeddable.
• However, much as with Objectivity and other old-school OODBMS, eXtremeDB winds up being more of a toolkit with which to build DBMS than a full DBMS.
• eXtremeDB has a few indexing schemes. The main one is good old B-trees. One customer wanted Patricia tries, so they’re in there. (Perhaps not coincidentally, solidDB relies on Patricia tries.) At least one wanted R-trees, so they’re in there too.
• eXtremeDB has long had the option of persistent logs.
• eXtremeDB newly has a hybrid memory-centric option, in which you can have more data in the database than fits into RAM.
• eXtremeDB newly has multi-master two-phase-commit clustering.

My guess three years ago that eXtremeDB might emerge as an alternative to solidDB seems to have been borne out. McObject CEO Steve Graves says that the core of McObject’s business is OEMs, in sectors such as telecom equipment and defense/aerospace. That’s exactly solidDB’s traditional market, except that solidDB got acquired by IBM and deemphasized it.

I’ve said before that if I were starting a SaaS effort — and it wasn’t just focused on analytics — I’d look at using a memory-centric OODBMS. Perhaps eXtremeDB is worth looking at in such scenarios.

… a real-time inventory control system which has the following requirements — basically it needs to provide high write-through-rate, and it needs little if any indexing functionality.

1) a central control system records/updates the inventory data (number/weight and etc.) at each room/rack — there exist thousands of racks/rooms

2) sensors (at different rack) also report/update the temperature to the central control system, at rate of approximately 1~2 updates/min — as there are thousands of sensors, the update throughput needs to be high considering the scalability requirement.

3) When some problems happen, we need to roll back the logs (to replay the events and diagnose the root cause).

His questions included:

Memory-centric DBMS or complex event/stream processing (CEP)? Given that the purpose is to record data, and that he wants to record all data rather than engage in immediate data reduction, true DBMS seems like the way to go.

What are the good in-memory DBMS alternatives anyway? He thought McObject’s eXtremeDB was dominant in the market, which surprised me (although McObject does seem to have made a push in Asia). I know long-time leaders TimesTen and solidDB have, since their acquisitions by Oracle and IBM respectively, pulled back from the standalone market. (Their new owners are more interested in front-end caching for Oracle and DB2 respectively.) But I didn’t think the pullback had been that — as it were — extreme.

And while my correspondent didn’t ask this, I’ll add — should he maybe just go with an ordinary DBMS anyway? A couple thousand updates per minute isn’t that forbidding. On the other hand, it might be hard to achieve with conventional DBMS on super-cheap hardware. And a memory-centric alternative that only logs to disk in near-real-time might be plenty good enough for any analytics they want to do.

He was quite frank about wanting to get experience with leading-edge technology, with an eye to deploying it in other use cases.  So it’s reasonable to be pretty general in this whole discussion. With that as background — well, I’ve already given some of my thoughts.  So what are yours?

This was based on documentation and general sleuthing (Dan figured out who McObject got Perst from), rather than hands-on experience, so performance figures and the like aren’t validated. Still, if you’re interested in such technology, it’s a fascinating post.

First, the McObject guys — who also sell a relational in-memory product — have an object-oriented, apparently Java-centric product called Perst. They’ve sent over various press releases about same, the details of which didn’t make much of an impression on me. (Upon review, I see that one of the main improvements they cite in Perst 3.0 is that they added 38 pages of documentation.)

Second, I just got email about something called CSQL Cache. You can read more about CSQL Cache here, if you’re willing to navigate some fractured English. CSQL’s SourceForge page is here. My impression is that CSQL Cache is an in-memory DBMS focused on, you guessed it, caching. It definitely seems to talk SQL, but possibly its native data model is of some other kind (there are references both to “file-based” and “network”.)

• IBM’s acquisition of Solid seems to suggest a focus on DB2 caching rather than the embedded market
• McObject actually has built up something of a customer list, as per the boilerplate on any of its press releases.

And they do seem to have some nice features, including Patricia tries (like solidDB), R-trees (for geospatial), and some kind of hybrid disk-centric/memory-centric operation.