Starcounter high-speed memory-centric object-oriented DBMS, coming soon
Since posting recently about Starcounter, I’ve had the chance to actually talk with the company (twice). Hence I know more than before. 🙂 Starcounter:
- Has been around as a company since 2006.
- Has developed memory-centric object-oriented DBMS technology that has been OEMed by a few application software companies (especially in bricks-and-mortar retailing and in online advertising).
- Is planning to actually launch an OODBMS product sometime this summer.
- Has 14 employees (most or all of whom are in Sweden, which is also where I think Starcounter’s current customers are centered).
- Is planning to shift emphasis soon to the US market.
Starcounter’s value propositions are programming ease (no object/relational impedance mismatch) and performance. Starcounter believes its DBMS has 100X the performance of conventional DBMS at short-request transaction processing, and 10X the performance of other memory-centric and/or object-oriented DBMS (e.g. Oracle TimesTen, or Versant). That said, Starcounter has not yet tested VoltDB. Starcounter does not claim performance much beyond that of disk-based DBMS on analytic tasks such as aggregations.
The key technical aspect to Starcounter is integration between the DBMS and the virtual machine, so that the same copy of the data is accessed by both the DBMS and the application program, without any movement or transformation being needed. (Starcounter isn’t aware of any other object-oriented DBMS that work this way.) Transient and persistent data are handled in the same way, seamlessly.
Other Starcounter technical highlights include:
- Starcounter is focused on OLTP (OnLine Transaction Processing).
- The Starcounter OODBMS is ACID-compliant.
- The Starcounter DBMS is single-server, albeit multi-core. Starcounter thinks this is OK because the Starcounter DBMS can do millions of transactions per second on a server with 8 cores or less. (I neglected to ask how quickly Starcounter thinks RAM would fill up on a single server at that kind of update rate.)
- A Starcounter database sits in RAM. Logs go to disk, and Starcounter doesn’t commit a transaction in RAM until there’s been an acknowledgement that it’s been logged to disk.*
- Since Starcounter never wants to read from disk (except in the case of recovery), logs can be written pretty much at sequential/batch update speeds.
- You can do SQL queries against Starcounter objects, based on T-tree indexes. Otherwise, Starcounter data manipulation is done via what effectively is a proprietary object-oriented data manipulation language. (I neglected to ask whether there was any concept of join, or whether Starcounter SQL just does SELECTs. Starcounter did say that the only schema in a Starcounter database is the object model.)
- Naturally, Starcounter objects are compressed, so that the most possible data fits into the fastest possible tier of memory. Proxy objects also come into play here.
- Starcounter runs on Windows and .NET, supposedly for reasons of better virtual machine performance. Ports to Linux, Java, etc. are on the drawing boards, but won’t be particularly easy.
*I thought Starcounter said that the core that runs the operating system communicates the acknowledgement via Direct Memory Access to a core that runs the Starcounter DBMS, obviating the need for an interrupt (except to the core that runs the operating system). But upon reflection, that doesn’t really seem to make sense.
Comments
3 Responses to “Starcounter high-speed memory-centric object-oriented DBMS, coming soon”
Leave a Reply
Curt,
if I may clarify three things.
1) Starcounter support SQL queries including joins, both traditional joins and implicit joins using path expressions.
2) The manipulation of data in the database is done using native language operations in your programming language, as for example the new operator and variable assignments.
3) Starcounter writes to the transaction log on disk using Direct Memory Access.
Kind regards
PhD Peter Idestam-Almquist
CTO Starcounter
Curt,
Let’s hope all transaction aren’t inserts. Then we’ll be in trouble.
/ Jack
Peters comment about the join is important to us. Starcounter is not an really an ODBMS. Its data operates on a UNION of the following constructs:
1. The relational tuple
2. The object
3. The graph node
4. The key/value store
5. The document element (both structured and unstructured)
It uses a single unified model. Actually, the union of the these entities has no real contradiction. We will not abide to any single religion. We will love them all with equal passion. We are working on a JSON access layer to be binary compatible with CouchDB as well as an ODBC driver that allows us to be a SQL-92 RDBMS.