[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Storing Large Objects in an LDAP Tree

Bad idea for the current back-ldbm database, since it stores all entries in
LDIF format. Maybe reasonable in back-bdb, which uses a binary record
format.
Of course, I don't believe the buffer architecture in slapd would perform
well
with 100MB objects; far too much byte-copying needed.

I think the question itself reveals a misunderstanding of when and why to
use
a Directory. Go back to the telephone analogy - a telephone directory tells
you how to locate something, but doesn't store the thing itself. There's
nothing in the protocol to prevent you from doing this, but I don't believe
it's the right approach.

A better idea would be to store some metadata for the document, including
an HTTP URL for where the main document can be retrieved. The directory
should
give you a lookup, an index, not the actual content. Leave the actual
document
as a standalone file; after all, that's what filesystems *are* designed for.

If you need any further help understanding the issues or designing a
solution,
feel free to contact us at Symas Corp. We have both the breadth of
experience
to identify the correct technologies for a solution, and the depth to
deliver
the details.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Adam Sherman
> Sent: Saturday, October 13, 2001 11:29 AM
> To: OpenLDAP Software
> Subject: Storing Large Objects in an LDAP Tree
>
>
> We are currently designing a document management system for a
> client. I'm new to LDAP, but I see a good possibility of using it over
> SQL for this project.
>
> The main requirement for the system is that it be able to handle very
> large files, 100MB plus.
>
> Any comments or opinions about how this could be done with OpenLDAP,
> and whether or not it would be fast/stable?
>
>
> Thanks,
>
> A.
>
> --
> Adam Sherman
> President & Technology Architect
> Tritus Consultant Group Inc.
> +1.613.255.5164
> http://www.tritus.ca
>