On 06/02/2017 01:36 PM, Howard Chu wrote:
Prentice Bisbal wrote:
On 05/31/2017 04:39 PM, John Lewis wrote:
On Wed, 2017-05-31 at 15:07 -0400, Prentice Bisbal wrote:
On 05/31/2017 02:55 PM, Howard Chu wrote:
Prentice Bisbal wrote:
On 05/31/2017 12:37 AM, John Lewis wrote:
This sounds like the wrong tool for this job.
Really? Can you give a point by point comparison against what you
think is the "right" tool for the job?
That's the wrong question to ask, since I never made any claim as to
what the right tool is. A better question to ask would be why I think
this is the wrong tool. So here's my reply to that: It doesn't seem
like
this is a job LDAP was designed for. To me, LDAP is really just a
standardized database interface that make certain type of DB looks up
easy, and most importantly, standardized.I would think a more general
purpose database interface would be better for this.
Unfortunately, I'm not a database expert, so I can't give you the
"point-by-point argument you requested.
Now your turn - why would OpenLDAP be a good fit for this over other
databases?
--
Prentice
Yes, LDAP is really just a standardized database interface. That is the
point. I want my logs available through an IETF standardized
protocol so
I can reuse tools so I don't have to maintain as many tools.
OpenLDAP would be a good fit over other databases because Michael, and
Howard, and the other contributers to OpenLDAP did most of the work for
me.
Fair enough answer. How would you store and retrieve your results?
Are you
creating/using a schema specifically for this? If so, what does it
look like.
I'm still having trouble seeing the performance benefits, though. The
data is
still stored in a backend DB, right? Let's say that backend is some
sort of
SQL DB. You write your ldapsearch query, and then LDAP converts that
to SQL,
and then the DB returns the results to LDAP, which then translated
the results
to LDIF and returns them to you. Isn't there performance hits every
time you
traverse the LDAP layer?
I suppose this might still be faster than reading a plain-text log
file. Is
that the point I'm missing?
OpenLDAP's native backends are multiple orders of magnitude faster
than every SQL DB. That seems to be the crucial point you're missing.
Well, that certainly sounds like the missing link, doesn't it? ;)
What is different about your native backends that makes them so much
faster? Domain-specific design? I haven't been keeping up with OpenLDAP
over the past few years. The versions I've used in the bast used BDB for
the backend. I've been charged with upgrading an old LDAP server, and as
I was looking through the documentation for the latest version, I saw
that you have some new native backend(s), but I didn't have time to read
up on them.
Prentice