[elephant-devel] Statice and FramerD

[Ian Eslick]

I just was talking with Howie Shrobe today, a colleague who actually 
hacked on Statice back when he was at Symbolics.  It sounds like they 
did default object indexing (all objects had a class index that referred 
to them) and was pretty hairy under the hood due to some technical 
politics.  Zach's comments are consistent with what Howie told me. 

We talked a bit about GC and he said that there is a real problem 
defining reachability in a multi-user DB.  GC might make more sense in 
solo mode, but requires hooking into the running image to determine what 
references are in memory that aren't yet in the root index.  The only 
obvious way to be sure you can GC is to disconnect everyone from the DB 
(as if you were doing recovery) and do reachability from all root 
indices to mark objects as live.

I also had a chance encounter with Ken Haase, the author of FramerD - an 
object database intended for doing knowledge representation and he 
brought up a few design issues that he found important:

1) Derived feature indices (Elephant's secondary indices provide good 
support for this)
2) Appending values.  Sleepycat allows duplicate keys in secondary 
indices so
    if we want to index on values and two values share the same date, 
for instance, then
    there are two btree key/value entries.  In FramerD he had unique 
keys and, much like in
    a hash collision, recorded the new value by appending it to an 
array/list within the btree
    without having to update the BTrees.  Without this duplicate keys 
can be expensive.  His
    worry was having to read the whole list that collided, add an 
element, and write it back.
3) Lightweight objects (Elephant does this right by keeping only oids in 
memory and doing
    slot read/writes via the btrees)

I'll try to pick his brain on query methods and optimization the next 
time he drops in.

Ian

Zach Beane wrote:

>On Tue, Jan 24, 2006 at 11:43:16AM -0500, Ian Eslick wrote:
>
>  
>
>>That reminds me.  Without GC and/or renaming oids we'll eventually run 
>>out of OID address space, again when the DB gets enough use.  I haven't 
>>seen any provisions for fixnum wrap-around.  Am I missing something or 
>>is this correct?
>>    
>>
>
>This isn't a direct comment, but I recently came across this book:
>
>   http://www.amazon.com/gp/product/0136298338/102-6097685-4704118
>
>It has a concise but interesting chapter on the design and
>implementation of the Statice database. You can also find it on
>Abebooks for $1.
>
>I don't have it in front of me, but IIRC it described Statice OIDs as
>96 bit and intended to be unique across space and time. It also said
>that the database was *never* garbage collected.
>
>Zach
>
>_______________________________________________
>elephant-devel site list
>elephant-devel at common-lisp.net
>http://common-lisp.net/mailman/listinfo/elephant-devel
>  
>