[elephant-devel] Learning about Elephant

John develgenius at gmail.com
Tue Jan 27 16:00:15 UTC 2009


Hi all,

I've recently come across Elephant and have been reading the manual (even
though it claims to be a bit stale). My approach is to read the manual and
then dig into the code to learn more details or discrepancies not
documented/updated on manual. In so far, I have a few questions I wonder if
anyone could answer. I know that most everyone says not to worry about
performance until you really need to, and I agree with that. However, having
in mind realistic potentials or limitations of the framework may allow you
to pre-plan or even decide if Elephant will be a good fit. My particular
interest is Elephant with BDB.

1) Every read/write of pclass slots is done directly from/to the database,
so no in-memory "copy" exists (unless some sort of transient cache slot
model is used). This is good. However, is Elephant "intelligent" enough so
that if you attempt to setf a slot value with the same value stored in the
slot, Elephant will "avoid" the writing to the database, since the value
hasn't really changed? If that's not the out-of-the-box behavior, I pressume
that it would be relatively easy to add this functionality using MOP. I also
assume that doing this will require another read before the write in order
to compare the value to be written, but then again, Elephant claims that
reads are much cheaper than writes.

2) According to Oracle: "Berkeley DB includes support for building highly
available applications based on replication..." (
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/rep/intro.html)
So, I assume that in the event that a single machine becomes unable to
handle the load of a busy application, BDB supports replication to multiple
machines with near-instant replication effects (performance is inversly
proportional to replication speed). So, the question is, can Elephant
accommodate to this model? If I read correctly, the manual states that
elephant maintains a weak hash of persistent objects. So, if BDB is deployed
in a distributed model and Elephant is running in each separate machine, we
could in theory "trust" that the data read/written from/to disk will be all
in sync across all machines (as long as database IO on same object/slot
occurs at a frequency greater than the replication rate). The question I
have is with the weak hash. If a write is made in one machine, the data on
disk is updated across all machines. However, the weak hash remains stale in
the machines were the data was only replicated to. Is this an actual problem
or does Elephant use the weak hash "intelligently" to recover in the event
that the weak hash becomes "unexpectedly" stale?

3) I come from a RDBMS world, so I'm still learning the modalities of
connected objects vs just related rows. So, reading the tutorials you
describe a friends model using PSets. So, imagine a concept similar to
Facebook in terms of a friends database. I have millions of people created
in the system and they all create their list of friends. Some people may
have "few" or no friends while others could have hundreds of thousands of
friends (e.g. Pres. Obama). Are PSets the correct way to model this for
larger number of objects or is there a more appropriate methodology
recommended in Elephant? Obviously the idea behind this is so that you could
perform manipulations on these "friends" relatively easy, such as add/remove
friends or perform global queries as to list all friends of people who are
friends of Pres. Obama. There are references on the list about a query
system being worked on and some vanilla version being available, but
independently of that, I think my question is more related to the object
model implementation. Maybe I'm wrong.

Anyway, thank you for your help in advanced. Look forward to hearing back
from anyone soon and keep learning more about Elephant.

Thanks,
JD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20090127/02ff0142/attachment.html>


More information about the elephant-devel mailing list