Загрузка файлов на разные серверы, диски. Структура, ахритектура

Spear

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

Здравствуйте!
Имеется такая задачка - нужно сделать систему загрузки файлов (фото, видео) для проекта, ориентируясь на масштабирование. То есть вариант создания папочки uploads в корне сайта конечно отпадает :) К сожалению, поиск по форуму мне не помог (юзал даже google site:phpclub.ru/talk/), поэтому очень Вас прошу - подскажите, как правильно делается, или ткните носом в хорошую статью, можно на русском, можно на английском (только главное чтобы там была не абстрактная информация а что-то более-менее конкретное и доходчивое).

Конкретные вопросы на текущем этапе:
1. Фото. Каждое фото сохраняется в оригинале, + создается несколько ресайзов. Как правильно делать: сохранять в БД в отдельной таблице информацию о файле: всё данные + пути к оригиналу, и к каждому из ресайзов), или как-то по-другому?

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

Есть 2 сервера: 1 только для файлов, второй (основной) - БД, скрипты и тоже файлы (да, пока так, хотя конечно потом все файлы будут на отдельном/отдельных серверах).
Нужно создать "каталог" серверов? Загружать на локальный (тот, на котором скрипты) через move_uploaded_file(), а на другие как? Можно через FTP, а можно при закачке файла (пользователем) просто подставлять в форму адрес сервера, куда нужно лить файл - например, http://static2.project.com.

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

Как Вы посоветуете переименовывать файлы на дисках? Да, вопрос, возможно, кому-то кажется банальным, но навряд ли многие сервисы с громадным количеством файлов дураки и переименовывают файлы не в /uploads/users/user_1_avatar.jpg а во чтото вроде sr232.site.com/1223/45/xc/v43kl4t03cnfbdf8j4_44833_xxw2.jpg

Нет я не гонюсь за неопнятными путями к файлам ради создания иллюзии что у нас мега-система для хранения файлов на 300х серверах в 2 датацентрах) просто мне необходимо знать как делать правильно. Пожалуйста, помогите!
 

Angerslave

Новичок
Хм, правильно? Тут у каждого своё видение.
Думаю, для мало и среднебюджетного проекта подойдёт вариант, по сути описаный тобой - заливать файлы по фтп(или sftp) и хранить в базе пути с учётом сервера, на котором находится файл(в простейшем случае - url файла). Конечно, крайне желательно рядом хранить всю мета-информацию о нём, чтобы постоянно не дёргаться за ней на другой сервер. Естественно, необходимо как-то предусмотреть определение сервера, который наиболее оптимален для загрузки на него файла в текущий момент - аплоадом небольшого мока, опросом значений свободного места на диске и т.д.
Это моя точка зрения :)
 

Spear

почемучка
Ну это, в общем, верхушка айсберга) причём не самого мудрённого.

Бюджет проекта выше среднего: инвесторы ещё не привлекались, но при необходимости кол-во серверов будет увеличиваться.

Мне же нужно узнать и на 100% опредилиться как делать :)
 

Spear

почемучка
Абсолютно неадекватный совет, поскольку я ведь сказал что Simple вариант - не вариант. Спасибо за советы, но это не то
 

korchasa

LIMB infected
"Правильно" не бывает. Бывает, что решение устраивает каким то условиям или нет. Минимальный набор необходимых данных: id фотки и id сервера. id-сервера - чтобы знать у кого просить. id-фотки(ну еще возможно тип, если их несколько - фото/видео/etc) - чтобы знать что. И отдельная таблица не нужна. Keep It Simple, Stupid :)
 

Spear

почемучка
korchasa
вроде того?
media_files (таблица):
id
server_id
path


Но тогда как правильнее - делать по 4 записи в эту таблицу (для оригинала, ресайзов)? просто если создавать доп. поля, вроде path_orig, path_boxed, path_narrow - то ведь эти поля не будут юзаться теми же, скажем, аватарами, или видео файлами.

флоппик
спасибо. Ещё мне нравится Hadoop Distributed File System. Но и то и другое это, всё-таки, наверное немного позже понадобится, поскольку сейчас даже нет возможности поставить куда-то mogileFs или Hadoop DFS для разработки.

-~{}~ 28.10.08 13:40:

Вопросик в продолжение: кто-нибудь пробовал ставить Hadoop DFS (HDFS) на Windows, используя Cygwin? :)
 

dr-sm

Новичок
Spear, сделай как я :)
поставь себе под виндовс убунту в вмваре
 

Maxsystems

Новичок
Уменя такаяже фигня, правда без серверов)
Со структурой я разобрался, а вот застрял на ерунде, не хочу открывать доступ к директориям на 0777, а подругому перемещать файлы туда не получаеться... Вообщем решаю вопрос с безопасностью..

Кстати о 4 ресайзах, а они тебе нужны? Может одной миниатюрой обойтись, а уже потом её расайзить на лету уже с уменьшенной копии, напримере:
Фотка 1024*800
Делаем миниатюру 200*200
Ауже к запросом тыркать через обрезалку, файл не большой и думаю ресайзнет быстро.
Ну а потом если пойдет сильная нагрузка установить кэшь на ресайз, проверять по папке есть ли уже ресайзненый файл, если нет то в перед на обратку и копию в кэшь и на вывод.
 

phprus

Moderator
Команда форума
Maxsystems
Ауже к запросом тыркать через обрезалку, файл не большой и думаю ресайзнет быстро.
Ну а потом если пойдет сильная нагрузка установить кэшь на ресайз, проверять по папке есть ли уже ресайзненый файл, если нет то в перед на обратку и копию в кэшь и на вывод.
Идиотизм. Масштабирование картинок перед отдачей это хороший способ открыть огромную дыру для того, чтобы сайт можно было уронить.
А вообще диски сейчас очень дешевы, а вот процессоры дороги, по этому дешевле купить еще один диск, чем еще один процессор, чтобы на нем масштабировать картинки на лету.
 

Spear

почемучка
Ресайз на лету это из той же оперы что все файлы в корне в 1 папке site.com/uploads/ :))

-~{}~ 28.10.08 15:05:

Кстати, а есть примеры кода PHP, который работает с HDFS? Я всегда лучше понимал 2-3 строчки кода чем 2-3 страницы документации

-~{}~ 28.10.08 15:12:

dr-sm
кстати, убунту ставить сервер или десктоп? качаю сервер
 

korchasa

LIMB infected
Автор оригинала: Spear
korchasa
вроде того?
media_files (таблица):
id
server_id
path


Но тогда как правильнее - делать по 4 записи в эту таблицу (для оригинала, ресайзов)? просто если создавать доп. поля, вроде path_orig, path_boxed, path_narrow - то ведь эти поля не будут юзаться теми же, скажем, аватарами, или видео файлами.
Еще симплее...
media_files (таблица):
id | server_id | extension

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

media_files (таблица):
id | server_id | extension
42 | 42 | jpg

url тумбы - http://storage_42.blah-blah-blah.ru/42_thumb.jpg

ЗЫ: Следующая проблема - много файлов в одной папке :)
 

Spear

почемучка
ну собсно из-за проблемы большого кол-ва файлов в одной папке и прочим я и поднял эту тему :) Я так понимаю, HDFS решает большинство этих проблем? Но с ним ещё разобраться нужно.

по поводу большого кол-ва файлов в папках: сейчас у меня делается так: есть Бд файлов, примерно как мы опредилили до этого, + там есть 2 поля - folder1 & folder2. В итоге структура папок такая поулчается:
/1...-n-...100
/1...-n-...100/1...-n-...100

т.е. 100 папок, по 100 папок в каждой. Файлы загружаются равномерно. Первая фотка (+ её ресайзы) будут в папке 1/1, а 130 фотка будет в папке 2/30.

Но по-моему это убогое решение, недалеко уходящее от всё той же папочки uploads в корне ....
 

MiksIr

miksir@home:~$
Я думаю, вам стоит
1. активно погуглить на предмет различных архитектур
2. посмотреть материалы наших хайлоад конференцией
3. научится самому отвечать на глупые вопросы
Совет может быть о каких-то ньюансах в архитектуре - пути решения или ошибочность. Совет о всей архитектуре "с нуля" дать смогут только те, кто находится приблизительно на том же уровне знаний, что и вы, но "где-то что-то слышали"... думаю, ясно какие это могут быть советы.
Конкретно по теме - Яндекс на последнем хайлоаде(РИТ) делал доклад о своих яндекс-фотках.
 

Maxsystems

Новичок
Автор оригинала: phprus
Maxsystems

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

[qoute="korchasa"]Следующая проблема - много файлов в одной папке[/qoute]
Над этим я долго думал но мне подсказали идею, она наверное уже стара, но мне подходит.

В таблице есть айди файла, этот номер кодировать при помощи md5, получаеться 32 символьная строка, из которых создаешь разброс папок
например строка
cfcd208495d565ef66e7dff9f98764da
c/f/c/d/2/0/8/4 - глубину директории определяешь сам, и сохраняешь файл под настоящим id.txt разброс получаеться колласальный


Конкретно по теме - Яндекс на последнем хайлоаде(РИТ) делал доклад о своих яндекс-фотках.
Ты хакер чтоли?! Они много чего говорят интересного, только до конца ничего не раскрывают.. будь добр, выложи сылку где можно почитать..
 

MiksIr

miksir@home:~$
Я не хакер, я хуже - я умею пользоваться гуглом.
http://company.yandex.ru/experience/

-~{}~ 28.10.08 16:42:

ЗЫ: с видео похуже... скорее всего РИТ-овцы просто не торопятся выкладывать все.
 

dr-sm

Новичок
Автор оригинала: Spear
dr-sm
кстати, убунту ставить сервер или десктоп? качаю сервер
если сможешь настроить без GUI, ставь сервер, принципиальной разницы никакой.
кстати, достаточно вполне vmware workstation.
 

Spear

почемучка
поигрался с VMware и понял что мне проще купить отдельный комп, поставить туда убунту и уже под ней работать)
 
Сверху