MongoDB gridFS - filename length, indexing, performance

Question

I'm studying gridFS and I have a few questions.

1) gridFS automatically indexing files by generated _id. But most of the time I get files by their filename, so should I create index on 'filename' by myself?

2) gridFS don't have folders, just filenames, but I can mimic folders by using filenames with slashes '/images/avatars/35.jpg', right?

3) If I'm indexing on "filename" - is it better in performance terms to use short filenames? I mean - if I use user's _id which is 24 symbols long + suffixes, for example "/images/avatar_4f1d36b58e42ba3836ed178e_t.jpg" , wouldn't indexing on such long field slow down my system? Would it be better (faster) to use short user's login instead of _id?

Answer 1

1) I'd very surprised if the filename weren't indexed. It's used throughout the API, and I assume that it is indexed.

2) Yes, you can, but there is no real notion of directories implied. Listing files/dirs is a bit more complicated. In other words it's just a label.

3) Indexes use hashes, or fixed length strings, so a long key is just as easy to index as a long one.

Answer 2

1) The specification doesn't require the filename to be indexed. You would want to check the code in your driver, or just make an index yourself. One thing that you should take into consideration is that filenames don't have to be unique. You might reconsider your design, and query on the _id instead.

2) Yes.

3) The b-tree indexes in mongodb do not use hashes. A larger string will take more space in the index, thus taking more RAM, but I don't think performance will be affected much (unless you count using more RAM as taking a performance hit). A good rule of thumb for mongodb is that your indexes (and your "working set") should fit in RAM. If you can rework your application to query on the _id instead of the filename, you wouldn't have to worry about the space for this index.

Answer 3

GridFS在_id上有一个默认索引（很明显），在filename和uploadDate上有一个复合索引。