directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Henne <j.he...@levigo.de>
Subject Re: [ServerEntry] We may need our own JDBM code base
Date Tue, 12 Feb 2008 08:37:09 GMT
Emmanuel Lecharny schrieb:
> first, I have to told you we didn't received any news from incubator 
> for your code submission. I will try to ping incubator again to see if 
> someting is stalling for a reason or if we have missed some step (I 
> just suscribed to the incubator PMC today, I should have done it 
> sooner, but I think I just forgot to do so and thought I already did 
> it. My bad).
No worries!
> there is a big difference between entries (ldap) and data in a RDBMS : 
> entries are multivalued. This make it more complex to manage such data 
> efficiently in a database, but not impossible. In any case, this is 
> possible.
Without knowing the Derby database layer in detail, this is just a wild 
guess, but it may be possible that from a storage perspective (not the 
indexing perspective, of course) tuples are treated as black boxes, 
which would lessen the difference between tuples and entries. However, 
with large numbers of attribute values it might still be necessary to 
normalize them, as it is currently done.
> We don't want to reinvent the wheel, but to select the most 
> appropriate kind of storage to get the most performance out of the 
> server. When it comes to search, you have a three step approach which 
> work :
> - if you have less than a thousand elements, just use a list in memory
> - under a few hundred of thousands elements, a hashmap is better, for 
> non ordered data
> - above one million, BTree will be better, just because you won't be 
> able to cache everything.
Hashtables may be justified in some cases, however, the break down for 
range- and partial searches. Quite a few DBMS implementations therefore 
don't use them at all, since it turns out that a well-managed B+-Tree is 
"good enough" even if one does a lot of single-value primary-key 
accesses like in the case of a join.
> At some point, we really want Derby, Postgresql, LDIF, etc to be 
> storage for ADS, like what OpenLdap supports :
I totally agree - the ADS storage layer API should accomodate a range of 
possible backend implementations and therefore be as 
implementation-agnostic as possible.

Joerg Henne

Mime
View raw message