Back to index
The ObjectStore Database System
Charles Lamb, Gordon Landis, Jack Orenstein, and Dan Weinreb
Summary by: Steve Gribble and Armando Fox
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
- 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++
- Versioning is supported for cooperative/groupware apps.
- 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
- 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
- Example apps based on ObjectStore
- performance benchmarks
- extensible C++ object class
Good idea - language support for persistent storage access is a great idea.
- 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.
Back to index