CLOS persistence
in [Lisp]
|
From: vtail on 2 Jan 2008 02:54 Happy New Year group, I would appreciate comments on existing CLOS persistence libraries, in particular elephant vs cl-perec: how reliable/fast each one is, how large is the user base, how active are maintainers etc. For elephant in particular, I'm also interested in performance of Postgresql backend vs BerkeleyDB. My use case is a multi-user web-based app (I'm porting existing Perl/ MySQL application), and I would need performance that is not far worse then that of a existing system. I'm using SBCL on linux-amd64. I'm aware of AllegroCL/AllegroCache, but I'm only considering free implementations at that point. Thank you very much, Victor.
From: levy on 2 Jan 2008 07:37 On jan. 2, 08:54, vtail <victor.kryu...(a)gmail.com> wrote: > Happy New Year group, > > I would appreciate comments on existing CLOS persistence libraries, in > particular elephant vs cl-perec: how reliable/fast each one is, how > large is the user base, how active are maintainers etc. For elephant > in particular, I'm also interested in performance of Postgresql > backend vs BerkeleyDB. > > My use case is a multi-user web-based app (I'm porting existing Perl/ > MySQL application), and I would need performance that is not far worse > then that of a existing system. > > I'm using SBCL on linux-amd64. I'm aware of AllegroCL/AllegroCache, > but I'm only considering free implementations at that point. > > Thank you very much, > Victor. I am one of the authors of cl-perec, so I can answer your questions about it. The good news: We are using it currently in exactly one production system (with a few thousand users, one hundred persistent classes some of which has a million instances) without any issues so far. There's a quite good test suite in the repository which assures us not breaking things with changes. Of course we are continuously maintaining it and also have some minor developments in mind and willing to take into consideration users' needs too (well if there were any ;-). Read performance is not bad at all, because cl-perec gives a quite good RDBMS mapping for the CLOS classes you define. You can use the provided query compiler, write your own SQL queries or even mix the two. Using CLOS is still possible even if you have some hand optimized queries and lazy loading will work from that. Write performance is not optimized that much and I know a couple of ways how to improve it, but remember that in the worst case you can always execute an SQL batch update. The bad news: AFAICT the user base is practically zero, we had as much as three users who were able to set it up and give it a try. Unfortunatly we don't exactly know how far did they get with it. Well, as you probably know there's no documentation other than a few hundred test cases. levy
From: vtail on 2 Jan 2008 12:22 On Jan 2, 6:37 am, levy <levente.mesza...(a)gmail.com> wrote: > On jan. 2, 08:54, vtail <victor.kryu...(a)gmail.com> wrote: > > > > > Happy New Year group, > > > I would appreciate comments on existing CLOS persistence libraries, in > > particular elephant vs cl-perec: how reliable/fast each one is, how > > large is the user base, how active are maintainers etc. For elephant > > in particular, I'm also interested in performance of Postgresql > > backend vs BerkeleyDB. > > > I'm using SBCL on linux-amd64. I'm aware of AllegroCL/AllegroCache, > > but I'm only considering free implementations at that point. > > I am one of the authors of cl-perec, so I can answer your questions > about it. > > The good news: We are using it currently in exactly one production > system (with a few thousand users, one hundred persistent classes some > of which has a million instances) without any issues so far. There's a > quite good test suite in the repository which assures us not breaking > things with changes. Of course we are continuously maintaining it and > also have some minor developments in mind and willing to take into > consideration users' needs too (well if there were any ;-). > > Read performance is not bad at all, because cl-perec gives a quite > good RDBMS mapping for the CLOS classes you define. You can use the > provided query compiler, write your own SQL queries or even mix the > two. Using CLOS is still possible even if you have some hand optimized > queries and lazy loading will work from that. Write performance is not > optimized that much and I know a couple of ways how to improve it, but > remember that in the worst case you can always execute an SQL batch > update. > > The bad news: AFAICT the user base is practically zero, we had as much > as three users who were able to set it up and give it a try. > Unfortunatly we don't exactly know how far did they get with it. Well, > as you probably know there's no documentation other than a few hundred > test cases. > > levy Thank you for your answers, Levy. Congratulations on winning the contract - it is impressive what you have done under such time constraints! If it's appropriate to ask - what was the reason for writing cl-perec in the first place (versus using elephant)? I understand that your time constraints were pretty tight so you most likely have studied all the available options before rolling your own thing... Best Regards, Victor.
From: levy on 3 Jan 2008 04:42 On jan. 2, 18:22, vtail <victor.kryu...(a)gmail.com> wrote: > Thank you for your answers, Levy. > > Congratulations on winning the contract - it is impressive what you > have done under such time constraints! > > If it's appropriate to ask - what was the reason for writing cl-perec > in the first place (versus using elephant)? I understand that your > time constraints were pretty tight so you most likely have studied all > the available options before rolling your own thing... > > Best Regards, > Victor. Obviously we have not written cl-perec in that three months but in the past two years (with many other things in parallel). At that time elephant was in a very early stage and it's RDBMS mapping was well at least hard to explain to people. I don't know if that changed by now but I don't think so. The BDB backend was not an option due to its licensing and the fact that most people here are happy when they see their data stored in RDBMS rather than in X. There was clsql and allegrocache too and I evaluated both. Allegrocache was 1.0 at that time and had some very nice features but we decided not to use it due to its price and not being RDBMS based. Using lisp in itself is enough to explain and we didn't want to go into this other issue. As for clsql we had quite a few problems with it (and it's not really a CLOS persistence layer), enough to roll our own RDBMS layer called cl-rdbms. levy
From: Leslie P. Polzer on 3 Jan 2008 07:14
On Jan 2, 8:54 am, vtail <victor.kryu...(a)gmail.com> wrote: > Happy New Year group, > > I would appreciate comments on existing CLOS persistence libraries, in > particular elephant vs cl-perec: how reliable/fast each one is, Elephant has a large test library to ensure reliability. Elephant is easy to use for CLOS because of its MOP framework. > how large is the user base, Elephant is probably the most popular. By the way, have you looked at cl-prevalence? > how active are maintainers etc. A bunch of knowledgeable people are on the list. Ian Eslick, the most active one, is answering questions quickly. There's a Trac system with a roadmap. > For elephant > in particular, I'm also interested in performance of Postgresql > backend vs BerkeleyDB. > My use case is a multi-user web-based app (I'm porting existing Perl/ > MySQL application), and I would need performance that is not far worse > then that of a existing system. IIRC the Elephant docs say that performance is best with BDB and others are slower by a factor of three (check them out to verify this). The only way to find out whether a given library satisfies your performance needs is to try it. IMO the only disadvantage of Elephant is the one cited by levy: Elephant abuses relational databases as flat key-value-databases. But there's also a native SEXP backend in development for Elephant. Leslie |