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

Модератор: Модераторы разделов

Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu

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

Сообщение serzh-z »

Есть мысль хранить большое количество файлов в подобной структуре:

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

db/
  all/
    1
    2
    3
    9

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

    bar/
      1 -> ../../all/1
      2 -> ../../all/2
      3 -> ../../all/3
Поскольку количество файлов в all может быть очень велико, то явно следует разбить его на подкаталоги. Вопрос стоит в следующем: какую структуру выбрать для содержимого all? Структура и содержимое all, в принципе, для пользователя (т.е. меня) не важна. Он работает только с {foo, bar, ...} в links.

Есть мысль применять подход, аналогичный каталогизации ccache. Или же создавать в all структуру, в которой имена каталогов будут привязаны к дате импорта файла в all (т.е. all/2010/02/10, all/2009/01/01, ...). А может применять просто случайную нумерацию для создания "корзин" (01, 02, 03, 99) и при переполнении одной из "корзины", создавать следующую и складывать файлы туда?

Т.е. интересуют существующие обоснованные подходы к созданию некого подобия БД на ФС.
Спасибо сказали:
apprentice
Сообщения: 595
ОС: Debian 6

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

Сообщение apprentice »


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

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

Спасибо сказали:
azsx
Сообщения: 3684
ОС: calculate linux, debian, ubuntu

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

Сообщение azsx »

еще бы заметил про ограничение inode
df -i
Спасибо сказали:
Аватара пользователя
rm_
Сообщения: 3340
Статус: It's the GNU Age
ОС: Debian

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

Сообщение rm_ »

Если файлы меняться не будут, можно делать sha1-сумму содержимого, и складывать:

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

$ sha1sum phones.odt
68bd644b8d63c19461afe2bdfe6d0ff70baa9536  phones.odt

в

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

all/6/8/b/d/68bd644b8d63c19461afe2bdfe6d0ff70baa9536

количество уровней по вкусу. Таким образом получаем практически идеально-равномерное распределение файлов по каталогам.
Если меняться всё же будут, то можно считать сумму от чего-нибудь другого, например от имени+даты+времени.
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu

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

Сообщение serzh-z »

azsx писал(а):
25.10.2010 13:46
еще бы заметил про ограничение inode
Об этом думал. Полагаю, что Ext4 вполне справится с каталогом.

apprentice писал(а):
25.10.2010 13:40
Будет ли это доступ по имени (т.е. для доступа к фалу нужно будет знать полный путь к нему), либо вам нужно организовать поиск фала по названию, содержанию дате и т.п.
Поиск предполагается по ссылкам в links.
rm_ писал(а):
25.10.2010 13:59
all/6/8/b/d/68bd644b8d63c19461afe2bdfe6d0ff70baa9536
Ага, кажется, нечто подобное используется в Git и в ccache. А почему выбраны лишь первые два байта хеша в качестве каталога?

rm_ писал(а):
25.10.2010 13:59
Таким образом получаем практически идеально-равномерное распределение файлов по каталогам.
Есть где-нибудь обоснованное описание подобного подхода?
Спасибо сказали:
BIgAndy
Сообщения: 1923

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

Сообщение BIgAndy »

serzh-z писал(а):
25.10.2010 13:33
Есть мысль хранить большое количество файлов в подобной структуре:

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

db/
  all/
    1
    2
    3
    9

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

    bar/
      1 -> ../../all/1
      2 -> ../../all/2
      3 -> ../../all/3
Поскольку количество файлов в all может быть очень велико, то явно следует разбить его на подкаталоги. Вопрос стоит в следующем: какую структуру выбрать для содержимого all? Структура и содержимое all, в принципе, для пользователя не важна. Он работает {foo, bar, ...} в links.

Есть мысль применять подход, аналогичный каталогизации ccache. Или же создавать в all структуру, в которой имена каталогов будут привязаны к дате импорта файла в all (т.е. all/2010/02/10, all/2009/01/01, ...). А может применять просто случайную нумерацию для создания "корзин" (01, 02, 03, 99) и при переполнении одной из "корзины", создавать следующую и складывать файлы туда?

Т.е. интересуют существующие обоснованные подходы к созданию некого подобия БД на ФС.

Идея, как бы это сказать, не то что не нова, а с бородой.
Прародитель DB2 (а именно os/2 ee) так и делал.
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu

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

Сообщение serzh-z »

BIgAndy писал(а):
25.10.2010 14:23
Идея, как бы это сказать, не то что не нова, а с бородой.
Да мне пофиг - нова она или нет. Меня не устраивают существующие каталогизаторы фотографий и есть необходимость сделать свои скрипты, использующие ФС.
Спасибо сказали:
Аватара пользователя
guglez
Сообщения: 394
ОС: GNU/Linux

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

Сообщение guglez »

У ext3/4 есть ограничение на количество файлов в директории! Не стоит забывать об этом.
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu

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

Сообщение serzh-z »

guglez писал(а):
25.10.2010 14:40
У ext3/4 есть ограничение на количество файлов в директории! Не стоит забывать об этом.
Вот. Именно. Потому. Я. И. Спросил. Про структуру каталога all. Возможно, что где-то уже есть чьи-то труды с размышлениями о эффективности той или иной структуры.
Спасибо сказали:
BIgAndy
Сообщения: 1923

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

Сообщение BIgAndy »

serzh-z писал(а):
25.10.2010 14:27
BIgAndy писал(а):
25.10.2010 14:23
Идея, как бы это сказать, не то что не нова, а с бородой.
Да мне пофиг - нова она или нет.

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

Обзор можно почитать можно в первых номерах (по-моему, начиная с пятого) журнала Системы Управления Базами данных (сейчас часть "открытых систем"), также теоретическая часть была хорошо изложена в журнале "Алгоритмы и программы" за 1979 (!) год.
Спасибо сказали:
Аватара пользователя
rm_
Сообщения: 3340
Статус: It's the GNU Age
ОС: Debian

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

Сообщение rm_ »

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

Нипочему, я же написал, "количество уровней по вкусу", можно не два, а больше - хоть половину, или все. :)
Ведь конечная цель всего этого раскладывания по дереву - это чтоб в каждом из листьевых каталогов было "не слишком много" файлов.
Т.е. хотя современные ФС и шиты чем-то чуть более крепким чем лыко, каталог с миллионом файлов в нём - не самое оптимальное решение.
Спасибо сказали:
JwsD
Сообщения: 129
ОС: ArchLinux

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

Сообщение JwsD »

serzh-z писал(а):
25.10.2010 14:43
guglez писал(а):
25.10.2010 14:40
У ext3/4 есть ограничение на количество файлов в директории! Не стоит забывать об этом.
Вот. Именно. Потому. Я. И. Спросил. Про структуру каталога all. Возможно, что где-то уже есть чьи-то труды с размышлениями о эффективности той или иной структуры.

Пихай все в all. без разбивки. Просто для нее используй ReiserFS. в ней нет ограниений на иноды, и воркает очень быстро
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu

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

Сообщение serzh-z »

JwsD писал(а):
25.10.2010 15:54
Пихай все в all. без разбивки. Просто для нее используй ReiserFS. в ней нет ограниений на иноды, и воркает очень быстро
Привязка хранилища к какой-то определённой ФС - плохой тон.
Спасибо сказали:
JwsD
Сообщения: 129
ОС: ArchLinux

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

Сообщение JwsD »

serzh-z писал(а):
25.10.2010 16:15
JwsD писал(а):
25.10.2010 15:54
Пихай все в all. без разбивки. Просто для нее используй ReiserFS. в ней нет ограниений на иноды, и воркает очень быстро
Привязка хранилища к какой-то определённой ФС - плохой тон.

Почему же? У меня одна здоровая папка с фотками, гдето 4к фоток, все в одной папке. Открывается моментально
Спасибо сказали:
Аватара пользователя
Davinel
Сообщения: 481
ОС: Ubuntu

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

Сообщение Davinel »

Насколько я помню было ограничение на количество папок. Конкретно в ext4 - 64 тысячи. Вроде бы количество файлов ограничено только инодами, нет? Хотя скорость доступа при большом количестве файлов будет заметно падать, это да.

Ну вот в сквиде например используется до крайности примитивная схема разбивки.
Он создает сколько то папок(00, 01, ..., FF) сколько именно - настраиваемо, и в каждой из них по, кажется, 256 подпапок. И потом равномерно размазывает файлы по всем папкам. Если логика размещения файлов не важна - то можно такой подход использовать.
Спасибо сказали:
azsx
Сообщения: 3684
ОС: calculate linux, debian, ubuntu

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

Сообщение azsx »

да создать скриптом миллионов 5 текстовых файлов килобайт по 300, а потом попробовать попроводить с ними операции чтения, записи и т.п. И все для себя решить...
зы
у меня сайт слитый. там тысяч 100-300 файлов. В мс если в папку заходил - то тормоза конкретные были. Но по ssh
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu

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

Сообщение serzh-z »

Пришёл к выводу, что надо курить исходники squid и ccache, возможно, что там есть ссылки на описания алгоритмов, аналогичных Файловая система в качестве базы данных или сквидовому.

Есть же метод waterfall, ещё какие-то.
Спасибо сказали:
Аватара пользователя
Crazy
Сообщения: 862
Статус: Адепт Дзен.
ОС: Mint, Win7.

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

Сообщение Crazy »

Немного не в тему
http://meta.montclair.edu/grid/grid_linux2.png

Desipere in loco
Спасибо сказали:
Аватара пользователя
SLEDopit
Модератор
Сообщения: 4824
Статус: фанат консоли (=
ОС: GNU/Debian, RHEL

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

Сообщение SLEDopit »

serzh-z писал(а):
25.10.2010 16:15
Привязка хранилища к какой-то определённой ФС - плохой тон.
Какой у вас радикальный подход. По-моему, не мне вам рассказывать, что ФС между собой достаточно сильно различаются. Поэтому, имхо, использование reiser выглядит вполне логичным в данной ситуации.
UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity. © Dennis Ritchie
The more you believe you don't do mistakes, the more bugs are in your code.
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu

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

Сообщение serzh-z »

SLEDopit писал(а):
25.10.2010 21:56
Какой у вас радикальный подход. По-моему, не мне вам рассказывать, что ФС между собой достаточно сильно различаются. Поэтому, имхо, использование reiser выглядит вполне логичным в данной ситуации.
Сейчас возьму, нафиг, переформатирую свои винты в ReiserFS, из-за одного лишь каталогизатора. Или буду заниматься выносом каталога на отдельный раздел. Разве не это ли радикальный подход?

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

Не катит, ибо хочу от этого зоопарка уйти.
Спасибо сказали:
Serik
Сообщения: 149
ОС: SuSE Linux

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

Сообщение Serik »

У меня при попадании файла в информационную систему ему присваивается идентификатор aaabbbccc.
Записывается файл в $(FDB)/aaa/bbb/ccc/aaabbbccc.
Исследованием и разбором методик создания и наполнения подкаталогов/"корзин" не заморачивался.
Идентификатор перевалил за 100k, файлов более 60k.
Спасибо сказали:
test157
Сообщения: 124
ОС: Debian Lenny

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

Сообщение test157 »

guglez писал(а):
25.10.2010 14:40
У ext3/4 есть ограничение на количество файлов в директории! Не стоит забывать об этом.

у ext3 и ext2 файловой системы это ограничение всего лишь 32 тысячи файлов/папок.
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

test157 писал(а):
26.10.2010 18:27
у ext3 и ext2 файловой системы это ограничение всего лишь 32 тысячи файлов/папок.
У ext3 нет ограничения на число файлов в каталоге. Подозреваю, что у ext2 тоже. Есть ограничение на число подкаталогов, которое связано с ограничением на число ссылок, ибо каждый подкаталог добавляет одну ссылку. А файлов можно хоть миллион положить.

Кстати, помнится, несколько лет назад я что-то читал о причинах организации кэша squid в виде двух уровней подкаталогов. Связано это было с тем, что тогдашние ФС осуществляли поиск в каталоге линейно, что при большом числе entries — полный ахтунг. В нынешних ФС используются всякие B-tree/H-tree, поэтому вся эта свистопляска, думаю, неактуальна — можно тупо свалить всё в один каталог (я проверил у себя, 2e6 файлов каталог держит легко).

Щас вот, вечерком, доколбашу маленький бенчмарк для сравнения разных стратегий, к ночи, думаю, оно добенчмаркает, можно будет взглянуть на результаты.
Спасибо сказали:
Аватара пользователя
gcc
Сообщения: 526
ОС: FreeBSD 8.0 CURRENT

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

Сообщение gcc »

serzh-z, это обсуждали давно, уже, много раз...

то что я нашел:

если тебе еще нужно все картикни отдать сразу, то ядро не выдержит большое количество открытых файлов, кроме ФС...
на счет фс: есть ZFC на FreeBSD самая лучшая

есть решение: MogileFS c репликацией Master -> Slave
и отадача через nginx, как статику...

MogileFS - open source distributed filesystem

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

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

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

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


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



еще, PostgreSQL,MSSQl, Oracle умеют хранить файлы
в MSSQl, Oracle даже есть тип данных для стримминга:

в документации в PostgreSQL написано, что она может хранить фотографии, музыку и видео
Example: Streaming character data from the database

In this example, we demonstrate a technique for streaming data from the database to a file handle, in this case STDOUT. This allows more data to be read in and written out than could be stored in memory at a given time.


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

my $lob_id = 17; # Arbitrary row identifier, for example

$sth = $dbh->prepare( <<" SQL", { ora_auto_lob => 0 } );
SELECT chardata
FROM lob_example
WHERE lob_id = ?
SQL
$sth->execute( $lob_id );
my ( $char_locator ) = $sth->fetchrow_array();

my $chunk_size = 1034; # Arbitrary chunk size, for example
my $offset = 1; # Offsets start at 1, not 0
while(1) {
my $data = $dbh->ora_lob_read( $char_locator, $offset, $chunk_size );
last unless length $data;
print STDOUT $data;
$offset += $chunk_size;
}


Notice that the select statement does not contain the phrase "FOR UPDATE". Because we are only reading from the LOB Locator returned, and not modifying the LOB it refers to, the select statement does not require the "FOR UPDATE" clause.

A word of catution when using the data retruned from an ora_lob_read in a condtional statement. for example if the code below;


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

while( my $data = $dbh->ora_lob_read( $char_locator, $offset, $chunk_size ) ) {
print STDOUT $data;
$offset += $chunk_size;
}


was used with a chunk size of 4096 against a blob that requires more than 1 chunk to return the data and the last chunk is one byte long and contains a zero (ASCII 48) you will miss this last byte as $data will contain 0 which PERL will see as false and not print it out.


http://search.cpan.org/~pythian/DBD-Oracle...om_the_database


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

только для отдачи по httpd, нужно будет писать модуль к nginx

есть seek:

lo_lseek

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

$loc = $dbh->pg_lo_lseek($lobj_fd, $offset, $whence);

Changes the current read or write location on the large object $obj_id. Currently $whence can only be 0 (which is L_SET). Returns the current

location and undef upon failure. This function cannot be used if AutoCommit is enabled.


к MySQL есть какое-то дополнение:
http://blobstreaming.org/
Спасибо сказали:
Аватара пользователя
gcc
Сообщения: 526
ОС: FreeBSD 8.0 CURRENT

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

Сообщение gcc »

watashiwa_daredeska писал(а):
26.10.2010 19:39
test157 писал(а):
26.10.2010 18:27
у ext3 и ext2 файловой системы это ограничение всего лишь 32 тысячи файлов/папок.
У ext3 нет ограничения на число файлов в каталоге. Подозреваю, что у ext2 тоже.


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

ну и если будет в каталоге 100млн файлов, или даже более 800млн файлов? это не каждая СУБД с легкостью сможет обработать такое большое число данных...
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

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

gcc писал(а):
26.10.2010 20:19
это не каждая СУБД с легкостью сможет обработать такое большое число данных...
Да-да-да. Я вообще рекомендую для домашней коллекции фоток использовать сразу кластер, GFS и MapReduce для обработки. Кластер — обязательно в стойках должен стоять, для лёгкого наращивания мощностей. Ещё не забыть UPS, который может держать всю эту фигню полчаса, плюс дизель-генератор на балконе. Где держать бочку с солярой — надо ещё подумать, ибо по соображениям пож. безопасности дома нельзя. А чтобы друзья всегда могли посмотреть ваши фотки, не забудьте минимум 3 интернет канала проложить. Климат-контроль (с резервированием, естественно) и фильтрация воздуха — даже не обсуждаются.

Ведь домашняя коллекция фоток того стоит! :)

serzh-z писал(а):
25.10.2010 16:15
Привязка хранилища к какой-то определённой ФС - плохой тон.
Насколько я помню, у того же squid есть несколько стратегий хранения своего кэша. Под разные условия — объемы, ФС и т.п.

Так что, фиксирование стратегии хранения — в общем случае не айс, а вот иметь возможность выбрать из нескольких — вполне даже разумное решение.
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu

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

Сообщение serzh-z »

watashiwa_darede... писал(а):
26.10.2010 20:34
Да-да-да. Я вообще рекомендую для домашней коллекции фоток использовать сразу кластер, GFS и MapReduce для обработки. Кластер — обязательно в стойках должен стоять, для лёгкого наращивания мощностей. Ещё не забыть UPS, который может держать всю эту фигню полчаса, плюс дизель-генератор на балконе. Где держать бочку с солярой — надо ещё подумать, ибо по соображениям пож. безопасности дома нельзя. А чтобы друзья всегда могли посмотреть ваши фотки, не забудьте минимум 3 интернет канала проложить. Климат-контроль (с резервированием, естественно) и фильтрация воздуха — даже не обсуждаются.
=)))) Аццки жжёшь. Именно к этой мысли я постоянно и прихожу читая посты в этой теме... Чесслово, как в той теме про "Вкручивание лампочки на линуксфоруме".

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

Пару лет назад впервые столкнулся с *необходимостью* разбиения отпускных фотографий с двух камер на категории именно из-за ужаснейших тормозов (в то время, кажется, ещё был ext3) при перечислении содержимого каталога в Nautilus.
Спасибо сказали:
Аватара пользователя
gcc
Сообщения: 526
ОС: FreeBSD 8.0 CURRENT

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

Сообщение gcc »

Чукча не читатель, чукча писатель :)
Спасибо сказали:
watashiwa_daredeska
Бывший модератор
Сообщения: 4038
Статус: Искусственный интеллект (pre-alpha)
ОС: Debian GNU/Linux

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

Сообщение watashiwa_daredeska »

serzh-z писал(а):
26.10.2010 20:43
из-за ужаснейших тормозов (в то время, кажется, ещё был ext3) при перечислении содержимого каталога в Nautilus.
Ну при перечислении 2e6 файлов Nautilus будет тормозить, думаю, на любой ФС. Всякая графическая дребедень (и даже, подозреваю, псевдографическая, вроде mc) не годится для такого, ибо пытаются сделать много лишнего. А когда это лишнее помножено на 2e6, то получается РЕАЛЬНО МНОГО. Так что, только shell. А Nautilus'ом и прочими mc можно бегать по тем каталогам с симлинками.
Спасибо сказали:
BIgAndy
Сообщения: 1923

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

Сообщение BIgAndy »

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

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

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

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