The ObjectStore Database System

One-line summary: ObjectStore is an OO DBMS which very tightly couples a C++/C language interface to traditional DBMS qualities such as persistent storage, query access, and transaction management; OS virtual memory support is heavily used to gain object access speed usually equal to in-memory derefernce times.

Overview/Main Points

• C++ integration yields:
  • easy learning, expressive power of C++
  • type checking compiler support for both code and data in the database
  • ease of conversion from transient code (eg in-memory DB) to persistent code
• A nice, rich, flexible application interface is shown. Support for collections (lists, bags, sets, ...), simple transaction syntax, ease of access to persistent data (looks just like a structure dereference), "relationships" in which if one value in a structure is modified, the related value in a related structure is automatically updated.
• Flexible query interface - looks like SQL code embedded in C++ code.
• Versioning is supported for cooperative/groupware apps.
• Architecture
  • memory-mapped architecture - large virtual memory space is what app writer sees; DB split into a number of separate address spaces, and an overlay-like technique used to multiplex among them.
  • pointer relocation techniques are used to map between objects' virtual addresses and the values of object pointers inside pages.
  • "tag table" keeps track of the location and type of every object in database - used when mapping a page into a virtual address space and pointer relocation is needed.
  • Applications can give clustering hints so that objects that are frequently accessed together end up on same page.
• Queries
  • indexes and a query optimizer are used
  • in ObjectStore, collections are often not named, so available indexes are not discovered until the time at which query is run, so multiple access path strategies must be generated and the final selection left until the last moment.
  • claim is that queries in ObjectStore are usually over small number of top-level (nonembedded) collections, and thus join optimization (a la conventional DBMS's) is not as important.
  • query parse trees can be contructed at compile-time, not run-time as in DBMS. Functions can be constructed at compile time for scanning data structures and accessing data through an index.
  • index maintenance is difficult - consider statement p->age = p->age+1; - if p->age is really modifying persistent data in a structure, many index entries may need to be updated because of this statement. Language support is added to C++ so programmers can indicate which variables are indexable.
• Example apps based on ObjectStore
  • performance benchmarks
  • extensible C++ object class

Relevance

Flaws

• costs are hidden from programmer - a seemingly innocuous C++ statement could be extremely expensive
• distributed implementations are mumbled about, but nothing of substance is actually said about them
• detailed cost analysis/measurements are omitted
• too much generality? I'll bet knowledge of application semantics required could make this more efficient on a per-application basis.