Создание сайта для загрузки файлов, который масштабируется - PullRequest
5 голосов
/ 16 февраля 2011

Я пытаюсь создать сайт для загрузки файлов как побочный проект, и я никогда не создавал ничего такого, что могло бы обрабатывать большое количество таких файлов.Насколько я могу судить, существует три основных варианта хранения и извлечения файлов (обратите внимание, что на загрузку может быть несколько файлов, например, website.com/a23Fc может позволить вам загрузить один или несколько файлов, в зависимости отна сколько пользователь изначально загрузил - похоже на imgur.com):

  • Поместите все файлы в один огромный каталог файлов и используйте (реляционную) БД, чтобы выяснить, какие файлы принадлежат каким URL, а затем вернуть список имен файлов в зависимости от этого.Пример: пользователь загружает website.com/abcde, поэтому он запрашивает в БД все файлы, относящиеся к загрузке в abcde, возвращает их имена файлов, и сайт выводит их.
  • Используйте CouchDB, поскольку он позволяет фактически прикреплять файлык отдельным записям в БД, поэтому каждый URL / загрузка может быть записью БД с прикрепленными к ней файлами.Например, пользователь загружает website.com/abcde, CouchDB захватывает документ с идентификатором abcde, захватывает файлы, прикрепленные к этому документу, и передает их пользователю.
  • Полностью откажитесь от использования БД идля каждой загрузки создайте новый каталог и вставьте в него файлы.Пример: пользователь загружает website.com/abcde, сайт ищет каталог / files / abcde /, извлекает все файлы оттуда и передает их пользователю, поэтому база данных вообще не задействуется.

Что из этого кажется наиболее масштабируемым?Как я уже сказал, у меня очень мало опыта в этой области, поэтому, если я полностью отключен или есть очевидный 4-й вариант, я более чем открыт для этого.Наличие тысяч или миллионов файлов в одном каталоге (т. Е. Вариант 1) не кажется очень разумным, но наличие тысяч или миллионов каталогов в каталоге (т. Е. Вариант 3) не выглядит намного лучше.

Ответы [ 3 ]

3 голосов
/ 16 февраля 2011

Компания, в которой я работал, столкнулась с этой проблемой примерно с петабайтом файлов изображений. Их решение состояло в том, чтобы использовать файловую систему Andrew (см. http://en.wikipedia.org/wiki/Andrew_File_System) для хранения файлов в структуре каталогов, соответствующей структуре URL. Это очень хорошо масштабируется на практике.

Они также зафиксировали наличие файлов в базе данных по другим причинам, которые были внутренними для их приложения.

0 голосов
/ 27 марта 2011

Если вы собираетесь использовать ASP.NET, вот статья, которая описывает, как использовать распределенную файловую систему для веб-фермы http://weblogs.asp.net/owscott/archive/2006/06/07/DFS-for-Webfarm-Usage---Content-Replication-and-Failover.aspx

0 голосов
/ 19 февраля 2011

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

Время выхода на рынок важнее архитектуры по двум причинам:

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