[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Social-mediagoblin] Tahoe-LAFS as a document-oriented database

From: Christopher Allan Webber
Subject: Re: [Social-mediagoblin] Tahoe-LAFS as a document-oriented database
Date: Sun, 10 Apr 2011 10:33:35 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Rob Myers <address@hidden> writes:

> On 04/10/2011 04:02 PM, Christopher Allan Webber wrote:
>> /media/USER_ID/ENTRY_ID/${RANDOM_UUID}-filename.png
> I assume that the filename is irrelevant at the filesystem level, and
> could be mapped to an actual name through the database?
> Or am I misunderstanding document based databases?

Good question.  

So the "document database" in this case doesn't store our media files,
it's still used like *sql.  But the representation of the storage path,
as I'm planning it, will be like:

{'filepath': ['directory1', 'directory2', 'filename.jpg']}

That list is "interpreted" by the file store we're using into whatever
it needs to be.  In this case:


In the example described above, with the random UUID, it might end up

{'filepath': ['4d8e5b0048b1520586000000', '4d8ea23c48b15205e2000000',

Which would be expanded into:


But maybe in tahoe-lafs or eucalyptus it's expanded in a different way.

Am I clearly explaining myself?

... but part of what I'm asking here is about the *main* (not
eucalyptus, not tahoe-lafs) storage system, and whether or not people
will be okay with a filename like


and if they aren't, are they okay with having a directory for every
file, like


... which might chew up a lot of inodes, etc.

If I didn't care about people wgetting the files, I'd do the former
thing, with the uuid just tacked onto the filename.  That way I'd always
be safe about totally unique filenames.  But... I mean, *I* wget files a

There are some important tradeoffs here to consider, but in the long run
we can change our minds on them later.  I'd stil value peoples' input though. 

𝓒𝓱𝓻𝓲𝓼𝓽𝓸𝓹𝓱𝓮𝓻 𝓐𝓵𝓵𝓪𝓷 𝓦𝓮𝓫𝓫𝓮𝓻

reply via email to

[Prev in Thread] Current Thread [Next in Thread]