[Date Prev][Date Next]
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?
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.
Systems Software Engineer
--On Thursday, February 07, 2002 22:45:16 +0000 Dan Melomedman
Michael Cunningham writes:
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.