[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Backsql faster then sleepycat dbm?

I do not think this is an easy yes or no question. It depends:
What type of database?
What type of ODBC drivers?
Does the database use indexations?
How many joins do you need to construct an attribute?
Where is your database server with respect of the ldap server?
etc
etc
I am currently working on revising back-sql. I haven't submitted any patches yet becuase I'm still working through the bugs (sorry). I am currently working with a sybase back-end (11.9.2.something) with DataDirect Linux ODBC Sybase Drivers, and openldap 2.0.18(?). I can pull 14,157 of around 11 attributes each in around 15 secs. I still have to do some sybase tweaking and work out a few indexations still. I hope to get this well under 10 secs if not 5. Of course I don't feel the ldap protocol should be used for pulling such large quantities of data. If you are planning on truely doing pulls of this size, I would consider another protocol. Under small pulls, you will find the difference nominal.

Of course I must comment (and hopefully not set off a religious war) that speed should not be the only consideration or the reason to keep a legacy system. We decided on using Sybase for many reasons. First of all, data integrity. Sleepycat is more capable of data coruption when filled with large quanitites of data, as apposed with Oracle or Sybase or even postGres. Also there is the consideration of keeping another back up of the LDAP data if it contains data that is not easily reproduced from other systems in an ldif for re-load it. Also since all of our data that used to populate the LDAP is already in Sybase, it also voids up-to-date sync issues (i.e. once data is changed in Sybase, either having to produce an ldif file or initializing a trigger to up date the LDAP via ldapadd or ldapmodify commands or such). I could probably ramble on another hour on our reasoning for choosing this route.

Produceing LDIF files can be a labourous event, even with scripts involved. There are tools like metamerge (www.metamerge.com) that will keep your ldap (whatever backend) sync'd up with a database or such. But still some cases are time and cpu expensive, especially if you are trying to reconcile accross many databases and other directory services. Once again it depends.

I guess I'll conclude knowing I haven't still answered your question. I can only truely suggest you take some time to experiment.

==
Thomas Cramer
Systems Software Engineer
MUSC
http://www.musc.edu

--On Thursday, February 07, 2002 22:45:16 +0000 Dan Melomedman <dmelomed@devonitnet.com> wrote:

Michael Cunningham writes: 
Hiya,

I was wondering if anyone has done any bench marks
regarding using the backsql option/mysql versus sleepycat db.
I am going to have roughly 2k entries in the ldap server with
approximatly 100 attributes each. If it isnt faster.. what would be a
compelling reason to use it over sleepycat.


What would be a compelling reason to use back-sql? back-sql is meant to
be used for legacy data residing in SQL databases (in other words if you
can't move it to LDAP for beureacratical or expense reasons), not as the
primary store. Keep relational data in the relational databases, keep
directory data in it's embedded database. Use back-sql only if you have
to because it's mainly just a hack.  Unless there is a performance
problem with Sleepycat currently (and there have been such, and they were
bugs), I can't see how an SQL database could be performing better (again,
assuming sleepycat stuff is bug free (yeah, right)) when everything else
being equal.  There was a benchmark to see how well back-sql works with
Oracle, you can find a reference to it using CVS viewer at openldap.org.
Guess what, at the time of the benchmark, they found a bug affecting
Berkeley DB's performance. As of now, there are deadlock issues with it
if you follow openldap-devel list.  Personnaly, I will use GDBM until
they completely phase it out of the source tree. It's not as buggy, and
you won't have to recompile your software when your *nix integrator
updates BDB version.
--