|
|
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
Скажите, возникнут ли проблемы со скоростью доступа к папке если количество файлов в ней будет составлять тысячи? Десятки тысяч? В перспективе миллионы и десятки миллионов. Размер файлов не бошльше мегабайта и средний размер порядка трёхсот килобайт. Есть ли смысл распихивать их по папкам? Количество папок будет примерно в 30-40 раз меньше количества файлов? Какие файловые системы (из потдерживаемых линухой и фрёй) лучше справятся с такой задачей? Насколько грамотного администрирования требует такой файлсервер? Тоесть насколько трудно было бы обеспечить его работоспособность при среднем количестве запросов в 100-200 в секунду? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2006, 22:13:03 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
Все зависит от того каким образом и с помощью чего вы будете работать с этими файлами. Но однозначно можно сказать что в том случае если вы раскидаете их по папкам, то это будет более правильно... м... тут лучше всего собирать RAID0+1.... ну типа чтобы побольше шпинделей обслуживало раздел... Ну и по крайней мере нужно знать больше читать или писать будете.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 06:51:30 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
Читать примерно в 200-300 раз чаще чем писать. Может даже в тысячу. Доступ будет и на запись и на чтение из PHP скрипта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 07:52:10 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
вопрос более чем непростой - железо точно должно быть ну очень хорошим . посколько читать на порядки больше придется нежели писать - то полностью отказыватьсмя от журналируемой ФС не стоит.... но с уровнем журналирования придется поиграться..... по идее ответ на самый первый вопрос - да - скорость выборки из такой папки где миллионы файлов - будет ниже..... да и работать с такими папками придется через xargs так что есть серьезный повод более полно структурировать каталог файлов :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 08:51:57 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
А может таки воспользоваться БД с blob'ами, как это и принято в таких ситуациях? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 12:30:20 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
no-dashi-v2А может таки воспользоваться БД с blob'ами, как это и принято в таких ситуациях?А вы так уверены в достаточной производительности такого решения?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 12:39:01 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
no-dashi-v2А может таки воспользоваться БД с blob'ами, как это и принято в таких ситуациях? Полагаю это намного больше увеличит нагрузку как на ЦП, так и на винты. Да ивообще. Если они файлом лежат, то для того чтоб выдать файл пахать придётся апачу и ядру. А если в базе, то ещё PHP и СУБД присоединятся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 15:51:12 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
Да, забыл спросить: причины отказаться от жюрнарирования ФС какие? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 15:52:05 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
В обшем смысл таков - отказаться от журналирования можно - если это отдельный раздел..... и сохранность данных не настолько критична.... журналирование сильно тормозит на записи..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 15:54:45 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
SarinЕсли они файлом лежат, то для того чтоб выдать файл пахать придётся апачу и ядру. А если в базе, то ещё PHP и СУБД присоединятся. 1. Вы в курсе что один файл = 1 inode? Сколько inode делается на ФС по умолчанию? И знаете ли вы что без пересоздания ФС вы это число не увеличите? Сколько процентов дискового пространства съест миллион inodes (а это минимум 1 блок на _каждый_ inode). 2. Создайте в одном каталоге 50000 файлов. Потом попробуйте их удалить. В последнюю свою разборку с "хвостами" одного знакомого, у которого на ФС создалось в почтовом спуле несколько десятков тысяч файлов, они удалялись почти 40 минут (а это был монстр с 2 x 3.4GHz процессорами и 4 гигами оперативки, используемой под кэш VFS). Кстати, для удаления пришлось писать специальный скрипт, поскольку rm * не работал. Но перед удалением создайте еще 10000 файликов. И посмотрите на загрузку процессора. 3. Сколько суток в результате у вас будет идти fsck вашей файловой системы? Это тоже немаловажный фактор, кстати. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 09:22:36 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
SarinЧитать примерно в 200-300 раз чаще чем писать. Может даже в тысячу. Доступ будет и на запись и на чтение из PHP скрипта. Не советую так делать НИКОГДА. Выделите в именах файлов первые 2 символа, и сделайте что то типа ab/abakus ci/cirrus (заметьте, что я ПОВТОРЯЮ полное имя, то есть не пишу ab/akus - это позволяет в будущем ЛЕГКО переделать размещение файлов). Файловые системы работают с такой дрянью достаточно плохо, исключая может reiserfs (да и то - не уверен), кроме того, вы имеете шанс уронить бэкапную систему или что то еще такими каталогами. При этом раскидать совсем не сложно. База данных зачастую еще хуже будет (например, логи в базе данных - это вообще гемморой сплошной). Так что просто раскидывайте по 2-м буквам и получите нормальное время доступа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 10:10:14 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
А, еще: - журналирование ОБЯЗАТЕЛЬНО. Просто таки ОБЯЗАТЕЛЬНО. Не вздумайте играться без него. - раскидав по каталогам, вы можете легко раскидать и по файловым системам, просто например слинковав все a* в файловую систему /a а все b* в файловую систему b* - Файловые системы годятся тут только reiserfs xfs да пожалуй можно еще jfs попробовать. Но из трех только первая очень широко используется. Кстати, она же динамически расширяемая. - продумайте как будет работать бэкап. - продумайте как сделать так чтобы архивные данные (те ваши файлы которые давно уже никто не трогает) не мешались тем, с которыми работают сегодня. Возможно, есть смысл даже искать файл в 2 местах. - база + blog - не знаю, иногда будет лучше, и очень часто - много хуже. Но тоже вариант. - число инодов - естественно, требует раздумий тоже. Но опять таки, раскидывание по каталогам позволяет достаточно легко менять размещение файлов в будущем. Поиск по двум местам - еще лучше (вы можете спокойно двигать файлы со старого места на новое, например). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 10:15:30 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
(читать blob а не blog). На практике часто делают проще - файлы раскидываются по номерам последовательно и по дереву (1/100/1002130.dmx), а в базу пишется индекс и всякая информация для поиска - после чего обходятся без blob-ов с которыми много своего геммороя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 10:18:16 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
стало интересно, провёл опыт. FreeBSD4.11 UFS+S GENERIC-ядро, машина 500MHz P-III Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 11:32:29 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
да, удалил ьак: Код: plaintext 1. 2. 3. 4. я так понимаю их он потратил на поиск нет ли среди этих десяти тыщщ файлов других директорий.... Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 11:35:48 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
Всем большое спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 21:47:40 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
Alex Roudnev База данных зачастую еще хуже будет (например, логи в базе данных - это вообще гемморой сплошной). Дело в том что blob-ы в логи обычно не пишутся. С СУБД самое правильное решение ИМХО. Возьмите бесплатный постгре-скл и не мучайтесь, загрузка процессора и дисков получится значительно меньше. Это тоже ИМХО. Файловая система это тоже СУБД, только без индексов. В любом случае узкое место будет не в процессоре и дисках, а в сети. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 23:59:18 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
Или так find xxx -type f -print | xargs rm -f Но заметим, что FreeBSD и UFS тут будут здорово проигрывать линуксам с ReiserFS lissyara да, удалил ьак: Код: plaintext 1. 2. 3. 4. я так понимаю их он потратил на поиск нет ли среди этих десяти тыщщ файлов других директорий.... Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2006, 03:00:28 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
c127 Alex Roudnev База данных зачастую еще хуже будет (например, логи в базе данных - это вообще гемморой сплошной). Дело в том что blob-ы в логи обычно не пишутся. С СУБД самое правильное решение ИМХО. Возьмите бесплатный постгре-скл и не мучайтесь, загрузка процессора и дисков получится значительно меньше. Это тоже ИМХО. Файловая система это тоже СУБД, только без индексов. В любом случае узкое место будет не в процессоре и дисках, а в сети. Я имел в виду, что все виданные мною попытки системные и прочие логи обрабатывать через базу данных смотрелись просто ужасно, и простейшая записьб оных логов в файлы по какой то простейшей структуре (скажем, по датам появления) ускоряло и упрощало все и вся. Я не про логи оракла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2006, 03:02:16 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
Еще деталь time rm -rf xxx зачем date использовать, неясно! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2006, 03:03:05 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
С таким объемом файлов/записей используй лучше СУБД. Про что уже пытались намекнуть... Не зря ведь их (СУБД) придумали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2006, 11:22:53 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
nik_xС таким объемом файлов/записей используй лучше СУБД. Про что уже пытались намекнуть... Не зря ведь их (СУБД) придумали? База будет еще хуже. Оптимально, как я уже писал, или использовать гибрид - файлы имеют иерархические имена, а индекс делается через базу, или использовать Large Objects в базе которые по сути и есть _файл плюс индекс_. А так база намного менее эффективна - если у вас есть 1 терабайт мелких файлов, то их можно достаточно сносно организовать в несколько файловых систем, можно легко передвинуть на другой диск, закомпрессировать, удалить - а вот с базой все это будет сложно. База нужна, если поиска по простой иерархии имен недостаточно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2006, 22:00:42 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
Alex Roudnev Я имел в виду, что все виданные мною попытки системные и прочие логи обрабатывать через базу данных смотрелись просто ужасно, и простейшая записьб оных логов в файлы по какой то простейшей структуре (скажем, по датам появления) ускоряло и упрощало все и вся. Я не про логи оракла. Это по-видимому была какая-то ошибка в конфигурировании или проектировании БД, такого быть не должно. Что значит "простейшая запись оных логов в файлы"? Сколько там было логов и куда они писались до того, если не в файлы? В сайбейз АСА, например логов можт максимум быть два на БД: обычный и зеркальный. Но как правило используется один, если не нужна особая надежность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2006, 22:01:30 |
|
||
|
Большое количество файлов в папке.
|
|||
|---|---|---|---|
|
#18+
Alex Roudnev База будет еще хуже. Оптимально, как я уже писал, или использовать гибрид - файлы имеют иерархические имена, а индекс делается через базу, или использовать Large Objects в базе которые по сути и есть _файл плюс индекс_. BLOB не есть файл+индекс. Какую СУБД Вы использовали? Я подозреваю что-то вроде фокспро или парадокса. Alex Roudnev А так база намного менее эффективна - если у вас есть 1 терабайт мелких файлов, то их можно достаточно сносно организовать в несколько файловых систем, можно легко передвинуть на другой диск, закомпрессировать, удалить - а вот с базой все это будет сложно. База нужна, если поиска по простой иерархии имен недостаточно. БЛОБ-ы в файерберде, например, компрессуются, зачем их еще компрессировать? К тому же гифы или джепеги компрессировать бессмысленно. Удалять из БД гораздо проще чем из ФС, плюс целостность поддерживает БД, а в ФС - руками. На другой диск часть таблицы тоже передвигается без проблем, если использовать подходящий СКЛ сервер, ДБ2, например, есть бесплатная версия без ограничения на объем данных. Это называется partitioned table. Единственный недостаток файлов в базе это то что с картинками нельзя работать средствами файловой системы, но это редко когда нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2006, 22:13:26 |
|
||
|
|

start [/forum/topic.php?fid=25&msg=33657084&tid=1489579]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
70ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 367ms |

| 0 / 0 |
