Сохранение jpg в БД

1 23
Mik Foxi
На сайте с 02.03.2011
Offline
1177
#21

Плюсы базы:

1) открытие рандомной картинки из базы (тестил sqlite) по сортированному id быстрее чем искать одну из 100500 картинок на файловой системе.

2) бекапить один дамп быстрее, чем копировать 100500 картинок.

3) разграничение прав доступа (приватные фотоальбомы например).

Минусы:

1) потребление ресурсов, особенно оперативки, особенно если сравнивать отдачу медленным клиентам пхп+апач+база против отдача статики через лайти/нгинкс.

Антибот, антиспам, веб файрвол, защита от накрутки поведенческих: https://antibot.cloud/ Форум на замену серчу: https://foxi.biz/
S
На сайте с 23.05.2004
Offline
315
#22
MS утверждает что как раз в базе (MS SQL) и нужно хранить файлы.

У оракла вообще возможность стримить видео из базы есть.


не все БД одинаково заточены под работу с двоичными данными, тот же MS SQL 6.5 с ними плохо работал, сейчас допилили.

А ничего что 6.5 версия примерно 12 лет давности ? :)

Это просто подпись.
I
На сайте с 23.12.2010
Offline
25
#23
'[umka:
;10754790']😮 Это откуда такая информация?
Файл открывается fopen()-ом за один вызов.

я неправильно выразился, прошу прощения.

суть моего сообщения была в том, что в файловых системах чтобы достучаться до файла нужно последовательно открыть все директории, которые по сути обыкновенные файлы (directory files)

'[umka:
;10754790']
А представьте, какое количество fseek()-ов делает база для поиска нужных данных в файле-таблице с использованием бинарного индекса.

как бэ давно показано что поиск по дереву существенно быстрее последовательного поиска.

'[umka:
;10754790']
База делает fopen() как минимум каждый раз, когда возникает временная таблица.
Это я всё об MySQL.

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

[umka]
На сайте с 25.05.2008
Offline
456
#24
iopiop:
нужно смотреть на конкретную реализацию СУБД и на конкретную реализацию ФС.

Угу... ведь во-первых, дерево директорий — это то же бинарное дерево, если речь идёт о поиске файла. Но если мне не изменяет память, то даже в древней ФС FAT, в этой самой FAT сразу хранился адрес файла на диске. Не думаю, что в современных файловых системах нужно последовательно открывать все директории, чтобы открыть файл :)

Лог в помощь!
S
На сайте с 23.05.2004
Offline
315
#25
что в файловых системах чтобы достучаться до файла нужно последовательно открыть все директории

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

I
На сайте с 23.12.2010
Offline
25
#26
'[umka:
;10755936']Угу... ведь во-первых, дерево директорий — это то же бинарное дерево, если речь идёт о поиске файла. Но если мне не изменяет память, то даже в древней ФС FAT, в этой самой FAT сразу хранился адрес файла на диске. Не думаю, что в современных файловых системах нужно последовательно открывать все директории, чтобы открыть файл :)

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

в ФАТ надо последовательно открывать все директории.

1 23

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий