Yeah, ok I see it now... guess I'm still too much in some sql mindset. We will
store lots of files of the same type
so I guess I would need some way of separating them, perhaps by name or
something into "directories". You're
right of course about not putting 10 000 files into a directory.
Actual
Well... perhaps my use case isn't well suited for riak, not sure, but my
reasoning was that using riak as file storage with attached
metadata would be a good way of ensuring file availability. I've also
considered using S3 for this which also seems like a pretty
good choice, but I would then need
You may want to consider how often you will be accessing all 10,000 files in
one query.
It is my understanding that with a key/value store such as Riak, it's a good
idea to analyze what your common queries will be as long as your frequency
of reading vs writing, and then to structure your data so
You wouldn't put 10,000 files in a single directory on your computer, so
there's no reason you would have to in Riak either. What about representing
your directories as objects, too? The only thing you would require would be a
known key that's the root of the hierarchy. For example:
/riak/file
Yes, I've thought of this but as I understand it there is a bit of a problem
attaching a large amount of links to a key which
would be necessary here am I right? If I had 10 000 files in riak that would
mean 10 000 links attached to the "listing" key.
4 sep 2010 kl. 20.44 skrev Matthew Scott:
>
On Sat, Sep 4, 2010 at 11:31, John Axel Eriksson wrote:
> Listing keys in a bucket has been described as "bad" and something you use
> in development but
> not in production. I'm just starting out on Riak so I'm a newbie...
>
> I'm thinking of building an application using Riak as filestorage and
