px.uz - бесплатный хостинг изображений в TAS-IX

[JackDaniels]

Сообщение от Aziz Madetov

Второй способ заключается в том, что, как все наверное уже заметили, загруженные картинки хранятся в папках по датам, типа /2012/02/01/image.jpg - так вот, в папках каждый день создается индекс содержимого с указанием даты создания и последнего доступа, которая перезаписывается скриптом при запросе. Далее все просто

Это очень медленно, не заморачивайтесь даже.
Через 2-3 года и +100 000 картинок сервер будет просто «умирать» на этом месте.

[Denis Shlyapnikov]

Сообщение от Руслан Худяков

Это очень медленно, не заморачивайтесь даже.
Через 2-3 года и +100 000 картинок сервер будет просто «умирать» на этом месте.

Хочется отметить, что первый способ будет не лучше, постоянные запросы mysql со временем отправят сервер в даун.
Хотя есть более быстрые DB, но все равно это постоянная нагрузка на сервере будет.

[JackDaniels]

Сообщение от Denis Shlyapnikov

Хочется отметить, что первый способ будет не лучше, постоянные запросы mysql со временем отправят сервер в даун.
Хотя есть более быстрые DB, но все равно это постоянная нагрузка на сервере будет.

Глупости.

Смотрите сами —

При запросе картинки, например http://img.site.com/pictures.jpg
Ваш движок получает в переменную ее имя: $image=pictures.jpg

На каждую картинку в таблице всего несколько полей — "ID владельца", "Дата загрузки", "Размер", "EXIF данные", "Дата последнего запроса", "Публична/Приватна", "Имя картинки", "Размер X", "Размер Y", "Теги", "Тип", "Ну и еще какие ни будь полезности"

Все столбцы, по которым возможен запрос типа SELECT загоняем в Индекс, полный путь (исходная, миниатюра) принять постоянным для всех, чтобы не записывать отдельно (например "/mini/", "/orignl/").
Поле "Дата последнего запроса" даже не обязательно обновлять PHP-скриптом, можно пойти на хитрость, и выполнять холостой UPDATE-запрос, тогда выбрав тип TIMESTAMP мы возложим это на сам MySQL, который пробъет текущую дату.

Таким вот макаром получаем, что запрос картинки из MySQL на простеньком самодельном сервере будет занимать всего 0.003—0.005 с.

Профит:
Имеем гибкую структуру для поиска по различным признакам (размер, тип, автор, EXIF, и тд…)

Запуская раз в сутки, например в 5 утра, когда все спят, по Крон-у скрипт, который выполнит что-то типа SELECT * FROM img WHERE last_date >= cur_date+60 дней, находим просроченные.
И спокойно скриптом-удалялкой хлопаем по порядку все, что нашлось не нужное и из базы и с диска.

И все будет прекрасно работать и со 100 000 и с 500 000 и даже с 5 000 000 элементов.

А почему постоянные запросы к MySQL должны «отправить сервер в даун» — я вообще не понял.
С какой радости?
Ради приличия, можно после удаления ненужных запускать оптимизацию: OPTIMIZE TABLE `img`

[Denis Shlyapnikov]

Сообщение от Руслан Худяков

Глупости.

Смотрите сами —

При запросе картинки, например http://img.site.com/pictures.jpg
Ваш движок получает в переменную ее имя: $image=pictures.jpg

На каждую картинку в таблице всего несколько полей — "ID владельца", "Дата загрузки", "Размер", "EXIF данные", "Дата последнего запроса", "Публична/Приватна", "Имя картинки", "Размер X", "Размер Y", "Теги", "Тип", "Ну и еще какие ни будь полезности"

Все столбцы, по которым возможен запрос типа SELECT загоняем в Индекс, полный путь (исходная, миниатюра) принять постоянным для всех, чтобы не записывать отдельно (например "/mini/", "/orignl/").
Поле "Дата последнего запроса" даже не обязательно обновлять PHP-скриптом, можно пойти на хитрость, и выполнять холостой UPDATE-запрос, тогда выбрав тип TIMESTAMP мы возложим это на сам MySQL, который пробъет текущую дату.

Таким вот макаром получаем, что запрос картинки из MySQL на простеньком самодельном сервере будет занимать всего 0.003—0.005 с.

Профит:
Имеем гибкую структуру для поиска по различным признакам (размер, тип, автор, EXIF, и тд…)

Запуская раз в сутки, например в 5 утра, когда все спят, по Крон-у скрипт, который выполнит что-то типа SELECT * FROM img WHERE last_date >= cur_date+60 дней, находим просроченные.
И спокойно скриптом-удалялкой хлопаем по порядку все, что нашлось не нужное и из базы и с диска.

И все будет прекрасно работать и со 100 000 и с 500 000 и даже с 5 000 000 элементов.

А почему постоянные запросы к MySQL должны «отправить сервер в даун» — я вообще не понял.
С какой радости?
Ради приличия, можно после удаления ненужных запускать оптимизацию: OPTIMIZE TABLE `img`

Т.е. вы считаете правильным держать записи Всех 5 миллионов картинок в mysql, к которому постоянно будут идти запросы.

Допустим что так и сделали, и у нас имеется 100.000 картинок. Все они, к пример, располагаются на нескольких посещаемых сайтах. Далее, к примеру - на одной странице одного из этих сайтов располагается 30 картинок - это уже 30 запросов (на 1 пользователя). А если там будут выкладывать типа сборника Демов или еще чего наподобие )) то и 30 картинок далеко не предел. Или просто на посещаемый форум вобьют в подпись картинки.
По факту получится же -
1 картинка - 1 запрос от одного пользователя, а сколько их будет?)

Поэтому, на мой взгляд хранить в таком виде картинки - не есть хорошо.

[Denis Shlyapnikov]

А нет, ошибся, простите. Там не 1 запрос на 1 картинку, а 2
1 - выборка
2 - update
=\

[JackDaniels]

Сообщение от Denis Shlyapnikov

Т.е. вы считаете правильным держать записи Всех 5 миллионов картинок в mysql, к которому постоянно будут идти запросы.

Допустим что так и сделали, и у нас имеется 100.000 картинок. Все они, к пример, располагаются на нескольких посещаемых сайтах. Далее, к примеру - на одной странице одного из этих сайтов располагается 30 картинок - это уже 30 запросов (на 1 пользователя). А если там будут выкладывать типа сборника Демов или еще чего наподобие )) то и 30 картинок далеко не предел. Или просто на посещаемый форум вобьют в подпись картинки.
По факту получится же -
1 картинка - 1 запрос от одного пользователя, а сколько их будет?)

Поэтому, на мой взгляд хранить такой в таком виде картинок - не есть хорошо.

Дело не во взглядах, просто это удобный и правильный метод.
Изобретете что-то новое — пишите.

Чтоже до нагрузки, то даже если допустить, что при каждом посещении каждой страницы каждого сайта зарегистрированного на www.uz пользователь запросит 1 картинку (согласно статистики http://www.uz/ru/catalogue/stat/ это около 4 миллионов хитов за сутки), получается в районе 45 запросов в секунду, а при затратах времени на один запрос даже в 0.01 с, вы во много раз перекрываете потребность.

Быстрее заглохнет PHP, канал и дисковая система на отдачу самой картинки.

Подумайте сами, данных в базе на одно изображение: 1-2 кбайта, а сама картинка может быть и 2 и 5 мбайт.

[JackDaniels]

Сообщение от Denis Shlyapnikov

А нет, ошибся, простите. Там не 1 запрос на 1 картинку, а 2
1 - выборка
2 - update
=\

Сообщение от Руслан Худяков

при затратах времени на один запрос даже в 0.01 с,

Учел, как видите

Да, еще ни кто не мешает использовать фронтэнд и кеш.

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

[Denis Shlyapnikov]

Ну тогда и сервер надо ставить по мощнее )))

[Андрей Андреев]

Сообщение от Denis Shlyapnikov

сервер надо ставить по мощнее

интересно а у px.uz какой сервер стоит =)))

[JackDaniels]

Сообщение от Denis Shlyapnikov

Ну тогда и сервер надо ставить по мощнее )))

Ну это само собой