Как лучше хранить много файлов на сервере?
если файловая система такое не позволяет значит это неправильная файловая система (с)
в одну директорию сваливать конечно не нужно, лучше создать двухуровневую структуру как гит — 256 директорий а в них файлы. можно больше.
это убирает lock contention на i_mutex-е при создании новых файлов и кэш-мисе.
главное чтоб потом не было мудацких скриптов или slocate который всю эту хрень рекурсивно обходит.
в одну директорию сваливать конечно не нужно, лучше создать двухуровневую структуру как гит — 256 директорий а в них файлы. можно больше.
это убирает lock contention на i_mutex-е при создании новых файлов и кэш-мисе.
главное чтоб потом не было мудацких скриптов или slocate который всю эту хрень рекурсивно обходит.
Посмотри на Alfresco.
Причем файлов будет много (допустим, миллион).Это мало.
Поместится на 1 машине. Ваш КО.
Во-первых, раздели ФС где складываешь и откуда отдаешь. Это должны быть физически разные сервера.
Вот расклад для относительно небольшой системы.
Там где ОТДАЕШЬ:
1. директории вида 01 02 03 04 ... ff, всего 256. Сначала на 1 сервере, потом разнесешь на 2, 4, 8 и так далее, до 256 машин у тебя дробление заложено.
2. Каждая машинка свой nginx имеет, и умеет отдавать какие папки (на другие ругается 404).
3. директории раздаются RW любой удалённой ФС, например, NFS.
Машинки с софтом: монтируешь по NFS на каждой софтверной машинке все директории.
Системы покрупнее стоит проектировать иначе. Вариантов много, нужно уточнять задачу.
Вот расклад для относительно небольшой системы.
Там где ОТДАЕШЬ:
1. директории вида 01 02 03 04 ... ff, всего 256. Сначала на 1 сервере, потом разнесешь на 2, 4, 8 и так далее, до 256 машин у тебя дробление заложено.
2. Каждая машинка свой nginx имеет, и умеет отдавать какие папки (на другие ругается 404).
3. директории раздаются RW любой удалённой ФС, например, NFS.
Машинки с софтом: монтируешь по NFS на каждой софтверной машинке все директории.
Системы покрупнее стоит проектировать иначе. Вариантов много, нужно уточнять задачу.
Прямо в постгре нельзя? В оракле можно прямо в бд хранить файлы.
В оракле можно прямо в бд хранить файлы.А стоит?
а почему нет?
Про миллион не уверен, но вообще мы хранили в постгре блобами картинки, если не много
Про миллион не уверен, но вообще мы хранили в постгре блобами картинки, если не много
Да во всех приличных БД можно, но, ИМХО, не нужно.
http://stackoverflow.com/questions/1347461/saving-images-fil...
http://stackoverflow.com/questions/211895/storing-documents-...
http://stackoverflow.com/questions/1347461/saving-images-fil...
http://stackoverflow.com/questions/211895/storing-documents-...
мы хранили в постгре блобами картинкиВидео тоже можно.
в одну директорию сваливать конечно не нужно, лучше создать двухуровневую структуру как гит — 256 директорий а в них файлы. можно больше.это убирает lock contention на i_mutex-е при создании новых файлов и кэш-мисе.спасибо! пожалуй, так и сделаю
Во-первых, раздели ФС где складываешь и откуда отдаешь. Это должны быть физически разные сервера.
1. директории вида 01 02 03 04 ... ff, всего 256. Сначала на 1 сервере, потом разнесешь на 2, 4, 8 и так далее, до 256 машин у тебя дробление заложено.
2. Каждая машинка свой nginx имеет, и умеет отдавать какие папки (на другие ругается 404).
3. директории раздаются RW любой удалённой ФС, например, NFS.
спасибо за совет! у меня пока нагрузки не такие большие, хочу обойтись одним сервером (максимум - двумя).
Поместится на 1 машине. Ваш КО.Я как раз хотел узнать, как лучше организовать хранение файлов на одной машине, чтобы можно было легко оперировать бэкапами и не было излишней нагрузки при запросах файлов.
fi/le/na/me.ext
Самый оптимум, на мой взгляд
Самый оптимум, на мой взгляд
Я как раз хотел узнать, как лучше организовать хранение файлов на одной машине, чтобы можно было легко оперировать бэкапами и не было излишней нагрузки при запросах файлов.Хранилище на отдельном разделе диска, ну и какая-то система подкаталогов. Чуть вышел писали недурной вариант (fi/le/name.txt но он годиться только в случае если filename — md5/sha256 от чего-то там (содержимого файла например ибо нужна равномерность размазывания по каталогам.
Стоит.
Может быть тогда стоит вместо ФС использовать БД?
к чему эта ирония?
ибо нужна равномерность размазывания по каталогам.угу, причём коллизии тут можно использовать для дос атаки.
Это был вопрос.
На первый вопрос "стоит ли" ты ответил "стоит", не пояснив, почему.
Я предположил, что ты знаешь почему, и тогда сможешь ответить и на мой вопрос, только более развернуто.
На первый вопрос "стоит ли" ты ответил "стоит", не пояснив, почему.
Я предположил, что ты знаешь почему, и тогда сможешь ответить и на мой вопрос, только более развернуто.
В любом случае, надо тщательно продумывать возможные кейсы. Но если предполагается много мелких картинок, я бы хранил в БД. Как именно в БД, зависело бы опять же от задач и от возможностей конкретной БД.
вопрос в кассу: а начиная с какого кол-ва файлов стоит разносить по папкам отдельным? хотя бы на уровне одного сервера и с нечастыми скачками/закачками? 1000? 10000? 1,000,000?
Представь, что "папка" - это просто текстовый файл, в котором хранится некоторая информация о всех файлах внутри папки в определенном формате. Соответственно, поиск файла по имени = поиск текстовой записи в этом файле.
и если не знаешь, как выбранная тобой ФС работает с этим списком файлов в папке, ничего особого это не даст.
Приведи какие-нибудь примеры, вкратце.
можно и много миллионов на современных ФС
на практике замечен недостаток: ls выполняется доооолго
на практике замечен недостаток: ls выполняется доооолго
И rm * не работает 
Хотя ls -U спасает
Хотя ls -U спасает
В любом случае, надо тщательно продумывать возможные кейсы. Но если предполагается много мелких картинок, я бы хранил в БД. Как именно в БД, зависело бы опять же от задач и от возможностей конкретной БД.Убивает тупость такая.
Рейзер ФБ отлично хранит файлы мелкие, очень эффективно.
А своей БД ты не столько сэкономишь места на спичках, сколько начисто убьёшь возможность нормально отдавать. Одно дело отдавать Нгинксом с рейзера, и другое дело в БД ходить за каким-то бинарным говно.
В БД имеет смысл хранить только такие "файлы", которые надо строго ограничивать по правам, например, сканы паспортов в банке. Но даже там я бы писал отдачу с ФС, даже модули есть специальные для нгинкса, которые по уникальному урлу только одают с привязкой IP, useragent, cookie (т.е. то же что ты своим скриптом проверять будешь).
вопрос в кассу: а начиная с какого кол-ва файлов стоит разносить по папкам отдельным? хотя бы на уровне одного сервера и с нечастыми скачками/закачками? 1000? 10000? 1,000,000?Оптимально до 1000 держать в папке.
10 тысяч — потолок, дальше получишь больше проблем с кучей всего.
В пределах тысячи, например, ты можешь практически незаметно бэкапить. А на 10+ тысячах у тебя создание +1 файла уже будет долгим.
Вообще, лучше напиши скрипт и потестируй. Кто ж знает какие у тебя там файлы, может ты образы DVD раздавать собрался, а мы тут про аватарки говорим.
А своей БД ты не столько сэкономишь места на спичках, сколько начисто убьёшь возможность нормально отдавать. Одно дело отдавать Нгинксом с рейзера, и другое дело в БД ходить за каким-то бинарным говно.Зато в БД нормальный бэкап.
в нормальной FS тоже нормальный бекап
Как называется эта FS?
только без холиворов )
Я теперь на ZFS файлопомойку держу RAID-Z, с кешем на SSD и всё такое
)Я теперь на ZFS файлопомойку держу
RAID-Z, с кешем на SSD и всё такоеКак называется эта FS?copy-on-write filesystem. Многие современные так умеют.
А какие признаки у "нормального бэкапа"?
Зато в БД нормальный бэкап.можно плиз поподробнее для неспециалиста? какие ключевые слова?
гугл выдаёт например такой линк, и я там не вижу ни одного нормального способа, может это плохая ссылка?
http://www.orafaq.com/wiki/Oracle_database_Backup_and_Recove...
у меня опыт только c mysql, там в принципе примерно то же
в чем нормальность определяется? Что все должно быть гуевно и одной кнопочкой? Ну это, к сожалению, не про энтерпрайз БД. В принципе, на то, чтобы запилить OS на серваке, поставить библиотеки, настроить юзеров, окражения и тп и тд, скачать и установить оракл, накатить 400Гб бэкап с удаленного сервера у меня уходило часа 4.
400Гб это ниачём, на ноутбуках больше диски сейчас
> в чем нормальность определяется?
ну например инкрементальный бекап со снапшотами за несколько дат в прошлом (месяц, неделя назад, позавчера, вчера)
и чтоб при создании каждого снапшота не копировать и не инспектировать всю базу, а только небольшую часть, которая поменялась
> в чем нормальность определяется?
ну например инкрементальный бекап со снапшотами за несколько дат в прошлом (месяц, неделя назад, позавчера, вчера)
и чтоб при создании каждого снапшота не копировать и не инспектировать всю базу, а только небольшую часть, которая поменялась
ну например инкрементальный бекап со снапшотами за несколько дат в прошлом (месяц, неделя назад, позавчера, вчера)Насколько я помню, в Оракле это все было.
и чтоб при создании каждого снапшота не копировать и не инспектировать всю базу, а только небольшую часть, которая поменялась
какие ключевые слова? я нашёл ARCHIVELOG - это интересно и действительно я не знаю аналога для ФС, но тоже не очень решает проблему, если я всё правильно понимаю
например, есть полная копия месячной давности и redo-логи от неё до настоящего момента
теперь нужна копия за вчера, и нужна сегодня
а накатить месячные логи займёт ну пусть не месяц, а 10 суток, и что делать?
полное копирование многотерабайтной базы - тоже несколько суток
например, есть полная копия месячной давности и redo-логи от неё до настоящего момента
теперь нужна копия за вчера, и нужна сегодня
а накатить месячные логи займёт ну пусть не месяц, а 10 суток, и что делать?
полное копирование многотерабайтной базы - тоже несколько суток
не понимаю, что мешает настроить бэкап так, чтобы раз в неделю снималась полная копия (например в воскресенье а в остальное дни инкрементальный бэкап от последней полной копии.
Вообще. канеш с такими вопросами лучше к специалистам DBA.
Вообще. канеш с такими вопросами лучше к специалистам DBA.
http://docs.oracle.com/cd/B19306_01/backup.102/b14192/bkup00...
http://oracle4me.blogspot.ru/2011/03/incremental-backup-and-...
http://oracle4me.blogspot.ru/2011/03/incremental-backup-and-...
не понимаю, что мешает настроить бэкап так, чтобы раз в неделю снималась полная копия (например в воскресенье)непонятно, чем воскресенье лучше других дней, если доступность сервиса нужна 24*7 - а обычно так и бывает
мешать может то, что копирование всей базы займёт больше суток, а если она ещё больше - то и недели не хватит
собственно, с небольшими объёмами - когда можно просто взять и скопировать - справляются снапшоты ФС, и я тут не вижу какие ещё могут быть преимущества у БД
первая ссылка - ARCHIVELOG - я про него написал
вторая ссылка - практически точная копия того, как делается бекап ФС со снапшота (отличия в синтаксисе команд) - только ФС не нужно размонтировать, а по этой ссылке базе делается shutdown
вторая ссылка - практически точная копия того, как делается бекап ФС со снапшота (отличия в синтаксисе команд) - только ФС не нужно размонтировать, а по этой ссылке базе делается shutdown
интересная идея да - несколько слейвов с запаздыванием держать
какие ключевые слова?Change Tracking
По первой ссылке от
Each data block in a datafile contains a system change number (SCN which is the SCN at which the most recent change was made to the block. During an incremental backup, RMAN reads the SCN of each data block in the input file and compares it to the checkpoint SCN of the parent incremental backup. If the SCN in the input data block is greater than or equal to the checkpoint SCN of the parent, then RMAN copies the block.
Note that if you enable the block change tracking feature, RMAN can refer to the change tracking file to identify changed blocks in datafiles without scanning the full contents of the datafile. Once enabled, block change tracking does not alter how you take or use incremental backups, other than offering increased performance. See "Improving Incremental Backup Performance: Change Tracking" for more details about enabling block change tracking.
да, интересно
примерно это же делает lvmsync http://github.com/mpalmer/lvmsync
примерно это же делает lvmsync http://github.com/mpalmer/lvmsync
Оставить комментарий
sutulin
Работаю над веб-проектом, который предполагает возможность загрузки пользователями файлов. Причем файлов будет много (допустим, миллион).Как лучше организовать хранение такого большого числа файлов? Складывать все в одну папку - плохой вариант, так как работа с такой папкой будет создавать излишнюю нагрузку на файловую систему. Информация о файлах будет храниться в БД.
Использую nginx + centos + postgresql
Спасибо