Обслуживаете много маленьких файлов? - PullRequest
1 голос
/ 02 октября 2010

Я создаю веб-сайт, который зависит от того, достаточно ли быстро выкладывается множество маленьких mp3-файлов (около 10-15 КБ каждый).Каждый файл содержит произношение слова, и 20-30 на пользователя будут загружаться каждую минуту, когда они используют сайт.Каждый пользователь может загружать 200 в день, и я ожидаю 50 одновременных пользователей.Там будет ок.15000 отдельных файлов в конце концов.

Каков наилучший способ хранения, управления, вызова и воспроизведения этих файлов по мере необходимости?Нужен ли мне специальный хостинг для работы со всеми небольшими файлами, или они будут хорошо себя вести в одной большой папке (используя стандартный хост)?Любые задержки испортят ощущение.


Обновление

Сделав поиск немного больше, я думаю, что проблему можно решить с помощью:

  1. Aтакой сервис, как Photobucket , но вместо аудио, со своим собственным API
  2. Некоторым другим видом «хостинг-хостинга», где вы можете загружать тысячи файлов по разумной цене и легко вызывать их

Кто-нибудь знает такой продукт?

Ответы [ 3 ]

3 голосов
/ 02 октября 2010

15k Файлы в одном каталоге не должны быть проблемой для любой современной файловой системы. Это конечно не для NTFS. То, что вы не хотите делать, это открыть папку, содержащую более 100 тыс. Файлов в проводнике или что-то подобное, потому что заполнение списка (GUI) является убийцей. Также вы не захотите многократно повторять содержимое такой папки. Однако простой доступ к файлу, если вы знаете имя файла (путь), все еще очень быстр, и сервер обычно делает именно это.

Частота звучит не слишком страшно. 50 пользователей * 30 запросов / минута / пользователь - 25 запросов в секунду. Это не то, что вы можете полностью игнорировать, но любой приличный веб-сервер должен иметь возможность обслуживать файлы с такой скоростью. Также я не вижу необходимости в специализированном сервере / базе данных / хранилище данных в памяти. Каждая ОС имеет файловый кеш, и это должно заботиться о частом обращении к файлам в памяти.

Если вы должны гарантировать низкую (в худшем случае) задержку, вам все равно может понадобиться хранилище данных в памяти. Но опять же, если вы должны гарантировать задержку, все равно все усложняется.

И последнее: подумайте об обратных прокси. Я считаю очень удобным иметь возможность в первую очередь хранить / обновлять данные только в одном месте (по моему выбору), а обратные прокси-серверы позаботятся обо всем остальном. Если ваши файлы никогда не меняются (то есть один и тот же URL означает одни и те же данные), это очень простой способ обеспечить действительно хорошую масштабируемость. Если файлы действительно могут быть случайными, просто сделайте так, чтобы они не могли :), например. кодируя дату изменения в имени файла (и удаляя «старые версии»).

2 голосов
/ 02 октября 2010

Если вы хотите (или нуждаетесь) хранить файлы на диске, а не в виде больших двоичных объектов в базе данных, необходимо помнить о нескольких вещах.

Многие (но не обязательно все) файловые системы не очень хорошо работают с папками, содержащими много файлов, поэтому вы, вероятно, не хотите хранить все в одной большой папке - но это не значит, что вам нужен специализированный хостинг.

Ключ заключается в том, чтобы распределить файлы в иерархии папок на основе некоторой хэш-функции. В качестве примера, мы будем использовать MD5 имени файла здесь, но не особенно важно, какой алгоритм вы используете или какие данные вы хэшируете, если вы последовательны и располагаете данными, когда вам нужно найти файл .

Как правило, выходные данные хеш-функции форматируются в виде шестнадцатеричной строки: например, MD5 для "foo.mp3" имеет значение 10ebb1120767e9de166e0f5905077cb1.

Вы можете создать 16 папок, по одной на каждый из возможных шестнадцатеричных символов - таким образом, у вас есть каталог 0, одна с именем 1 и т. Д. До f.

В каждой из этих 16 папок повторите эту структуру, чтобы у вас было два уровня. (0/0 /, 0/1 /, ..., f / f /)

Затем вы просто помещаете файл в папку, продиктованную его хешем. Вы можете использовать первый символ, чтобы определить первую папку, и второй символ, чтобы определить подпапку. Используя эту схему, foo.mp3 будет идти в 1/0 /, bar.mp3 - в b / 6 /, а baz.mp3 - в 1 / b /.

Поскольку эти хеш-функции предназначены для равномерного распределения их значений, ваши файлы будут распределены довольно равномерно по этим 256 папкам, что уменьшает количество файлов в любой отдельной папке; по статистике, 15000 файлов в среднем составят около 60 на папку, что не должно быть проблемой.

Если вам не повезло и выбранная вами хеш-функция в конечном итоге приводит к объединению слишком большого количества ваших файлов в одной папке, вы можете расширить иерархию до более чем двух уровней или просто использовать другую хеш-функцию. В обоих случаях вам нужно распространять файлы, но вам нужно сделать это только один раз, и вам не составит труда написать скрипт, который сделает это за вас.

Для управления вашими файлами вам, вероятно, понадобится небольшая база данных, индексирующая, какие файлы у вас есть в данный момент, но это не обязательно нужно использовать для чего-то другого, кроме управления ими - если вы знаете имя файла и используете имя файла в качестве входных данных для вашей хеш-функции, вы можете просто снова вычислить хеш и найти его местоположение таким образом.

0 голосов
/ 02 октября 2010

Я бы обслуживал их из базы данных в памяти 15ksize * 15000 = 225Mb необработанных данных, даже при значительных накладных расходах они легко поместятся в план среднего хостинга.Кэши на основе диска могут быть элегантными, например, memcachedb, ehcache или аналогичные, тогда у вас есть только один API и некоторая конфигурация.

Вы должны прогреть кеш, хотя при запуске.

Метаданные могут быть в MySQL или аналогичном.Вы также можете хранить там мастер-копию для более простого управления и в качестве бэкэнда для кеша.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...