2 ms·
At the size they're doing things, the algorithims, data structures, and application specific optimizations (assumptions you can make about the data) are where t
by iigs 18y ago
At the size they're doing things, the algorithims, data structures, and application specific optimizations (assumptions you can make about the data) are where the big challenge is. It would be relatively simple to export/offer the data as an ldap service, but the wire protocol is arguably an uninteresting technical anecdote.
To see this in action, slap together a sun or oracle ldap server and fill it with 2-4x physical ram worth of data and benchmark non-trivial queries against it. I believe you'd see better results than a naive sql implementation but it would be quite undesirable compared to their real world transaction rates.
- lr 18y agoThe whole point is that you have more RAM than data, not less. If you are trying to do queries in LDAP and all of the data (entry db and index dbs) do not fit in RAM, then forget about it. This is why you would design the system to take growth into account. Modern LDAP servers -- in conjunction with LDAP proxy servers -- are designed to do this very thing. Verison has their 75 million wireless subscriber "database" in LDAP, not a RDBMS, and the entire dataset is in memory (spread across dozens of servers).