directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [ApacheDS][Partition] Using surrogate keys for attributeType aliases and objectClass aliases (was Re: [SCHEMA] Can two different LDAP AttributeType's have the same name?)
Date Sat, 07 Apr 2007 15:38:19 GMT

Emmanuel Lecharny wrote:

>> Although once the DAS gets done, people could start using
>> ADS as an RDB.
> A ldap server is *not* a RDB. Whatever you use it for, this is a 
> hierarchical database.

OK Bro - Now you're preaching to the quire :-)

Your earlier point was that
a ldap server is 99,99% and less tha 0,01 write.

My point is that when the DAS gets done, people have the
ability to use ADS just as an RDB and the read/write
ratio could hence change accordingly.

 From the point of view of a DAS there's no
difference between an RDB and LDAP, it's just
a datasource.

Some people will want to write a lot and some
will just continue to store mostly read data.

This naturally depends on how the server performs
with writes, which over time depends on the server's
road map.

If hsql or derby performs 5X better than ADS for writes
and is a little slower in reading then they may choose that

So it really depends on the types of usage /
performance scenarios scenarios ADS wants to be able to "Brag" about.

>> <snip/>
>>> So it definitively worth the price to spend a *lot* of time writing 
>>> twice the data in to different forms than do a computation for each 
>>> search. Adding entries in ADS is 10 to 20 times slower than reading 
>>> them.
>> Is that because they are written to many different forms during the 
>> one write.
>> It would be neat if it could just write one form. per configuration,
>> assuming a certain usage scenario.
> It's up to you : just don't add indices. But then performance will suck 
> big time. For every search not using an index, the cost is a full scan. 
> There is no free beer.

OK - Cool - Because there are essentially two DAS usage scenarios.

Scenario A where someone just wants to do regular CRUD
using the entire DataGraph instance (thus not searching) and B that 
searches/filters the members of a persisted DataGraph instance
during its recreation.

> Emmanuel
- Ole

View raw message