- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Самая длинная дискуссия на эту тему здесь.
Ayavryk, спасибо.. видел и это..
Цитата из поста (дабы не разрывать - приведу целиком):
Антипаттерном по мнению автора презентации являются "фантомные" файлы, возникающие при рассинхроне FS и БД при удалении, или транзакции (файл уже сохранён, а транзакция откатывается, или наоборот).
ИМХО, "проблема" решается простым сборщиком мусора (пишется на коленке), правильным порядком сохранения (файл, база) и, при необходимости, lock-ом при обновлении.
В комментариях к
http://www.mysqlperformanceblog.com/2010/02/09/blob-storage-in-innodb/ Петр Зайцев (цитата, правда, 2010 года):
Из минусов такого подхода:
- в оперативке вместо "полезных" данных (индексы, временные таблицы, кэш) висят файлы (если нет - опять же читается с диска (БД), а затем - отдаётся веб-серверу. Вместо прямого диск->веб-сервер).. При этом в случае хранения в файлах часто используемые кэшируются на уровне FS. При необходимости можно tmpfs подмонтировать
- нужно извращаться, чтобы отдать файл браузеру (тут речь о "стандартном" L(A|E)MP, а не про встроенный в СУБД web-сервер или плюшки вроде FILESTREAM) - php, коннект к базе, получение файла, его отдача (vs отдача напрямую Nginx-ом из FS)
В общем, метод имеет право на жизнь, наверняка успешно применяется (в определённых условиях), но с учётом:
и
Но есть маленькая проблема, сайт довольно крупный, планируеться большая посещаемости, и когда аватарок будет допустим 100.000, получаеться будет 400 папок. Что тоже уже много.
я бы не рекомендовал ТС-у использовать этот вариант.
я бы не рекомендовал ТС-у использовать этот вариант
А может у него свой дата-центр?
Переведя на наш колхозный сленг ::: идея хорошая и всё упираеццо только в бабло
А технический прогресс идёт нехилыми шагами
Мне как раз сложно представить проект в котоором приходится заморачиваться хранением большого числа картинок и при этом он размещается на пятикопеечном шареде.
Да причём тут стоимость? Я вообще-то о разных настройках и ПО разных серверов. Отсюда - конкретные настройки (тех же прав доступа) под конкретную локацию. "Проблемы" при переносе, обеспечение безопасности и тп.
Те кто ратует за такой способ (они в меньшинстве), как правило работают или с Oracle или c MS SQL.
т.е. это при как правило след условиях: сервер - не апач\нгикс и "среда разработки" не ПХП ;) Ну говоря прямо - все эти плюсы могут быть только при МС-разработках (винда, до.нет, етс).