Где хранить изображения: база данных vs файловая система(холивар)

r

Если ты имеешь ввиду пункты 1..4 - то они все заточены на RDBMS.

как вас понимать? для хранения картинок и доступа к ним по имени надо юзать RDBMS?

Почему такое отношение к этой БД? Вообще я только с этой БД плотно работал, приходится работать с DB2 на AIX, но редко, поэтому серьезные сравнения с другими, из своего опыта, сделать нет возможности.

Меня надо понимать так что все те вопросы которыё ты описал в пунктах 1..4 относятся к RDBMS. Это как предъявлять претензии к кораблю сухогрузу по поводу отсутствия откидывающегося кузова, и возможности прицепить прицеп.

а что делать для удаления +120?

помечать маркером «удалено». Физически не удалять. Место закончится - подрубить еще один жесткий. Можно придумать что-нибудь для сильно отложенного garbage collection.

мне честно говоря всё равно. Факт тот, что в конечном итоге это всё в любом случае сводится к одной из описанных Кнутом структур.

т.е. вопросы практики тебя не интересуют? занятно

r

Меня надо понимать так что все те вопросы которыё ты описал в пунктах 1..4 относятся к RDBMS.

давайте определимся: те пункты - это не вопросы. Это ограничения. Например у ФС всего один независимый индекс. У RDBMS тоже? Ну и далее по остальным...

r

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

можно пример попроще? Вот в чём в чём, а в сухогрузах я не очень. Они на Неву редко заходят, и до меня точно не доплывают. :-)

В любом случае, вы что-то неправильно понимаете - я не предъявлял претензии, это глупо ИМХО. Это как предъявлять претензии к отвёртке, что ею гвозди плохо заколачивать.

stevejobs

помечать маркером «удалено». Физически не удалять. Место закончится - подрубить еще один жесткий. Можно придумать что-нибудь для сильно отложенного garbage collection.

а как тогда сработает ссылка? придётся её как-то перенаправить... Или придётся опять-таки хранить коллекцию удалённых картинок. Или придётся сами данные менять (что не получится, может не влезть). У вас ведь жёстко прописано +120, и что с этим делать?

stevejobs

т.е. вопросы практики тебя не интересуют? занятно

вот как раз вопросы практики меня интересуют. Но собирать велосипеды, которые уже были собраны 50 лет назад - мне не интересно. Благо и собирали люди поумней меня, и ещё всё математически обосновали.

Например у ФС всего один независимый индекс.

То есть индексы которыё я наблюдаю в своих файловых хранилищах мне че - привиделись?

2,3 - вообще чистые понятия из rdbms.
4 - вообще бред - при чем тут длина строки и размер блока?

r

То есть индексы которыё я наблюдаю в своих файловых хранилищах мне че - привиделись?

про какие ты индексы?

r

2,3 - вообще чистые понятия из rdbms.

возможно. И что?

r

4 - вообще бред - при чем тут длина строки и размер блока?

блжд, а причём тут твоя rdbms??? я про неё не в курсе. Это про ФАЙЛОВУЮ СИСТЕМУ, в данном случае ext4.

Это как предъявлять претензии к отвёртке, что ею гвозди плохо заколачивать.

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

А реляционная алгебра - это не бохпослалкусочексыра - единый правильный универсальный путь хранения данных подходящий для всего - это неверное в корне понимание СУБД. СУРБД - это подмножество СУБД. Система управления _реляционной_ базой данных. Так вот чтобы управлять базой данных имеющей реляционную структуру всякие оракелы разрабатывают СУРБД.

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

Это покореженная логика. Это как выбирать формат хранения данных посмотрев какая программа установлена. Так делают обычные пользователи - у них есть ворд - потому документы хранятся в .doc. Это бред.

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

про какие ты индексы?

Про те которыё я создал самостоятельно.

возможно. И что?

То есть файловая система плохая - потому что не реляционная?:)

Это про ФАЙЛОВУЮ СИСТЕМУ, в данном случае ext4.

Почему ты хочешь хранить строки в блоках файловой сиcтемы?

а как тогда сработает ссылка? придётся её как-то перенаправить...

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

r

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

бред какой-то. чини детектор. мне такой херни и в голову не могло придти.

r

Про те которыё я создал самостоятельно.

ну вот. А в ФС есть только один индекс. И никаких индексов ты больше создать не можешь. Теперь понял, что это не какая-то СУРБД? А совсем другая вещь.

r

То есть файловая система плохая - потому что не реляционная?:)

нет конечно. хватит за меня всякий бред придумывать! ФС не плохая, и не хорошая.

r

Почему ты хочешь хранить строки в блоках файловой сиcтемы?

потому-что «строками» я(здесь) называю некоторую информацию. Это не обязательно последовательность ASCIIZ.

И никаких индексов ты больше создать не можешь

Как это не могу? Я их создал.

Теперь понял, что это не какая-то СУРБД?

А что кто-то называл ФС - СУ_Р_БД?

потому-что «строками» я(здесь) называю некоторую информацию.

С чего ты взял что информация длиной ~50?

stevejobs

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

garbage collection теперь время не занимает?

r

Как это не могу? Я их создал.

завязывай с веществами, я про фс.

r

А что кто-то называл ФС - СУ_Р_БД?

ты и называл :-)

r

С чего ты взял что информация длиной ~50?

я ничего не брал. я лишь говорил о том, что не экономно хранить 50и байтовую инфу, в 4096и байтовых контейнерах.

занимает. Раз в N времени. Например раз в месяц, или раз в год, или раз в тысячу лет.

stevejobs

занимает. Раз в N времени. Например раз в месяц, или раз в год, или раз в тысячу лет.

а до той поры мы будем заходить на +120, и получать старую удалённую картинку?

да. Ну или null, или 404: драйвер читает по адресу +120 первый байт, и на основе него выдает ответ (тот самый «маркер удаления»)

ладно. А какие плюсы у этой системы?

Почему такое отношение к этой БД? Вообще я только с этой БД плотно работал, приходится работать с DB2 на AIX, но редко, поэтому серьезные сравнения с другими, из своего опыта, сделать нет возможности.

Я как-то попробовал поплотнее поработать с PgSQL и местами чисто из-за хранимок он выигрывает. Просто удобнее и логичнее для меня. И да, у нас основной это MySQL, сейчас Percona тестится.

завязывай с веществами, я про фс.

Я тоже про нее.

ты и называл :-)
завязывай с веществами,

я лишь говорил о том, что не экономно хранить 50и байтовую инфу, в 4096и байтовых контейнерах.

А зачем ты ее хочешь так хранить?

r

я лишь говорил о том, что не экономно хранить 50и байтовую инфу, в 4096и байтовых контейнерах.

А зачем ты ее хочешь так хранить?

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

найди в этой цитате, где я чего-то хочу.

Зачем ты задал вопрос про ~50 длину строки и размер блока?

drBatty

Размер блока данных в EXT равен 4К, потому хранить в такой БД строчки в ~50символов не экономично.

r

Зачем ты задал вопрос про ~50 длину строки и размер блока?

не было никакого вопроса. Было утверждение. Ты с ним не согласен?

Да и вообще, я если спрашиваю, специальный значок ставлю, код 63 или 0x3F.

не было никакого вопроса. Было утверждение.

ЗАчем ты его сделал?

еблоб с похмелом уже предлагали http://www.ioremap.net/ ?

тред не читал.

r

ЗАчем ты его сделал?

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

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

Ты считаешь что хранить строку в 50 символов лучше в RDBMS?

r

Ты считаешь что хранить строку в 50 символов лучше в RDBMS?

я считаю, что в MySQL 1М таких строчек будут занимать намного меньше места, и обрабатываться быстрее. Я не прав?

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

я считаю, что в MySQL 1М таких строчек будут занимать намного меньше места, и обрабатываться быстрее. Я не прав?

Нет. У меня сейчас есть геобаза - файл csv 2.5GB, 13M записей. 1 сервер держит 140k запросов в минуту (это не предел - больше просто никто не спрашивал). Индекс занимает пол гига.

Можешь попробовать запихнуть такую хрень в мускуль и скажешь потом что занимает меньше места или быстрее работает.

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

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

r

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

а ты вообще сабж читал? Давай откроем другую тему, и уже в ней обсудим RDBMS vs ЧТО? DBMS?

Здесь я пишу исключительно ФС vs DB. Разве это так сложно понять?

а ты вообще сабж читал?

ТАм чувак спрашивает где ему хранить строки по 50 символов?

Здесь я пишу исключительно ФС vs DB. Разве это так сложно понять?

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

Почему когда говоришь об индексах ты ссылаешься на юзерскую (то что может создать пользователь) сущность в RDBMS (create index), а когда говоришь об FS - на внутреннюю структуру FS на которую пользователь не имеет никакого влияния? Почему когда ты ссылаешься на RDBMS ты говоришь о внешнем таблично/строчном представлении данных - по сути интерфейс, а когда говоришь об FS ссылаешься на его внутренние блоки?

Ты говоришь строка в 50 байт с блоком в 4 к займет на файловой системе 4к. Ты думаешь в mysql она займет 50 байт?

r

ТАм чувак спрашивает где ему хранить строки по 50 символов?

не, там чувак спрашивает, где ему картинки хранить.

r

Почему когда говоришь об индексах ты ссылаешься на юзерскую (то что может создать пользователь) сущность в RDBMS (create index), а когда говоришь об FS - на внутреннюю структуру FS на которую пользователь не имеет никакого влияния?

потому и говорю, что в ФС уже есть один индекс ключ->значение (имя файла->содержимое файла), и изменить это мы никак не можем. А если нам это и не нужно? Если нам достаточно одного этого индекса?

r

Почему когда ты ссылаешься на RDBMS ты говоришь о внешнем таблично/строчном представлении данных - по сути интерфейс, а когда говоришь об FS ссылаешься на его внутренние блоки?

ну потому, что внутреннее представление каталогов ФС и индекса БД построено по одним и тем же принципам, и подчиняется одним и тем же правилам. Что до внешнего представления, то это не такая уж проблема - напиши обёртку, что-бы получить нужное внешнее представление. Эта обёртка будет довольно дешёвой, если конечно число эл-тов достаточно велико.

r

Ты говоришь строка в 50 байт с блоком в 4 к займет на файловой системе 4к. Ты думаешь в mysql она займет 50 байт?

ну не 50 конечно, но не очень-то и много, если например использовать VARCHAR(100). Уж никак не 4096 байтов. А вот в ФС у нас практически нет иного выбора.