McObject and eXtremeDB
I talked with McObject yesterday. McObject has two product lines, both of which are something like in-memory DBMS — eXtremeDB, which is the main one, and Perst. McObject has been around since at least 2003, probably has no venture capital, and probably has a very low double-digit number of employees.*
*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.
Comments
11 Responses to “McObject and eXtremeDB”
Leave a Reply
Thanks for the opportunity to talk yesterday, and this blog entry, Curt. I’d like to expand on a couple of points in your write-up.
Rather than being “something like” an in-memory database system, eXtremeDB is unequivocally an in-memory database system. Unlike some other technologies out there, eXtremeDB was written from the ground up to be an IMDS.
McObject was started, and eXtremeDB was launched, in 2001. Our high availability edition was released in 2003, which is probably where you got that date from. You’re right, we chose not to pursue venture capital when we started 10 years ago. McObject has grown by every metric, every year: customers, revenue, head count,… through some pretty bad economic conditions. We have over 300 licensees in 33 countries that have released around 20 million systems with our database systems embedded in them.
Lastly, eXtremeDB is not an object-oriented DBMS. It can’t be put in the group that includes Objectivity, Versant, ObjectStore, et. al. We take an object-oriented approach to using the database, but the database system doesn’t support inheritance, polymorphism, etc., and the native programming interface is C. We also offer C++, JNI and C# interfaces (and ODBC/SQL and, soon, JDBC), but they all operate through our C libraries.
I look forward to talking with you again.
Steve Graves
McObject
Steve,
Thanks for the clarifications!
My “something like” was meant in three ways:
1. To challenge whether ExtremeDB, out of the box, is a full DBMS at all (I don’t know).
2. To acknowledge that it is now hybrid memory-centric.
3. In anticipation of your not-exactly-an-OODBMS distinction.
I’m still not quite clear about the difference between this and ObjectStore.
In ObjectStore, if there is enough main memory on the machine to hold the database, the database is all in main memory. That is, nothing is written to disk except the cache. We didn’t call it an “in-memory DBMS” merely because when it was first designed (1989), people mostly needed databases that were bigger than the amount of main memory that machines of he time had. Nowdays it’s common for machines to have far more main memory than machines did back then, so more applications have databases that fit entirely in main memory, but that’s just quantitative. If there’s a qualitative difference, I’d appreciate understanding it better.
I should also clarify the sense in which ObjectStore is object-oriented. The database system is modularity divided into two layers: the storage layer, and the language layer. The storage layer did not deal in inheritance, polymorhism, and such. That was all in the programming language layer. The storage system worked at the level of blocks of memory. The server, in fact, has no programming language layer at all.
ObjectStore supported C++, but it worked just fine if you restricted yourself to the subset of C++ that is C. The lanaguage layer was needed mainly so that ObjectStore would know which words in the stored data were pointers, so that the pointers could be converted to the appropriate virtual memory addresses when the block was mapped into memory. Without that facility, the mapping between stored data and addressible data would have to be one-to-one, which would make it impossible to have a database that did not fit into virtual memory. These days, allowable virtual memory is higher than it was then, so this is less of an issue, and the language layer could be eliminated.
So I don’t think the differences are as fundamental as they might, at first, appear.
Is eXtremeDB a full DBMS? In the absence of a definition of what constitutes a “full DBMS”, my answer is yes. It has a data definition language, transactions that enforce the ACID properties, the means to create relationships (either object-identifiers and references, or primary and foreign keys), and SQL if you choose to use that interface. What it isn’t is a full-on client/server DBMS. Though it does have some capability for that, it isn’t the primary focus. Being an embedded database system is the primary focus. It is somewhat the opposite of MySQL, in that regard. MySQL is primarily a client/server DBMS, with some ability to be embedded. eXtremeDB is primarily an embedded database system, with some ability to be client/server.
Daniel, the “hybrid” characterization has likely caused some confusion. eXtremeDB Fusion is hybrid in the sense that, in the data definition language, you can indicate on a table-by-table basis whether a table is ‘transient’ or ‘persistent’. A transient table is 100% in-memory. A persistent table is cached with other persistent tables. The persistent part of eXtremeDB is much like any other disk-based DBMS; the developer creates a cache of some size determined by him/her, and eXtremeDB Fusion will keep objects in the cache via a least-recently-used (LRU) algorithm, which can optionally be influenced by a cache prioritization scheme.
So, an eXtremeDB Fusion hybrid database will have at least four logical database devices: A memory device for the in-memory (transient) tables, a memory device for the cache for persistent tables, a file system device (or devices) for the database file(s), and a file system device for the persistent tables’ transaction log. It’s important to point out that in-memory tables don’t automatically “spill over” to persistent tables. They are distinctly different entities. Transactions can involve in-memory and persistent tables.
As I recall, ObjectStore had a “pointer swizzling” scheme to create a database larger than available memory. eXtremeDB does not do this. With eXtremeDB, if you want a 100MB in-memory database, it is up to you to allocate 100MB of local- or shared-memory. If you fill up that memory, eXtremeDB will put the transaction that caused the overflow into an error state (so subsequent attempts to put data in the database within the same transaction don’t crater the application), and the application program must deal with it, either by pruning the database to create space, or by extending the size of the in-memory database (allocating more memory). Thus, eXtremeDB never swaps data in/out of memory; it’s all in memory, all the time, and the performance is constant. So, the qualitative difference is two-fold: 1) constant performance, and 2) better performance derived from knowing that the data is in-memory (i.e. no pointer swizzling and/or swapping pages in/out of virtual memory).
[…] for example, my recent tweak of McObject, for not being willing to quickly run through basics such […]
Time to time, there has been some confusion regarding to table types of in-memory databases. Some people have understood that in-memory tables are something that disappear in failure or in server shutdown. Probably needless to say, this is not true, although the claim has been widely spread at least some time ago, for example, in wikipedia.
solidDB supports three in-memory table types: temporal (not persistent, private for connection), transient (not persistent, for multiple clients), and persistent. I’m not sure if the table type labels of other products match with those of solidDB’s.
@Vilho, what exactly is an in-memory persistent table in SolidDB? Is it different than how I characterized eXtremeDB Fusion persistent classes (tables)? “…The persistent part of eXtremeDB is much like any other disk-based DBMS; the developer creates a cache of some size determined by him/her, and eXtremeDB Fusion will keep objects in the cache via a least-recently-used (LRU) algorithm…”
Steve, rows of a persistent table are stored in in-memory storage, always. They are made persistent through the use of logging, and checkpointing. To provide constant, predictable performance for each row, solidDB doesn’t drop in-memory data away from memory.
@Vilho,
Okay, thanks for the clarification. We do use terminology differently in our respective products. The functionality you describe is our eXtremeDB In-Memory database system in combination with the eXtremeDB Transaction Logging module.
[…] did something cool with Patricia tries years ago. McObject and ScaleDB tried them too. Few people noticed or […]
[…] did something cool with Patricia tries years ago. McObject and ScaleDB tried them too. Few people noticed or […]