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

grizzly, я немного не сообразил. Для чего 32 коннекта? Разве не получится сделать одним запросом в один коннект?

Или вы про то что каждое фото будет получаться так <IMG src="/get_photo.php?id=1"> ?

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

как всё-таки форум хорошо показывает уровень большинства фрилансеров. дет. сад.

Это Вы про меня? Ну-ну.... Ребята, ну как можно так примитивно мыслить!!!

1. Объемы данных. Допустим, у нас есть 50 миллионов картинок. Какое хранилище данный с ними лучше справится, база данных, для которой такие объемы вполне естественны (я не имею в виду MySQL, но даже он справится, как показывает опыт), или файловая система? Вы можете себе представить как поведет себя файловая система, в которой будет например 50 миллионов файлов, пусть даже и разложенных по каталогам?

2. Метаданные. Одно дело просто хранить картинки. Но поймите, что кроме картинки нужно хранить еще массу другой информации. Например, чья это картинка, характеристики картинки, возможно комментарии автора, возможно комменты, возможно категория/каталог, и т.д. и т.п. То есть, все равно эту информацию нужно где-то хранить. Не говоря о другой информации - о том же списке пользователей.

Тут кто-то предлагал хранить XML или текстовые метаданные... А подумайте, если картинок будут миллионы... Как например их группировать по категории, по пользователям, или например по тегам? Например, я залогинился в систему. Хочу увидеть все мои картинки. Как быть, шариться по миллиону каталогов? Все равно базу данных использовать придется, как ни крути.

3. Надежность. Знаете ли вы что такое транзакции, и как они влияют на надежность? Может ли быть система, бизнес логика которой включает в себя неатомарные операции, и не поддерживающая транзакции, быть надежной? В нашем случае, если картинки хранятся вне БД, то никогда нельзя будет ручаться, что те данные, что есть в БД (я про метаданные, про принадлежность картинок тем или иным пользователям, и т.д.), соответствует тому, что находится на диске.

Не забывайте про DML операции. Например, добавляется новая картинка. Картинку скачали, в нужное место в файловой системе положили. А метаданные не положили, так как в это время какой-то сбой произошел (например в случае с PHP, скрипт умер по таймауту). Получилось что в файловой системе лежит ненужный мусор. Или наоборот, положили метаданные, с указанием что такая-то картинка есть, а саму картинку не положили из-за сбоя. Это вообще теперь нарушение целостности. Таких примеров на этой задаче может быть множество.

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

4. Кеш. Конечно, стратегию кеширования нужно выбирать в зависимости от задачи. Если нагрузка на все десятки миллионов картинок абсолютна равномерна, то можно было бы и не кешировать. Но так никогда не бывает. Обычно в тот или иной момент времени одни картинки будут показываться чаще, другие - реже.

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

5. Производительность. Если система будет оперировать с десятками миллионов картинок, тогда встанет вопрос распределения нагрузки между несколькими с серверами. С БД это решить проще простого. Также не забываем, что хранить нам нужно не только сами картинки, но и метаданные - информация о том, что это за картинка.

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

6. Выводы. Да, БД хранит информацию в файлах. Но архитектура БД (конечно, MySQL далеко не лидер в этом, и его не желательно для таких задач использовать, но даже он справится) обычно рассчитана на надежную работу с большими объемами данных. Для того базы данных и придумали.

Хранение картинок в файловой системе - это скорее ремесленническая поделка, призванная повысить производительность путем того, чтобы сделать "кеш вручную". Оно неплохо работает на небольшом количестве картинок, это факт, я сам лично не раз делал такие задачи на заказ. Но в отличие от этого, коммерческая разработка программного обеспечения накладывает ответственность на хранение данных клиентов. Поэтому я не могу предлагать ненадежное решение, разве что заказчик сам этого хочет.

Итак, если нет опыта работы с большими объемами данных, тогда выбирайте хранение каждой картинки в отдельном файле. Но, пожалуйста, не называйте детским садом то, в чем не разбираетесь, и не делайте выводов про уровень других. Где я не прав?

В случае с Apache/PHP со связкой БД+кеш, выдача картинки может производиться например так:

<IMG src="/cache/3A/51/670A7E120021.jpg" width="..." height="...">

при этом в Apache (в httpd.conf или .htaccess) будет прописано что-то типа (пишу по памяти, могу ошибиться):

RewriteCond %{REQUEST_URI} ^/cache/.*
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/cache/(+)/(+)/(+) /getimage.php?code=$1$2$3

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

tvv,
1. какие существуют ограничения на количество файлов в файловой системе (например, ntfs5)? 49КК файлов?
2. метаданные оч удобно ложатся в базу, наличие в той же базе самой картинки не обязательно
3. добавляется новая картинка. Картинку скачали, в нужное место в файловой системе положили. А метаданные не положили, так как в это время какой-то сбой произошел &
Нет ничего более надежного, чем открыть транзакцию, положить в базу данных картинку и метаданные, и закрыть транзакцию.
думай шырше.. добавляй сначала метаданные, потом картинку
начали транзакцию, положили метаданные в бд, добавили картинку, проверили ее crc, закрыли транзакцию
4. Обычно в тот или иной момент времени одни картинки будут показываться чаще, другие - реже.
и как это сказывается на производительности? ставишь сервак(lighthttpd & co) для статики и наслаждаешься жизнью
5. тут вроде уже подсказывали про репликацию файликов. не устраивает так?
6. оч убедительно... п1-5 можно было не писать)

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

1. какие существуют ограничения на количество файлов в файловой системе (например, ntfs5)? 49КК файлов?

Andreyik, ntfs5 ? Вы что, собираетесь такой проект, отдающий миллионы картинок, на Windows ставить? Да уж, мне нечего сказать....

Обычно лучшие серверные платформы - это Unix/Linux. Да, можно поставить специальные файловые системы, которые будут поддерживать работу с большим количеством файлов... но вот нюанс. Файлов может быть не более чем максимальное количество inodes. У кого есть Unix/Linux, те могут определить это командой /bin/df -i

Запустите, попробуйте, что будет? На моем хостинге, например, выдало

Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda3 38544768 10942390 27602378 29% /

То есть, максимум около 38 млн. файлов... Конечно, можно поставить другую FS, переформатировать радел указав другое количество inodes, и т.д., но в любом случае, файловая система будет крайне перегружена таким огромным количеством файлов, что неизбежно скажется на производительности.

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

4. Обычно в тот или иной момент времени одни картинки будут показываться чаще, другие - реже.
и как это сказывается на производительности? ставишь сервак(lighthttpd & co) для статики и наслаждаешься жизнью

Как раз это я в своем посте выше и описал - именно благодаря тому факту, что одни картинки будут показываться чаще, другие - реже, возможно эффективное использования кеширования. Я даже пример привел настроек для apache... По сути, при работе с кешем идет та же работа со статикой.

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

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

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

tvv,
ну а зачем ставить проект, отдающий миллионы картинок на недоось, не поддерживающую 40млн файлов?) просто помня о том, что ext2 кажись не поддерживал даже 2гб файлы насчет фс линуксов утверждать не стал

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

то в файловой системе появится картинка-мусор, с которой ничто не связано.
и чем это грозит? разрушением картины идеального мира?

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

Если хотите использовать lighthttpd - без проблем. При этом кеш можно заполнять не при первом обращении к картинкам, а при первом обращении к странице, которая эти картинки выводит. Тут возможна масса вариантов реализации.

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

Далее, еще минус хранения миллионов картинок. Допустим, сервер выключился и включился. Некорректно. Файловая система начинает чекаться, пойдут проверки... Как Вы думаете, сколько это займет времени (сколько часов?), если на винте будут 40-50 млн. файлов? А такая ситуация очень даже возможна, и все это время сервер не будет доступен.

В общем, я много что написал в своих постах выше, повторяться не буду. Аргументы постарался привести. Мое мнение: хранить 40-50 миллионов файлов-картинок в файловой системе - считаю бредом. IMHO.

В догонку. Такой кеш можно поставить и на какой-либо реализации RAM диска, пусть он и будет относительно небольшого размера, тогда скорость еще более вырастет при отдаче статики из кеша. Это все решается при определении стратегии кеширования.

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

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

Такой кеш можно поставить и на какой-либо реализации RAM диска, пусть он и будет относительно небольшого размера, тогда скорость еще более вырастет при отдаче статики из кеша.

А этот аргумент смешной.
Вау, у нас кешируется выборка из БД и даже кешируется в оперативную память!
А куда, как ты думаешь, производится кеширование файлов? Только без дополнительных промежуточных звеньев.

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

То есть, максимум около 38 млн. файлов... Конечно, можно поставить другую FS, переформатировать радел указав другое количество inodes, и т.д., но в любом случае, файловая система будет крайне перегружена таким огромным количеством файлов, что неизбежно скажется на производительности.

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

4. Обычно в тот или иной момент времени одни картинки будут показываться чаще, другие - реже.
и как это сказывается на производительности? ставишь сервак(lighthttpd & co) для статики и наслаждаешься жизнью

Как раз это я в своем посте выше и описал - именно благодаря тому факту, что одни картинки будут показываться чаще, другие - реже, возможно эффективное использования кеширования. Я даже пример привел настроек для apache... По сути, при работе с кешем идет та же работа со статикой.

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

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

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

А таблица с 38ю миллионами записей, думаете, будет быстрее работать?

Мусор из-за нарушения транзакционности... Думайте шире, а если начать транзакцию, добавить метаданные, закрыть транзакцию и не добавить картинку в файловую систему?

"Кэширование"...Оно вообще не потребуется, если использовать ФС. Вернее, им будут заниматься буферы IO и дискового контроллера.

Кроме того, нет никакого увеличения производительности, если разделять хранилище файлов на папки. С таким же успехом можно покрасить сервера в красный цвет и ждать повышения быстродействия Я имею в виду, скорость доступа к файлу от этого совершенно не изменится. На файловых системах, где используются inode, при открытие файла идет поиск суперблока в хэше узлов по индексу. Хэш-таблица хранится в памяти, поиск по ней идет бинарный.

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

Далее, еще минус хранения миллионов картинок. Допустим, сервер выключился и включился. Некорректно. Файловая система начинает чекаться, пойдут проверки... Как Вы думаете, сколько это займет времени (сколько часов?), если на винте будут 40-50 млн. файлов? А такая ситуация очень даже возможна, и все это время сервер не будет доступен.

А если база (на 40-50 млн. записей - это ж 5 террабайтов, если картинки в среднем по 100к ) упадет из-за некорректного выключения? Из бэкапа будете ее быстрее поднимать?
Надо использовать репликацию и резервные железки - в обоих случаях.

Мы опять рассматриваем сферического коня в вакууме.

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

Ограничения на количество файлов. Есть очень разные файловые системы - некоторые иноды выделяют автоматически, некоторые нет.

Скорость восстановления после краха - опять же, некоторые ФС делают это не часы а минуты и секунды. Может быть такая специфика, что восстановление вообще не потребуется - если использовать readonly системы, что в данном случае более чем реально.

Не надо забывать, что если у нас на _одной_ машине 50.000.000 файлов - трафик с неё может быть огромным, обязательно потребуется распределение, а это сделать легко с файлами на readonly системах.

Наверняка в реальности в больших хранилищах используется комплекс мер, но у меня огромные сомнения, что всё может храниться в традиционной (mysql, postgres и т.д.) базе - даже откат гигабайтной транзакции будет проблемой.

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

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

даже откат гигабайтной транзакции будет проблемой.

О каких гигабайтных транзакциях речь?

SolNikolay, фотографии сейчас весят по несколько десятков мегабайт.
Если это будет PSD с несколькими слоями и 48-битным цветом, то пара сотен мегабайт на файл наберется.
И даже десятимегабайтные транзакции -- это уже повод подумать о том, стоит ли эту информацию хранить в базе.

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

Я думаю, что система управлениями картинками должна примерно так строиться - просто первое что в голову пришло:

1) мегамонстр, в котором в базе или ещё как-то очень надёжно хранятся изображения и метаинформация;
2) несколько систем-хранителей метаинформации и, возможно, превьюшек;
3) сеть простых как валенок компьбтеров, единственная задача которых ранить файлы и отдавать их.

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

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

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

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

VistaSolutions, я именно про это. какие ещё варианты, если кэш не используем?
Pilat66, да, я на своей домашней страничке так и делаю.
perldev, Цитата:

Кроме того, нет никакого увеличения производительности, если разделять хранилище файлов на папки

всё зависит от типа фс.

распределённое хранилище на фс сделать не проблема - по-этому репликация это не аргумент. в тоже время, не дёргая бд получаем прирост производительности, допустим 10% на каждом сервере. если серверов 10, получаем прирост 100% - экономим на 1 сервере.

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

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

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

что происходит, когда мы обращаемся к последнему байту последнего файла? в первом случае мы пробегаем по цепочке и последовательно вычисляем следующий сектор до конца. если предоложить, что размер блока в 16к, то имеем (10^11/2^14=100*20^16=6553600 - 6 милионов итераций прохождения по цепочке. Если не верите, что это так много, то создайте такой файл и через Far и F3 перейдите в конец файла).

во втором случае предполагаем, что файлы не разбиты на каталоги и не сортированы для оптимизации поиска. понадобиться 100 000 итераций строковых сравнений (примерно в 4 раза дольше итерации прохождения по цепочке) - 400 000, затем 10^6/2^14=2^6=64, в сумме 400 064 итерации, что в полтора раза выгоднее обращения к одному большому файлу. теперь учитываем, что файлы можно разбивать по каталогам, например 2 уровня вложенности, по двум первым 16-ричным цифрам контрольной суммы имени для нормального распределения - делим результат на 256 и прибавляем - 2*16*4 (затраты на поиск каталога), итого менее 2000 итераций.