Файловая система в качестве базы данных

[/dev/random]

Морду можете написать сами. При помощи fpc или OOoBase сделаете это часа за три.

В качестве морды существует куча FUSE-based файловых систем, хранящих файлы в БД.

[mix1m]

Ты выше упомянул про "2e6 файлов" в одном каталоге - это обнадёживает. Вполне возможно, что простым выходом будет просто посвалить все файлы в один каталог. Благо - весь /home на ext4.

Вот мы и пришли к классическому на сегодняшний момент состоянию дейтабейзинга.

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

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

[gcc]

ну и если будет в каталоге 100млн файлов

То на 1TB винте это -значает, что каждая фотка (про фотки см. посты serzh-z выше) занимает не более 10KB…

а причем тут это?
"1TB винте"?
...если это домашняя коллекция...
просто, автор топика сам не знает то, что он хочет...

[Crazy]

Да-да-да. Я вообще рекомендую для домашней коллекции фоток использовать сразу кластер, GFS и MapReduce для обработки. Кластер — обязательно в стойках должен стоять, для лёгкого наращивания мощностей.

В топку кластер http://mcslp.com/category/technology/grids/.

[diesel]

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

Ну при перечислении 2e6 файлов Nautilus будет тормозить, думаю, на любой ФС. Всякая графическая дребедень (и даже, подозреваю, псевдографическая, вроде mc) не годится для такого, ибо пытаются сделать много лишнего. А когда это лишнее помножено на 2e6, то получается РЕАЛЬНО МНОГО. Так что, только shell. А Nautilus'ом и прочими mc можно бегать по тем каталогам с симлинками.

ls на 2e6 будет тоже не больно то быстр особенно если не ls > file.

[diesel]

Ты выше упомянул про "2e6 файлов" в одном каталоге - это обнадёживает. Вполне возможно, что простым выходом будет просто посвалить все файлы в один каталог. Благо - весь /home на ext4.

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

Для операций с архивом картинок - нет, третьего шага не будет. и таки есть подозрение что те же восемь классических реляционных операций Сержу там нафиг не нужны. максимум какой-нить индекс, и возможность быстрого доступа к элементам индекса. Если у нас есть скажем винт на 1Тб, и каждая картинка порядка 1Мб - это всего-то около миллиона картинок, простой поиск по файлу вида "category:path" из миллиона строк сильно тормозным не будет, хождение по симлинкам - тоже(хотя лучше все-таки не скидывать все в одну директорию), ну или в sqite какой-нить индекс засунуть - тоже не страшно.

Не изобретайте велосипеда. Берите любую нормальную RDBMS (DB2/Oracle/Postgres...) создавайте структуру, и складывайте туда свои файлы.

Какой-то сильный overhead для такой задачи.

[serzh-z]

Не изобретайте велосипеда. Берите любую нормальную RDBMS (DB2/Oracle/Postgres...) создавайте структуру, и складывайте туда свои файлы.

Если честно, то я уже рыдаю...

Кстати говоря, о забивании гвоздей микроскопом - всё что я хотел - это *как раз наоборот* уйти от всех этих каталогизаторов, типа F-Spot, Picasa, gThumb (вынуждающими постоянно терять инфу о альбомах и тегах), с собственными базами, хранящимися отдельно. ;)

[serzh-z]

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

Каталог links с с симлинками (people, by-years, events, etc) как раз и будет заменять индекс.

просто, автор топика сам не знает, то что он хочет...

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

ФС - это более универсальное средство хранения, а симлинки - более простой способ теггирования файлов.

[gcc]

хорошо, а в чем тогда вопрос? что не получается?

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

например:
Для чего все это ???
Зачем такой объем ? какой он сейчас и какой он будет?
Какой тип нагрузки ?
Время простоя какое допустимо ?
Вам нужно чтобы эти 1-100Tb были видны одним куском ?
Ну и как быть с будущим бэкапом и репликацией такого объема ?

Без ответа на вопросы, ваши все ФС и прочая ерунда в
определенных ситуациях навернется медным тазом .

[diesel]

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

Каталог links с с симлинками (people, by-years, events, etc) как раз и будет заменять индекс.

Да я понял. А почему бы кстати не совместить часть "индекса" и реальные фотки. Ну то есть раскладку реальных картинок ведь можно сделать в духе year->month->day->photo. Симлинкать тебе по-большому счету ведь все-равно что и откуда, а так и одна разбивка будет иметь место быть(то есть не все будет в одной папке складываться), и другие на ее основе легко построить как симлинки.

[Portnov]

Мне другое интересно. А по какому принципу собираетесь создавать линки? Что-то типа тегов сделать? А сложные запросы (has tag A and has not tag B) как поддерживать?

[serzh-z]

Ну то есть раскладку реальных картинок ведь можно сделать в духе year->month->day->photo

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

А по какому принципу собираетесь создавать линки? Что-то типа тегов сделать? А сложные запросы (has tag A and has not tag B) как поддерживать?

По принципу "решил, что вот это, это и вот это фото надо пометить тегом spring". Нафига мне сложные запросы?.. Я лишь хочу зайти ФС-браузером в links/spring и увидеть то, что там есть. У меня сложилось впечатление, что первый пост никто не читал принципиально и всех просто смутило название темы.

[serzh-z]

Хм... Хотя, мысль делать поиск по нескольких тегам - полезна. Вероятно, с помощью find можно сделать подобный запрос.

[drBatty]

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

почему? скорее - НЕ надо.

Об этом думал. Полагаю, что Ext4 вполне справится с каталогом.

не справится - сделайте раздел с бОльшим количеством инодов.

Есть где-нибудь обоснованное описание подобного подхода?

нет и быть не может. подход принципиально неверен: если у вас каталог с файлами такого вида, то ОС САМА так делает (считает хеш и выстраивает многоуровневое дерево) наварачивая одну структуру поверх такой-же вы делаете полную ерунду. Используя EXT3/4 вы можете также менять тип используемого хеша.

У ext3/4 есть ограничение на количество файлов в директории! Не стоит забывать об этом.

кто вам это сказал?

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

угу. а теперь сравните работу каталога с 1000000 файлами с работой каталога с 1000 подкаталогами в каждом из которых 1000 файлов.

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

как O(log(N))
при вашем подходе, как O(sqrt(N))
учите матчасть...

[/dev/random]

угу. а теперь сравните работу каталога с 1000000 файлами с работой каталога с 1000 подкаталогами в каждом из которых 1000 файлов.

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

как O(log(N))
при вашем подходе, как O(sqrt(N))
учите матчасть...

На практике обычно делают небольшую "перестраховку" на случай захода в этот каталог графическим ФМ, попадания БД на FAT32 и тому подобных форсмажоров. Выглядит это так: каталог не один, а некоторая _константа_ (обычно от 16 до 256), между которыми файлы распределяются примерно равномерно. Выбор одного из каталогов занимает константу времени, поэтому на бесконечности имеем всё то же O(log(N)), зато при реалистичных значениях N мы более-менее защищены от форсмажоров.

[drBatty]

На практике обычно делают небольшую "перестраховку" на случай захода в этот каталог графическим ФМ, попадания БД на FAT32 и тому подобных форсмажоров.

не думаю, что это как-то спасёт - что 1000000 файлов, что 100000, в любом случае форсмажор ;)

Выглядит это так: каталог не один, а некоторая _константа_ (обычно от 16 до 256), между которыми файлы распределяются примерно равномерно.

я так делал, когда мне понадобилось упаковать эти файлы. если доступ внутрь каталога очень быстр в любом случае, то доступ к архиву конечно в 256 раз быстрее, если архивов 256. Я свернул имя файла по md5, и переименовал все файлы. Архивы были 00.txz, 01.txz и т.д..
но делать такое с каталогами имхо нет смысла. Вообще, как я понял, обычно путь считается именем. Т.е. мы имеем не 1000 "папок" с 1000ю файлами в каждой, а миллион файлов с именами вида
356/945.txt. Ну да, страшновато смотреть на каталог размером не 4096 байт как обычно, а скажем 349234300 байт. Ну и что? Это как раз БД и есть - для каждого имени вычисляется хеш, и эти хеши организовываются в дерево, именно так, как тут и предлагают.

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

используя опцию -O можно

dir_index
Use hashed b-trees to speed up lookups in large directories.

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

В итоге, это оптимальная схема, если конечно удастся свести требуемую задачу к БД с одним ключом типа "строка" размером 0...255 байт.

Ну а если нужно просмотреть скажем фотки в GUI, то можно сделать выборку, и сделать хардлинки от этой выборки, потому как лезть в такую "БД" через GUI конечно невозможно. Да и в консоли есть тонкости - например grep "" * сначала очень долго тормозит, обрабатывая * - надо составить отсортированный список файлов. Потому приходится писать find . -exec grep "" {} /dev/null \; потому-что find не сортирует файлы. Кроме того, размер командной строки ограничен, причём при переполнении никаких предупреждений не выдаётся, просто часть файлов молча теряется.

[Crazy]

Код: Выделить всё

db/
  all/
    1
    2
    3
    9

  links/
    foo/
      1 -> ../../all/1
      9 -> ../../all/9

    bar/
      1 -> ../../all/1
      2 -> ../../all/2
      3 -> ../../all/3

Не понимаю, чем это лучше обычного размещения?

Код: Выделить всё

root/
     music
     video
     images

[serzh-z]

Не понимаю, чем это лучше обычного размещения?

Наличием у файла множественных "тегов".

[drBatty]

Не понимаю, чем это лучше обычного размещения?

фотки/1.jpg
2.jpg
3.jpg

Маша/
1->../2.jpj
2009й_год/
1->../1.jpg
2->../2.jpg

наверное это...

[gcc]

еще не давно в голову пришло не большое дополнение:

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

когда я хочу получить файл, то будет функцию:
sysread $start , $end c этого файлика...

Syntax

sysread FILEHANDLE, SCALAR, LENGTH, OFFSET

sysread FILEHANDLE, SCALAR, LENGTH

Definition and Usage

Tries to read LENGTH bytes from FILEHANDLE, placing the result in SCALAR. If OFFSET is specified, then data is written to SCALAR from OFFSET bytes, effectively appending the information from a specific point. If OFFSET is negative, it starts from the number of bytes specified counted backward from the end of the string. This is the equivalent of the C/operating system function read( ). Because it bypasses the buffering system employed by functions like print, read, and seek, it should only be used with the corresponding syswrite and sysseek functions.

($start , $end получаем с базы или СУБД как угодно)

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

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

ЗЫ: сейчас есть сайт в котором картинки хранятся в MySQL и отдаются с apache (картинки маленькие до 70-100kb, возможно, такое хранение оправданное)

как такая идея с cache картинок?

[drBatty]

как такая идея с cache картинок?

мне кажется быстрее будет просто показать картинку.

[serzh-z]

как такая идея с cache картинок?

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

[drBatty]

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

что-бы держать открытый огромный файл. причём я не думаю, что он эффективно закешируется. А даже если и закешируется, то информация о популярности будет устаревшей. К тому-же, это надо
1) запрос к БД
2) обработать запрос БД
3) получить $begin, $end
4) прочитать картинку в память

прямой поиск файлов будет явно эффективнее. даже и проверять не стану.

[gcc]

как такая идея с cache картинок?

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

с точки зрения оптимизации

прямой поиск файлов будет явно эффективнее. даже и проверять не стану.

в ядре есть опции:

Код: Выделить всё

kern.maxfiles: 10000
kern.maxfilesperproc: 11095
kern.openfiles: 1284
kern.filedelay: 30

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

[RasenHerz]

с точки зрения оптимизации

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

[zombie]

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

Мне рассказали про одну такую полезную вещь, как формилизованный массив:

Код: Выделить всё

$str = serialize($array); //превращаем массив в строку

Код: Выделить всё

$array = unserialize($str); //превращаем строку в массив

Это раз. Может пригодиться.

Два:
БД на ФС - вещь для конкретного случая и любое решение оптимально совсем далеко не всегда. На самом деле как и БД в принципе.

А может применять просто случайную нумерацию для создания "корзин" (01, 02, 03, 99) и при переполнении одной из "корзины", создавать следующую и складывать файлы туда?

Вот я почти так последний раз и делал... Только для файлов, а не для папок, не по себе мне, когда много маленьких^{(ну вот тут опять, конкретный случай)} файлов. И вообще когда много файлов или папок.


p/s
Сказал, наверно, бред, но все что по поводу в голову пришло...

[serzh-z]

как формилизованный массив:

Сериализованный.

[drBatty]

в ядре есть опции:
Код
kern.maxfiles: 10000

дык это видимо одновременно открытые файлы. причём тут они?

Сериализованный.

именно!

БД на ФС - вещь для конкретного случая и любое решение оптимально совсем далеко не всегда. На самом деле как и БД в принципе.

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

[landgraf]

/me все мечтает прикрутить вот это: Эффективное хранение двоичных данных больших объёмов, напр., фото и видео ибо тоже бардак

[xorader]

Почему никто не предложил радикальное решение "проблемы" ? (rm -rf *) )