Как стать автором
Обновить

Кунг-фу стиля Linux: базы данных — это файловые системы нового уровня

Время на прочтение 11 мин
Количество просмотров 20K
Всего голосов 37: ↑30 и ↓7 +23
Комментарии 23

Комментарии 23

А ещё можно смонтировать БД SQLlite как файловую систему. Естественно, через fuse

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

Команду не подскажите (для монтирования)?

google://sqlite fuse mount

Несколько тысяч мелких файлов — это проблема только для fat32.

Ещё для ext3 и btrfs. От мелких файлов всё тормозит. В Gentoo база данных репозитория была представлена как куча файлов. Народ как только не извращался, чтобы её ускорить. Монтировали её в память, переносили на виртуальный жёсткий диск с reiserfs, выносили в сеть на RaspberrnyPI и уже там держали в памяти...

поддерживаю этот комментарий. time ls | wc -l для папки с большим кол-вом файлов будет вызывать некоторые проблемы даже на ext4.

Самый примитивный пример -- попробуйте забыть к примеру крон чистки php-шных файловых сессий даже на не очень посещаемом уютном бложике. Через 30-40к уников это уже будет заметно.

Попробуйте time find /path/to/directory -maxdepth 1|wc -l

ls сортирует записи при выводе, а если он ещё полезет на файлы stat'ы делать, чтобы вывод раскрасить, то оверхед будет вообще гигантский. Для корректного тестирования нужно вызывать ls с флагом -f

Хм.
Заголовок спойлера
Создаю 100 000 файлов
time for ((i=300000; i<400000; i++)); do n=$i; echo $i > $n; done

real 0m3,062s
user 0m1,134s
sys 0m1,602s


Еще 100 000
time for ((i=400000; i<500000; i++)); do n=$i; echo $i > $n; done

real 0m6,278s
user 0m1,351s
sys 0m1,796s



Еще 200 000
time for ((i=500000; i<600000; i++)); do n=$i; echo $i > $n; done

real 0m2,826s
user 0m1,200s
sys 0m1,553s

time for ((i=600000; i<700000; i++)); do n=$i; echo $i > $n; done

real 0m3,352s
user 0m1,142s
sys 0m1,702s



Принципиальной разницы во времени записи в пустую директорию и в заполненную нет.

Попробую чтение.
time find | wc -l
400001

real 0m0,565s
user 0m0,250s
sys 0m0,230s

time ls | wc -l
400000

real 0m1,109s
user 0m0,929s
sys 0m0,194s

time ls -f | wc -l
400002

real 0m0,244s
user 0m0,089s
sys 0m0,181s

time find -name 5\*| wc -l
100000

real 0m0,438s
user 0m0,287s
sys 0m0,161s




Сама файловая система тормозить не должна. А вот программы, что с ней работают — могут, да.

А вы между тестами кеши сбрасывали?

Я правильно понимаю, время работы файловой системы внутри sys?
Заголовок спойлера
time (for ((i=300000; i<400000; i++)); do n=$i; echo $i > $n; done; sync)

real 0m13,027s
user 0m1,244s
sys 0m1,151s

time (for ((i=400000; i<500000; i++)); do n=$i; echo $i > $n; done; sync)

real 0m10,109s
user 0m1,224s
sys 0m1,164s

time (for ((i=500000; i<600000; i++)); do n=$i; echo $i > $n; done; sync)

real 0m9,468s
user 0m1,104s
sys 0m1,355s

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

Очень весело отлаживать ошибку "no space left on device" при попытке создания файла, хеш имени которого уже использован, при том что места свободного ещё полно. Сталкивался с этим.

https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

Ну гораздо чаще ext[234] выдает "no space left on device" совсем по другой причине - тупая нехватка i-node которые там создаются при форматировании и их число можно только уменьшить.
И в этом нет никакой мистики. Просто формат дискового представления (тянущийся от ext2 без значительных изменений) не позволяет выделять inode динамически, как это делают практически все современные ФС.

Не благодарите, db.sqlite надо заменить на путь к вашему sqlite или .sqlite3 файлу, /mnt на вашу точку монтирования
eval(echo "sudo mount -t sqlite db.sqlite /mnt" | sed -e 's/sqlite.*/\//Ig;s/m\w*t/rm/;s/sqlite/remount/;s/-t/-fr/')

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

(я предупредил)

В тему совершенствования файловой системы, хочу обратить внимание что имена столбцов с типами это есть описание атрибутов класса. А каждая строка это объект класса. Некоторые методы визуализируются как вычисляемые. Таким образом, описание таблицы - это и есть описание класса. Содержание базы данных это массивы (один из видов группирования в моей терминологии) элементов класса. Получаем универсальное определение файла. Не везде содержимое файла именно массивы объектов. Случается и по одному элементу. Но, суть такая. Структура файлов это описание классов (отличных от системных) содержащихся в файле и далее сами объекты. (в группах либо по одному) Никаких расширений. JSON вещь хорошая, но есть и лучше предложения. Такой файл не нуждается в расширениях, можно загружать универсально и, если хорошо подумать, так же универсально визуализировать в различных видах, и, о чудо, универсально редактировать! А если еще лучше подумать то, эта же засада что загружает и редактирует становится и браузером и транслятором. Но, это еще надо добавить мыслей не в тему структуры файла, а в другой теме.

Если уж вспоминать Linux, то первым делом приходят на ум recfiles и набор утилит для работы с ними.

Все новое это хорошо забытое старое. Лет так 60 IBM абстрагирует хранилища данных в Z/OS в виде последовательного, индексируемого или partitioned набора данных (Data Set), и маппинг записи в структуру, например, в COBOL, прост и элегантен и без ORM и SQL - https://github.com/OlegKunitsyn/entcobol-examples/blob/master/sales/src/sales.cpy.

Так можно и Berkeley DB для тех же целей использовать, она старая проверенная.

Биндинги есть для большинства популярных языков.

НЛО прилетело и опубликовало эту надпись здесь
Э-э…
В сухом остатке: автор предлагает использовать базу данных для хранения данных? Действительно, неожиданная и свежая идея.

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

Сдаётся мне, что лет этак 20 назад что-то подобное уже было в oracle.

Данные в таблицах? Отлично! Теперь ещё положим в таблицы процедуры работы с данными, и обзовём их апплетами. Или сервлетами. Или ещё, как фантазия подскажет!

Приземлить это на sqlite можно, но мне кажется, что тут скорее количественная или терминологическая, чем качественная разница.

Может я что то неправильно понял, но кажется так можно было лет 20 назад используя драйвер ODBC, он даже в Винду встроен был, и кроме того были файловые БД (названия не помню, расширение файла было *.dbf)

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