Очень нужен совет
 

Подскажите пожалуйста.

Мне необходимо реализовать сервис с огромным количеством фотографий.
Эти фото будут показываться, только в том случае если человек заплатил за месяц. Столннулся с двумя вопросами, которые не знаю как решить.

1 - Как уменьшать размер фото. Мне очень нравится как сделано вконтакте, но у них используется для этого flash.
2 - Как хранить фото. Как я понял обычно фото хранятся в файлах, но дело в том, что их надо показывать только тем кто заплатил и ограниченное количество.

Подскажите пожалуйста как это сделать.

1. У вконтакта flash используется для сжатия на стороне клиента, т.о. меньше (и быстрее) передается на сервер. Ну а уменьшать стандартно - сохранять в худшем качестве, ресайзить.
2. Хранить в файлах. Можно запретить прямой доступ и "проксировать" обращения к картинкам. Это, правда, не очень оптимально, но для не очень нагруженных проектов и малых файлов пойдет. Ну а если нужно что-то серьезное - можете посмотреть в сторону функций веб-серверов. nginx вроде как умеет отдавать файлы только при выполнении некоторых условий.

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

каждый раз когда, какой-то скрипт собирается показать HTML стегом IMG на картинку, то делается следующее:
в какой-то директории, видимой для веб-сервера, создается жесткая ссылка с случайным именем на файл, который требуется показать.
ну, и генерится соответствующий <img>
в итоге веб-сервер спокойно, и незамысловато показывает обычный файл.
но, такую ссылку сможет просмотреть любой человек независимо от кук.
чтобы не тырили для других, надо всего лишь проходить по директории, и чистить картинки старше минуты(или другое время.отталкиваемся от времени за которое ГАРАНТИРОВАННО загрузится страница у пользователся)
захочет пользователь обновить страницу - наделаем новых жестких ссылок

удалено.

удалено.

Какой хедер? Location что ли?

удалено.

Ну это будет то самое проксирование, о котором я говорил. Минусы такого подхода:
1. Увеличивается нагрузка.
2. Нужно возиться с кеширующими заголовками.
3. Если нужен будет partial content, то это опять же ручной труд.
Если использовать для этих целей средства веб-сервера, то все будет хорошо.

удалено.

Про nginx.

удалено.

Спасибо огромное, что пытаетесь помочь.
Я просто уже месяца 4 на одном месте топчусь потому, что не могу понять как мне серверную часть реализовывать.
А из ходя из серверной части и всю клиентскую часть строить надо.

Про вконтакт.
Если взять любую фотку только что с фотика, предположим на 700 кб,
загрузить её на аккаунт, а потом назад сохранить, то максимальный размер получается 300 кб, а иногда и 70 кб!!!
Я пробовал разные программы, так как это делается вконтакте больше негде не нахожу, качество вообще не ухудшается, а все другие программы ухудшают и это очень заметно.

Про сервер.
Дело в том, что поначалу буду делать на хостинге, а там менять
настройки сервера врятли получится.
Т.е. все таки как то средствами php надо, но похоже это реально не возможно, кроме одного способа.

Т.е. хранить все фотки в одной папке, .htaccess только localhost-у позволяется обращаться и копирует фото, в другую папку, от куда идет просмотр, а потом удалять эти фото. Но нагрузка реально будет большой.

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

Да, и ограничение по количеству просмотров бредово. Никто не помешает мне сохранить картинку где-нибудь у себя.

удалено.

удалено.

удалено.

mycoding,
обратите внимание на мой способ
на виртуальном хостинге он также доступен
к тому же вы можете завести каждому пользователю по папке, и ложить туда какой хотите .htaccess

Да, наверное незнание.

Мне сказали, что каждому пользователю заводить папку это плохо,
хотя сначала я именно так и собирался делать.

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

Мы так и делаем))

Кстати есть еще один вариант:
1. нужно создать папку для хранения фотографий, к примеру TMP, в которой будут храниться временные фотографии.
2. когда пользователь купит фото, то ему нужно давать не прямую ссылку на нее из основного хранилища, а ссылку на копию. Т.е. после покупки находится фото с нужным именем, затем производится копирование во временную папку и уникальное переименование самой фото, после пользователь получает ссылку на скачивание, которая действует определенное время (можно крону ставить задачу на выполнение скрипта, который будет удалять файлы срок хранения который вы определите)

К примеру:

<?php
$filename = end(glob('file/photo_154*.jpg', GLOB_NOSORT));
if(file_exists($filename)){
	copy($filename, 'tmp/'.$filename.'_'.date('d.m.Y',time()).'.jpg'); // к новому названию файла добавим текущую дату
}
else {
	exit("Ошибка: запрашиваемый файл $filename не существует");
}

//Для Cron'a
$time = time()-filemtime(end(glob('tmp/photo_154*.jpg', GLOB_NOSORT)));
if(file_exists($filename_tmp) && $time >= 172800){ //2 дня
	unlink($filename_tmp);
}
?>

Относительно изменения размеров фото:

А часто ставить cron-у задачи?
Просто если каждую минуту, это же на сервер большая нагрузка или нет?
Я кроном никогда не пользовался.
И предпложим будет ну 1000000 пользователей, то получается, cron-у надо во все папки зайти и глянуть нет ли там старых фото?
Или это делать раз в день, часа в 3 ночи, когда пользователей нет?

хорошие планы)) У нашей компании тоже есть стоковый магазин фото, но таких цифр за сутки еще не было

Можно одну общую папку создать для всех пользователей
да, раз в сутки запускать, с пользователями это никак не будет связано

удалено.

Вообще планирую где то около 1000000 активных пользователей, а так может быть и 5000000 и 1000000, конечно звучит может мощно. Но этот контент будет нужен очень многим.
Значит для каждого пользователя папку делать нельзя.

Придется наверное все в одной папке держать и названия у файлов будут вроде таких
id1267977matan9787.jpg и доступны они будут только для localhost.
И ещё одна папка в которой будут фото для просмотра(эти файлы будут копироваться туда из основной папки), которые будут удаляться раз в день.

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

наполеоновские планы

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

сейчас вроде бы первый уровень - 16 папок.
в каждой из них по 256 подпапок.
в оригинальном движке немного по-другому, но суть та же.

использование системы поддиректорий для хранения БОЛЬШОГО количества файлов - популярное решение, использующееся во многих движках.
в свое время помогал переводить один нагруженный проект с системы "одна папка, куча файлов", на систему "древовидная система папок.в листьях - файлы"
переводили именно потому, что начались жуткие тормоза файловой системы

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

удалено.

Мне главное понять как надо, а дальше уже буду писать.
Как понял ограничение на количество папок в одной папке около 40000?
Т.е. если пользователей свыше 40000 и каждому сделать папку то будет сбой?

Что-то мне это Битрикс напоминает))

догадывался, но не был уверен.


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

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

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

А никто не знает случаем как сделано вконтакте хранение фото?

Они связывают в БД ссылки на профайл с доверенными пользователями.

У нас на сайте стоковых фотографий так:

Да интересно.
Начинаю всё больше и больше понимать.

Но всё такие с php у меня видимо не очень.
Никак не пойму как запретить прямой доступ к картинке?
С помощью htaccess?

Deny from all
 Allow from localhost

Т.е. в Б.Д. у Васи Иванова есть ссылка
matanid19867n19787forvasyaivanov.jpg а у исходного файла название
matanid19867n19787.jpg , я просто не пойму как это реализовать?
С настройкой серверов очень плохо знаком, да и тем более у меня же хостинг, а так настрока серверов не реализованна.

Вообще я по php прочитал всего две книги Котирова PHP5 и PHP для хаккеров, может ещё что надо? Наверняка надо а то вопросы у меня из разряда нубских.

Самый распространенные и намой взгляд один из лучших
да

Хрень такая.

Вот эти купил и имею теперь счастья полные штаны
Изучаем PHP и MySQL, 2-е издание //Для тех кто уже знаком будет лишней, а для новичков наверное лучшей в этот экскурс
PHP 5. Профессиональное программирование //Введение в PHP 5, очень много про PEAR
Профессиональное PHP программирование. 2-е издание //Хорошая база
PHP. Рецепты программирования //Лучший cookbook
PHP. Объекты, шаблоны и методики программирования //ООП!
MySQL. Оптимизация производительности, 2-е издание //Есть даже главы по работе с PHP и Perl
Руководство по MySQL //Очень хорошая база
Рефакторинг SQL-приложений //Сложная сцука поначалу
Oracle PL/SQL для администраторов баз данных //база SQL хорошая

Вообще PHP, довольно шаблонный язык на котором легко писать приложения, главное справочником почаще пользоваться, чтобы не изобретать велосипед

Огромное спасибо за советы по книгам.

удалено.

удалено.

удалено.