LINUX.ORG.RU

И все же, как хранить миллионы мелких файлов?

 


0

1

93Гб, 5,45М файлов, 127к каталогов

Оно ни то что на ссд (с их проблемой работы с мелочью) оно даже с винта на винт копируется 5 часов.

Паковать в tar - еще хуже, чем копировать между ссд. Безумно медленно. Тар не годится для этого.

В какой бы контейнер укладывать это? Пока tar'ю подкаталоги, но и это тоже тормозной изврат.

\что за хрень? копия сайта с размещенными турами.

Перемещено leave из talks

Перемещено leave из desktop


что за хрень? копия сайта с размещенными турами.

сессии таришь =)

int13h ★★★★★
()

а так да, лучше снапшотом их, снапшотом

int13h ★★★★★
()
Ответ на: комментарий от hateyoufeel

Твоюжматьменяажпередернуло.

Зачем ты так с нами?

Stil ★★★★★
()

Каталогизация @ сквашфс.

iu0v1
()

Можно попробовать (не обещаю успех!)

1) Установить Oracle Database, хранить данные оракла на raw разделах диска, файлы хранить в blob полях таблицы.

2) Для работы с файлами таким образом написать специальную прогу с веб-интерфейсом (например, на Java). (Вместо написания своей софтины попробовать заюзать нечто вроде Alfresco, но боюсь что оптимизация у Альфрески на объемах в 6M мелочи - «не, не слышал»).

Далее полученную вундервафлю выставить в интернет по белому ip, и вообще ничего никуда не копировать, а обращаться к файлам просто через веб-интерфейс

4) Если веб-интерфейс не канает, и нужно именно физическое наличие на диске - написать небольшую прогу-переливалку (из БД на целевой диск).

Еще можно попробовать посмотреть, с какой скоростью на таких данных отрабатывает master-slave репликация самого Оракла (и дальше копировать данные через нее) или встроенный в БД бэкап.

5) И конечно везде надо замерять перфоманс и делать выводы.

stevejobs ★★★★☆
()

что за хрень? копия сайта с размещенными турами

блин, не дочитал до конца, пропустил эту строчку :( ну тут сам бох велел попробовать хранить всё не на диске, а в базке, и бэкапиться встроенным бэкапом (или если это нужно для распределения нагрузки - встроенное репликацией). Только базка должна быть не sqlite и вероятно не mysql, а хотя бы postgres, лучше oracle (если рука поднимется её пиратить).

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 2)

Тема про «хранить», а нытье про «медленно копируется». WTF? Мелочь ты все равно быстро не скопируешь, тут в иопсы все упирается, т.е. если ты на _постоянной_ основе переносишь файлы, то тебя спасет только громоболт с внешним ssd. Ну и рабочую копию тоже только на ssd. А чтобы спать спокойно, бекапы делать через dd.

Lordwind ★★★★★
()

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

P.S: Вроде бы KRoN73 проводил какие-то исследования на эту тему пару лет назад.

shrub ★★★★★
()

лалка, ты кроме толксов больше разделов не знаешь?

smilessss ★★★★★
()
Ответ на: комментарий от t184256

Скорее всего минусов никаких и нет, надо будет бенчмарки погонять.

xtraeft ★★☆☆
()
Ответ на: комментарий от shrub

Именно исследований не проводил, адекватные тесты разработать всё ломает. Но по факту, если есть структура кешей с большим количеством файлов (от сотен тысяч и выше) и относительно высокой вложенностью (глубиной в 2-4 подкаталога) и надо это барахло регулярно сканировать (find для удаления, rsync для копирования), то ext4 начинает на таком очень быстро тормозить ужасающе. А переход на reiserfs сильно разгружает систему, даже когда ФС развёрнута не на отдельном разделе, а в loop-образе на ext4.

xfs пока на этот счёт так и не щупал. Когда-то она страшно тормозила на удалении, поэтому выпадала из рассмотрения, сейчас, говорят, в этом плане сильно улучшили. Но я пока так и не экспериментировал.

http://juick.com/Balancer/2225516

http://juick.com/Balancer/2229209

http://juick.com/Balancer/2762617

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

то ext4 начинает на таком очень быстро тормозить ужасающе

Ради интереса, а не вспомнишь опции монтирования?

A1
()
Ответ на: комментарий от xtraeft

Вот бы мне какой файл-контейнер. Типа дисков для виртуалок. Сразу размеченный одним фрагментом на 100-150 ГБ. А в него мелочь писать.

dk-
() автор топика
Ответ на: комментарий от Lordwind

Рабочая копия на ссд. Архивное хранение на винтах в 10м рейде. Но когда надо туда сюда прогнать один большой тур - начинается трата времени.

dk-
() автор топика

Что такое, ntfs не тянет ничего дальше «писечки скачать бесплатно»?

anonymous
()

\что за хрень? копия сайта с размещенными турами.

я бы предложил переделать движок туров, чтобы он не с отдельными мелкими файлами работал, а хранил всё в больших файлах-контейнерах и индексировал их самостоятельно

в геймдевелопменте такая проблема есть - хранить и читать много-много файлов с текстурами, иногда больше, чем у тебя, но они её решают, кучей мелких файликов не хранят

Harald ★★★★★
()
Ответ на: комментарий от dk-

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

а мелкие картинки удобно складывать в tiff как отдельные страницы/кадры.

MKuznetsov ★★★★★
()
Ответ на: комментарий от dk-

ИМХО не поможет, все равно в IOPS упрешься, хоть твое файло будет в одном образе. Ты его примонтировал, а дальше что? Правильно, ты всю эту мелочь будешь читать, и хоть они и в одном большом файле, от тормозов это не очень поможет. Создай файл размером сколько тебе надо, да отформатируй. Контейнер готов.

yars068 ★★★★
()

файлов миллионы, а диск один?

нужно добавить дисков, это очевидно. а какая там фс всё равно.

ukr_unix_user ★★★★
()
Ответ на: комментарий от A1

Ради интереса, а не вспомнишь опции монтирования?

Они у меня более-менее одинаковые всюду. Что-то типа:

rw,noatime,nodiratime,commit=290,barrier=0,data=writeback

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Да, все расслабленно донельзя, особенно commit=290). Thx.

A1
()
Ответ на: комментарий от anonymous

Nodiratime входит в noatime

Я в курсе. Это осталось с каких-то древних экспериментов.

а reiserfs ожидает barrier=none

Я привёл мои опции монтирования для ext4 :) С resierfs — только noatime и то не всюду. На кешах, как раз, включено, чтобы видеть к чему давно не было обращений.

KRoN73 ★★★★★
()
Ответ на: комментарий от dk-

https://www.opennet.ru/opennews/art.shtml?num=36153

В файловой системе Ext4 добавлена поддержка inline-хранения данных, что позволяет значительно увеличить эффективность хранения очень мелких файлов за счёт размещения данных прямо внутри inode, что значительно экономит дисковое пространство. По умолчанию размер inode составляет 256 байт, а размер блока данных 4 Кб. Ранее, даже если файл занимал несколько байт, ему всё равно выделялся блок в 4 Кб. Отныне, содержимое файлов, размером несколько байт, может сохраняться прямо в inode без выделения дополнительных блоков данных. При хранении исходных текстов ядра новая возможность позволяет сэкономить примерно 1% дискового пространства, для типового раздела /usr экономия составляет 3%. Кроме экономии дискового пространства хранение данных в inode также позволило заметно увеличить скорость доступа к мелким файлам, за счёт сокращения числа перемещений головки и минимизации операций чтения с диска;

Я так хранил научные измерения: 1 минута - 1 файл. Суточные измерения. Файлов много. Раздел на Ext4 полностью устроил меня. Так как использовалась Windows, то приходилось копировать данные на диски ntfs. В Ext4 файлы копируются в 2 раза быстрее.

neon1ks ★★
()
Ответ на: комментарий от neon1ks

У меня больше файлов. В 5 раз :) А месте меньше.
Пичалька.

dk-
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.