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.
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
openldap-technical@openldap.org
-
Howard Chu -
Prentice Bisbal