Когда файлы хранят в БД???

[Pattern]

насколко я помню это в handbook было написано что при открытии каталога используються специальный кэш, т.к. это ресурсоемко

Абсолютно верно подмечено, открытие такого каталога напряжет систему достаточно... НО! А зачем открывать каталог? Ты же будешь обращаться непосредственно к какому то конкретному файлу (например, /path/to/target/file). В по каталогам шариться вовсе не обязательно, даже через скрипты, тем более что путь то к файло будет всегда один.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[zg]

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

[Pattern]

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

Можно подробнее пояснить, какое это отношение имеет к хранению данных в БД и обмену данных??? И... мы разве говорим о HTML? По моему тут вопрос не конкретизировался...

[zg]

И... мы разве говорим о HTML?

ага почитай первый пост. Да и вообще, кроме как для вэба подобной проблемы никогда не было. А вэб - это HTML 4

Можно подробнее пояснить, какое это отношение имеет к хранению данных в БД и обмену данных???

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

[Pattern]

почитай первый пост.

И вам того же советую.

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

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

[zg]

Одно дело - отрисовывать где-либо какие то данные, другое дело - организовать для этих данных хранилище

при отрисовке страницы в HTML4 с 50 картинками потребуется обработать 51 запрос. HTML5 позволяет вставлять картинки и файлы в тело страницы, в результате всю страницу можно будет сформировать за один запрос.

И вам того же советую.

и что там есть, чего я не увидел?

[Pattern]

при отрисовке страницы в HTML4 с 50 картинками потребуется обработать 51 запрос. HTML5 позволяет вставлять картинки и файлы в тело страницы, в результате всю страницу можно будет сформировать за один запрос.

От того что у вас страница будет формироваться за один запрос, ни MySQL-серверу, ни тем более файловой системе от этого легче не станет. Скуль как хранил в себе данные так он в нём их хранить и будет, к файловой системе как шли обращения, так они и останутся, вне зависимости от того какой будет HTML, хоть 5, хоть 10. Да, несомненно, это упростит запросы. Но ещё раз повторюсь, что к хранению данных, прорисовка страниц не имеет никакого отношения.

и что там есть, чего я не увидел?

не знаю, всё зависит от того, что вы там пытались увидеть. Во всяком случае, я там не увидел ни единого упоминания о HTML.

[zg]

От того что у вас страница будет формироваться за один запрос, ни MySQL-серверу, ни тем более файловой системе от этого легче не станет.

ну да, а ддос, страшилка для плохих админов

Но ещё раз повторюсь, что к хранению данных, прорисовка страниц не имеет никакого отношения.

51 запрос и 1, разница есть? умножь 51 запрос на 1000 человек в день и уже будет разница очевидна. А с учётом того, что mysql умеет считать количество запросов и некоторые провайдеры пользуются этим, то второй вариант гораздо привлекательней.

Во всяком случае, я там не увидел ни единого упоминания о HTML.

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

[Pattern]

От того что у вас страница будет формироваться за один запрос, ни MySQL-серверу, ни тем более файловой системе от этого легче не станет.

ну да, а ддос, страшилка для плохих админов

Судя по ответу, вы, первое что вам пришло в голову решили ответить, дабы хоть что то ответить. Это то здесь к чему вообще?

51 запрос и 1, разница есть? умножь 51 запрос на 1000 человек в день и уже будет разница очевидна. А с учётом того, что mysql умеет считать количество запросов и некоторые провайдеры пользуются этим, то второй вариант гораздо привлекательней.

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

Во всяком случае, я там не увидел ни единого упоминания о HTML.

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

СМС-сервис. По защищенному каналу от ОпСоСа на сервер поступает запрос, что некий пользователь запросил какой то файл, скрипт обрабатывает такой запрос, из БД выхватывает данные о файле, сам файл берёт из файловой системы, данные упаковываются и отправляются обратно. Файлы лежат отдельно от БД, а в БД хранятся только данные о них. Где здесь HTTP? Где здесь HTML?
Так штаа.... В первом посте не говорилось, что разговор идет о HTML, не увиливайте от ответа. Вы ещё ни на один мой вопрос по существу не ответили.

[zg]

из БД выхватывает данные о файле, сам файл берёт из файловой системы

две операции чтения с диска вместо одной

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

а разработчик то тут при чём? если браузер каждую картинку грузит всегда отдельным запросом?

Где здесь HTTP? Где здесь HTML?

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

[Pattern]

А вот это уже по делу

из БД выхватывает данные о файле, сам файл берёт из файловой системы

две операции чтения с диска вместо одной

Согласен. Однако трудозатрат на эти 2 операции уйдёт гораздо меньше, чем если файл будет лежать в таблице. Я надеюсь, что мы говорим не о 2-3 записях и файлах, а как минимум 10к+...

а разработчик то тут при чём? если браузер каждую картинку грузит всегда отдельным запросом?

Про разработчика я сказал так, что подумал вы говорите, что на каждую картинку делается запрос к MySQL. Потому и был удивлён, кто такие запросы делает??? Теперь я понял про что вы говорите. Только такие картинки лежат физически доступными для конечного пользователя (например, http://my.site.com/images/picture.gif). И пользователь в любой момент может обратиться к этому файлу.
Я же выше описывал именно создание файлового хранилища, к которому прямого доступа извне нет, только через обработку запроса на какой то файл.

[zg]

Я надеюсь, что мы говорим не о 2-3 записях и файлах, а как минимум 10к+...

10+ даёт нехилую нагрузку на фс, особенно, если все они лежат в одной папке. Если файлы сравнительно мелкие и соединение идёт через uniix-сокет, то база будет эффективней.

[Gerk]

Хранение файлов в базе данных это путь в никуда, MySQL точно не переживет.
ИМХО, таким программистам нужно отрывать руки.
Быстродействия никакого, востановление/резервирование сплошное издевательство,
СУБД сервер жрет кучу ОЗУ и как правило нестабилен.
Оптимальное решение - ссылки на файлы, и правильная структура каталогов.

1 милион файлов от 1 до 50 Мб..... это база 500-1000 Гбайт

[zg]

ИМХО, таким программистам нужно отрывать руки.

начни с разработчиков PDO, которые встроили загрузку-выгрузку файлов в базу на уровне драйвера

MySQL точно не переживет.

файлы до 64кб будут прекрасно храниться и в исаме и иннодб

СУБД сервер жрет кучу ОЗУ и как правило нестабилен.

ты это щас к чему?

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

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

1 милион файлов от 1 до 50 Мб..... это база 500-1000 Гбайт

при правильной организации таблицы муся это потянет.

[Gerk]

ИМХО, таким программистам нужно отрывать руки.

начни с разработчиков PDO, которые встроили загрузку-выгрузку файлов в базу на уровне драйвера

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

MySQL точно не переживет.

файлы до 64кб будут прекрасно храниться и в исаме и иннодб

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

СУБД сервер жрет кучу ОЗУ и как правило нестабилен.

ты это щас к чему?

Опытным путём для себя вывел, что наличие большие БД вызывает большие проблемы с обеспечением доступности, резервированием и восстановлением БД.

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

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

Не совсем понимаю зачем Вы задавали этот вопрос...
Все это реализуется с помощью Web-скриптов + штатных средств ОС по разграничению доступа.
ИМХО, ссылки на файлы + статистика загрузок это более подходящий тип инфы для размещения в БД, чем большие файлы (blob'ы).
Хотя на практике, каждая вторая баннерная система, написанная очередным "мегакодером" создает сумашедшую нагрузку на СУБД пытаясь записать
каждый клик....

1 милион файлов от 1 до 50 Мб..... это база 500-1000 Гбайт

при правильной организации таблицы муся это потянет.

Я с базами больше 50 Гб не работал, MySQL базы данных больше 10 Гб это п..ц.

[zg]

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

то есть 99%? котуда столько ненависти?

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

никак не упадёт. Чего ради ей падать?

Опытным путём для себя вывел, что наличие большие БД вызывает большие проблемы с обеспечением доступности, резервированием и восстановлением БД.

ааа, ну понятно почему ты ненавидишь программеров

Не совсем понимаю зачем Вы задавали этот вопрос...

то есть ты никогда не реализовывал подобные скрипты?

Хотя на практике, каждая вторая баннерная система, написанная очередным "мегакодером" создает сумашедшую нагрузку на СУБД пытаясь записать каждый клик....

правильно настроенная БД должна держать подобную нагрузку, за это админам и платят

Я с базами больше 50 Гб не работал, MySQL базы данных больше 10 Гб это п..ц.

даже база в 55 мегабайт это ппц, если использовать кривые запросы. Размер не главное.

[Pattern]

Чёт ребят мне кажется разговор не в ту сторону завернулся... Каждый сам для себя решил что ему предпочтительнее. Для меня предпочтительнее когда "мухи отдельно, котлеты отдельно" Каждый по своему прав, к чему все эти споры "чьи в лесу шишки"?

[Alex Keda]

Хотя на практике, каждая вторая баннерная система, написанная очередным "мегакодером" создает сумашедшую нагрузку на СУБД пытаясь записать каждый клик....

правильно настроенная БД должна держать подобную нагрузку, за это админам и платят

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

[Alex Keda]

2 zg
сразу видно программиста - то что программеру платят за прямой код, ты не упомянул.
зато быстро припахал администраторов расхлёбывать наделанное )

[zg]

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

если бы программистам платили за прямой код, то они бы сдохли с голоду

зато быстро припахал администраторов расхлёбывать наделанное

зачастую кривой код компенсируют железом, а расхлёбывают, ага, админы Я, кстати, как раз работаю над одним таким проектом. Под него уже второй сервак собрали.

[Fastman]

если бы программистам платили за прямой код, то они бы сдохли с голоду

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

Я, кстати, как раз работаю над одним таким проектом. Под него уже второй сервак собрали

Все мы работаем над такими проектами Неизбежное зло и опыт на них стоит больше чем пачка сертификатов

[Alex Keda]

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

если бы программистам платили за прямой код, то они бы сдохли с голоду

по твоему, это повод перевешивать свои косяки на других - пусть расхлёбывают?!

[zg]

по твоему, это повод перевешивать свои косяки на других - пусть расхлёбывают?!

-)))) дак так всегда делали, делают, и будут делать. В веб-проектах, кстати, это проявляется особенно сильно, потому что разрабатывают проект одни, а ведут потом другие.

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

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

[ProFTP]

лисяра, по твоему распределенные FS для прикола сделали...?

NOOFS - file system storing its data in an SQL relational database.

Файловая система, использующая в качестве хранилища данных SQL базу, в частности PostgreSQL.
# Функциональность: Создание единого хранилища данных в сети;
# Расширенные средства управления безопасностью;
# Функции быстрого поиска файла;
# Хранение расширенной информация об элементе ФС;
# Виртуальное управление директориями - папки с динамически формируемым содержимым;
# Встроенные средства по управлению целостностью данных.

MogileFS - open source distributed filesystem

Распределенная файловая система созданная в рамках проекта LiveJournal и реализованная на уровне многоплатформенного приложения на Perl.

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

Для каждого файла задается его класс, определяющий на какое число соседних машин от будет реплицирован. Отлично подходит для создания распределенных web-проектов и как средство создания высоконадежного хранилища данных, не прибегая к использованию RAID. Доступ пользовательских приложений к ФС осуществляется посредством HTTP запросов (PUT/GET) или через использования виртуального NFS тома.

Perlbal - система балансировки нагрузки на Perl, представленная на том же сайте. Отличный пример как нужно писать высокопроизводительные приложения на Perl.

http://www.danga.com/mogilefs/

ЗЫ: для небольшой или средней нагрузки скорее всего все равно
ЗЫЫ: напрмиер если картинки (файлы) будут в базе, и если будет нагрузка из-за них, то картинки всегда можно перенести на fs и наоборот... (если их много, то некоторое время может занять)

[Fastman]

Присутствуют операции создания файла (путь к файлу представляет собой множество ключей в рамках заданных доменов, информация о файлах хранится в MySQL базе)

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

Распределенные файловые системы в первую очередь нацелены на то, чтобы предоставить унифицированный доступ к большому количеству данных, размазанных по множеству хранилок/либо между нодами. Все... от файловой системы мне нужно:
- Надежность
- Атомарность операций
- Управляемость(желательнор на лету без остановки сервиса)
- Отслеживание коллизий и ошибочных ситуаций.

Добавление в файловую систему свойств которые будут относится ко всему остальному - черевато усложнением логики/обслуживания/надежности.