Хранение графической информации - где?

Цитата ("Pilat66"):

Цитата ("TO4KA"):

Цитата:

Я видел, как php-шники с ними работают - вероятность потерь 100%

Обоснование будет? У меня под контролем работает на MySQL база регионального медстраха на несколько сотен тысяч человек. Около 500 дней аптайма. Бэкап (делается ежесуточный и еженедельный) ни разу не был востребован. Что я делаю не так?

Сходу - то, что бэкап ни разу не проверялся, правильно? Может, его и восстановить нельзя? Частая ситуация.
Делать медстрах на mysql - это вообще преступление. Обосновывать не буду, это в суде объяснят при первом же спорном случае.

Далее, представьте, что у Вас не крохотная базка на 100 тысяч человек - размером в несколько мегабайт (ну пусть гигабайт , а монстр из картинок на терабайты. Как его бэкапить быстро?

Умнйы бекап, добавлять в бекап файл только новые данные..

Akkort, о таких файловых системах речь не идёт.

Tvv:
1) ну СУБД с ними же как то управляется, ФС пишут тоже не глупые люди, да и СУБД ипользует ФС (ну и размерчик 50e6*500кб = 2.5e10кб = 2.4e7гб = 2.3e4тб . как держать такие размеры в бд я не представляю, а вы ?)
3) тут можно пойти простым путем, загрузка -> песочница -> основное хранилище
4) перечитайте вычеркнув "из кеша": "По сути дела, скорость выборки из кеша будет соответствовать скорости выдачи картинок из файловой системы."
5) узким местом будет getimage.php

далее по доводам я согласен с Pilat66.

e1it3, ну, так Pilat66 предлагает по сути тот же вариант что и у меня, только кеш у него безразмерный, то есть, распространяется на все картинки-файлы, и заполняется не по запросу извне, а при каком-либо изменении в основном хранилище.

СУБД будет нормально работать с большими базами данных, измеряемых терабайтами. Они на это рассчитаны. В частности, у меня есть положительный опыт работы с Oracle на таких объемах. Тут же необходимо помнить, что практически все крупные СУБД позволяют хранить информацию не в одном огромном файле, а в нескольких, в том числе на разных разделах. Это все уже давно отработано, и очень надежно.

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

Насчет MySQL - есть сомнения, но можно поставить эксперимент и проверить, лично я не проверял как он себя ведет на терабайтных объемах (максимум на моей преактике с MySQL - около 180 Gb - полет нормальный, система уже почти два года в продакшене, кстати картинки там именно в БД+кеш+реверс_прокси, правда, там не PHP, а Java/J2EE).

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

Цитата ("tvv"):

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

Объясните, почему другая ситуация с видео?

Если размер видео будет, скажем, 1 Gb, и одновременно 100 пользователей решат зааплоадить такие видео, то как Вы думаете, как на это отреагирует transaction manager?

tvv,
то как Вы думаете, как на это отреагирует transaction manager?
да оч просто он отреагирует
компания Oracle может себе позволить нанимать лучших разработчиков планеты, и создавать продукты, которым тысячи крупных мировых компаний доверяют свои терабайты данных©

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

Andreyik, не в любом случае, а в данном случае (файлы-фотографии).
Для небольших файлов смысл хранения их в БД есть. Для случаев, когда файлы являются вспомогательной сущностью и их мало -- тоже есть.
А вот когда медиа-контент является основной сущностью, тогда БД нужна только для хранения метаинформации.

Ну допустим зачем хранить тз к проектам на этом сайте в бд? какая от этого польза?

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

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

Цитата ("tvv"):

СУБД будет нормально работать с большими базами данных, измеряемых терабайтами. Они на это рассчитаны. В частности, у меня есть положительный опыт работы с Oracle на таких объемах. Тут же необходимо помнить, что практически все крупные СУБД позволяют хранить информацию не в одном огромном файле, а в нескольких, в том числе на разных разделах. Это все уже давно отработано, и очень надежно.

Оракл один, или с системой репликации на разных континентах? Центральную базу - в моей терминологии систему 1, вполне можно на оракле держать и даже нужно. А как 100 копий этого оракла по планете раскидать? А это вполне реализуемо при хранении в файлах, причём надёжность выше за счёт многократного дублирования, обслуживание проще, стоимость ниже плюс возможность использовать сервисы типа akamai.

Цитата ("tvv"):

Если размер видео будет, скажем, 1 Gb, и одновременно 100 пользователей решат зааплоадить такие видео, то как Вы думаете, как на это отреагирует transaction manager?

12-тимегапиксельная фотография в raw и 16 бит даст файл в 24 мегабайта, - не всякое видео с ютуба такое большое.

alibek, а где грань, между большим и маленьким файлом? где грань между много файлов - мало? в чём смысл использовать ненужное звено в виде бд? да в конце концов, нужно думать о расширяемости. планировался проект с малым количеством файлов, например как здесь аттачи к проектам - по сути не основная сущность, раскрутился раздел "обработка фотографий", стали к проекту приляпывать десятки рав файлов по 17 мб или ещё хуже, тиффы. и что, переписывать систему, с хранения в бд на фс?

кто-нибудь может сформулировать преимущества хранения файлов в бд, помимо псевдо целостности, которую можно реализовать и с хранением файлов в фс, которую с лихвой перекрывают минусы этого подхода???

Файловая система не следит за сохранностью файла. Пропал файл - ругнётся при fsck и перенесёт его в директорию с потерями.
База данных более аккуратна - система поддержки целостности, взаимные ссылки, которые контролируются базой...

ЗЫ
MySql, естественно, не рассматривается как база в этом контексте.

Pilat66, возможно вы имели в виду -файловая система FAT(32) не следит... ? в нормальной файловой системе файлы пропадают только вместе с осыпающимся диском и никуда не девауются даже если вырубить питание при дефрагментации

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

А здесь про архитектуру YouTube ссылка

Цитата ("Andreyik"):

Pilat66, возможно вы имели в виду -файловая система FAT(32) не следит... ? в нормальной файловой системе файлы пропадают только вместе с осыпающимся диском и никуда не девауются даже если вырубить питание при дефрагментации

Всё пропадает на всех ФС - а насколько часто, определяется количеством файлов.
Журналирующие ФС, например, от пропадания файлов не защищают, FAT не защищает, тогда какие защищают?

Pilat66,
Журналирующие ФС, например, от пропадания файлов не защищают настолько же верно как "транзакционные бд не защищают от пропадания записей"