andreiru
и ещё два списка по которым ищем ?
Да.
Это будет очень эффективно.
Естественно, при условии, что у вас есть свободная память.
Исходя из приведенного вами количества элементов, память есть.
Но, в любом случае, вам выбирать - стоит ли дополнительно расходуемая память возможности быстрого поиска.
Тут, конечно, тоже есть оговорка - все зависит мощности от используемого сервера. Но получить дополнительную память обычно дешевле получения дополнительной процессорной мощности, если говорить о VDS или хостинге.
О способе хранения данных. Пример.
1. Список путей файлов - list, после добавления пути в список мы получаем его индекс (ссылку).
2. Список расширений - set. Имя множества - расширение файла, а элементы множества - индексы (ссылки) из п.1.
Теперь чтобы получить список всех путей для искомого расширения нам достаточно выбрать множество по его имени и для каждого элемента множества с помощью LINDEX получить путь к файлу.
Чтобы реализовать поиск по имени файла, мы можем выбрать 2 пути.
1. Используем строки, где ключ - имя файла (подчеркиваю, только часть пути - имя, без расширения), значение - путь к файлу или индекс из списка (ссылка).
Теперь поиск по имени файла работает не только по полному имени, но и с помощью KEYS, используя все его возможности. Получение списка путей - аналогично примеру выше.
Из недостатков: т.к. возможны коллизии ключей, то нужно к ключу прибавлять уникальный суффикс или префикс. Например, код компьютера, сервера, хоста.
2. Тупо хранить в качестве ключа строки полный путь к файлу и поиск осуществлять через KEYS. При этом не важно, что будет хранится в самой строке, для поиска нам нужен ключ. Поиск можно делать не только по имени файл, но и по любой другой части пути. Это самый функциональный вариант.
Однако расход памяти тут будет наибольший из-за длины ключей. Плюс будет низкая скорость поиска.