I doubt that Elephant on postmodern is going to be faster than using
CL-SQL to do direct ORM against Postgresql. Despite the great work
that Henrik and others have done with Postmodern, there are too many
layers of abstraction in the architecture to overcome. The real point
of using Elephant is ease of use, rapid prototyping and the
programming API, not absolute performance.
I do suspect that raw performance (using BDB) may be comparable or
better to any SQL/ORM solution for some simple access patterns, but
for complex queries and joins SQL is probably the better way to go.
We have already seen various comments on the list about common
features of SQL databases that Elephant is missing (like getting a
COUNT without generating all the objects).
As for using BDB to do replication and distributed transactions - it's
possible but no one has tried it. Elephant would need some serious
modifications as the transaction protocol is different and I think
that you'd have to build your own Global Transaction Manager either in
Lisp or as an additional C daemon.
It's also possible that there are architectural or performance issues
in using Postgresql across multiple machines of which I am unaware -
hopefully one of the PG experts will comment.
Ian
On Feb 20, 2008, at 9:47 PM, [EMAIL PROTECTED] wrote:
Well, this is certainly interesting, since this would allow me to
decouple the storage system from the lisp environment allowing the
possibility of setting up a cluster of lisp machines to handle
application logic. Isn't there a way to achieve this on BDB?
We prefer to deploy our systems on clusters of "inexpensive"
machines in order to leverage hardware failures and it seems that
scalability of BDB/Lisp applications is achieved by scaling a single
machine.
Now, postmodern being 4x slower could be an issue. However, how does
that compare to a regular CL-SQL and relational queries is a
different story. If postmodern is about the same speed as hitting
Postgres with CL-SQL and just using plain SQL instead of elephant,
at the end of the day, that's the performance our users are getting
anyway :)
Thanks,
Waldo
Since Postgres does allow for features such as replication,
clustering, and fail-over with multiple active simultaneous client
connections, does this mean that I could have multiple (separate)
lisp clients using elephant connecting to a separate Postgres
cluster with no concurrency issues?
Yes.
You can do this on BDB, but only on the same system as it relies on
shared memory locks between processes. This helps for multi-CPU
systems (one lisp process per CPU) but not for distributing
Elephant across
Thanks,
Waldo
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
