Хранение и резервное копирование 10 миллионов файлов в Linux

25

Я управляю веб-сайтом, где около 10 миллионов файлов (обложек книг) хранятся в 3 уровнях подкаталогов, начиная с [0-f]:

0/0/0/
0/0/1/
...
f/f/f/

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

Однако, когда мне нужно сделать резервную копию этих файлов, требуется много дней, чтобы просто просмотреть каталоги 4k, содержащие 10-метровые файлы.

Поэтому мне интересно, могу ли я хранить эти файлы в контейнере (или в контейнерах 4k), каждый из которых будет действовать точно так же, как файловая система (какой-то монтированный контейнер ext3 / 4?). Я предполагаю, что это было бы почти так же эффективно, как прямой доступ к файлу в файловой системе, и это имело бы большое преимущество, заключающееся в очень эффективном копировании на другой сервер.

Любое предложение о том, как сделать это лучше всего? Или любая жизнеспособная альтернатива (noSQL, ...)?

Вениамин
источник
Какую файловую систему вы используете сейчас?
cmcginty
NetApp - это всего лишь вариант, если вы можете оценить цены
Иан Рингроз
Я использую ext4 под CentOS 5.6
Бенджамин
1
Любопытно, почему «много дней уходит на просмотр каталогов 4k, содержащих 10-метровые файлы», что кажется слишком медленным. Предполагая 150 байтов на путь, 10-метровые имена файлов составляют 1,5 ГБ данных, поэтому это может быть доступная память / ЦП (включая сортировку результата). Кроме того, проверьте, помогает ли включение / отключение dir_index: lonesysadmin.net/2007/08/17/… плюс различные советы на serverfault.com/questions/183821/…
RichVel
Обратите внимание, 5 лет спустя: я перенес все на Amazon S3, который идеально подходит для хранения такого большого количества файлов. Кроме того, мне больше не нужно разбивать файлы на 3 уровня подкаталогов, поскольку для S3 это не имеет значения (путь - это путь, независимо от того, содержит ли он косую черту или нет). И я могу спать лучше, зная, что мои данные безопасно реплицируются в нескольких местах.
Бенджамин

Ответы:

11

Варианты быстрого доступа и резервного копирования миллионов файлов

Заимствовать у людей с похожими проблемами

Это очень похоже на более легкую проблему, с которой сталкиваются серверы новостей USENET и кэширующие веб-прокси: сотни миллионов небольших файлов, к которым осуществляется произвольный доступ. Возможно, вы захотите получить подсказку от них (за исключением того, что они обычно не должны делать резервные копии).

http://devel.squid-cache.org/coss/coss-notes.txt

http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf

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

Выделенные файловые системы

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

LVM

Я упомянул LVM выше как полезный, чтобы позволить динамическое изменение размера раздела, чтобы вам не нужно было создавать резервные копии большого количества пустого пространства. Но, конечно, у LVM есть и другие функции, которые могут быть очень применимы. В частности, функция «снимка», которая позволяет вам мгновенно заморозить файловую систему. Любой случайный rm -rfили что-то еще не мешало бы снимку. В зависимости от того, что именно вы пытаетесь сделать, этого может быть достаточно для ваших нужд резервного копирования.

RAID-1

Я уверен, что вы уже знакомы с RAID и, вероятно, уже используете его для надежности, но RAID-1 можно использовать и для резервного копирования, по крайней мере, если вы используете программный RAID (вы можете использовать его с аппаратным RAID, но это на самом деле обеспечивает более низкую надежность, поскольку для чтения может потребоваться одна и та же модель / контроллер версии. Идея заключается в том, что вы создаете группу RAID-1 с одним диском, который больше необходим вам для нормальной безопасности (например, третий диск, если вы используете программный RAID-1 с двумя дисками, или, возможно, большой диск и аппаратное обеспечение). RAID5 с небольшими дисками с программным RAID-1 поверх аппаратного RAID-5). Когда придет время сделать резервную копию, установите диск, попросите mdadm добавить этот диск в группу raid, подождите, пока он не укажет полноту, при необходимости запросите проверку для проверки, а затем удалите диск. Конечно,

Сет Робертсон
источник
Очень полный ответ, который обобщает хорошие решения. Я думаю, что я сохраню свою существующую структуру файловой системы и буду использовать снимки LVM, что, кажется, идеально подходит для моего случая использования.
Бенджамин
9

Вы можете смонтировать виртуальную файловую систему с помощью диспетчера зацикливания, но хотя это ускорит процесс резервного копирования, это может повлиять на нормальные операции.

Другой альтернативой является резервное копирование всего устройства с использованием dd. Например, dd if=/dev/my_device of=/path/to/backup.dd.


источник
+1 Резервное копирование самого устройства - хорошая идея.
Asm
3
Вам следует, если вы используете этот подход, протестировать восстановление (ну, вы всегда должны это делать), потому что, если ваш ввод - это диск, такой как / dev / sdd, dd будет хранить схему и размеры раздела. Если вы восстановите его на меньший диск, вы получите ошибки, а если вы восстановите его на больший диск, он будет обрезан. Это будет работать лучше всего, если вы восстановите данные на другом экземпляре диска того же типа. Восстановление только разделов (/ dev / sdd1) будет менее хлопотным.
пользователь неизвестен
1
Обратите внимание, что если устройство работает на LVM, резервное копирование также может быть выполнено без размонтирования диска с использованием снимков LVM.
bdonlan
Я второй подход резервного копирования снимка LVM. В прошлом я использовал lvm для живой репликации DR. Использование dd в сочетании со снимками позволяет быстро создавать резервные копии на уровне блоков.
Слэшдот
Я попытался ddболее , ncи это делает хорошую работу! Однако у меня могут быть противоречивые / поврежденные данные, в отличие от использования снимков LVM вместо живого раздела.
Бенджамин
8

Как вы, наверное, знаете, ваша проблема - местность. Типичный поиск диска занимает около 10 мс. Так что просто вызов «stat» (или open ()) для 10 миллионов случайно размещенных файлов требует 10 миллионов поисков, или около 100000 секунд, или 30 часов.

Таким образом, вы должны поместить ваши файлы в более крупные контейнеры, чтобы соответствующее число было пропускной способностью вашего диска (обычно 50-100 МБ / с для одного диска), а не временем поиска. Кроме того, вы можете использовать RAID, что позволит вам увеличить пропускную способность (но не сократить время поиска).

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

Nemo
источник
Да, местность имеет решающее значение. Посмотрите на ваши шаблоны использования. Большинство проблем, как правило, следуют принципу Парето (80% процессов затрагивают 20% данных), поэтому, если вы можете выяснить, какие файлы необходимо кэшировать в ОЗУ, или просто поместить в отдельный раздел с другим расположением каталогов, так это займет меньше поиска или поиска в каталоге, это, вероятно, очень поможет. Распределение часто используемых файлов на разных шпинделях дисков, чтобы поиск мог выполняться параллельно, также может помочь. +1 за @nemo для поднятия населенного пункта.
Марчин
5

Есть несколько вариантов. Самое простое и должно работать со всеми файловыми системами Linux, это ddскопировать весь раздел ( /dev/sdb3или /dev/mapper/Data-ImageVol) в один образ и заархивировать этот образ. В случае восстановления отдельных файлов, выполните петлевое монтирование образа ( mount -o loop /usr/path/to/file /mountpoint) и скопируйте нужные файлы. Для полного восстановления раздела вы можете изменить направление исходной ddкоманды в обратном направлении , но вам действительно нужен раздел одинакового размера.

Судя по вашему варианту использования, я предполагаю, что отдельные операции восстановления файлов - это очень редкое событие, если оно вообще происходит. Вот почему резервное копирование на основе образов действительно имеет смысл здесь. Если вам нужно делать отдельные восстановления чаще, использование поэтапных снимков LVM будет намного удобнее; но вам все равно нужно сделать резервное копирование на основе образов для тех критических бедствий, которые «мы потеряли все». Восстановление на основе изображений, как правило, выполняется намного быстрее, чем восстановление на основе tar, просто потому, что это просто восстановление блоков, оно не требует большого количества операций с метаданными с каждым fopen / fclose, а также может быть очень последовательной дисковой операцией для дальнейшая скорость увеличивается.

В качестве альтернативы, как указывало в видео Google @casey о половине пути, XFS - отличная файловая система (если она сложная). Одна из лучших утилит с XFS - это xfsdumpутилита, которая выводит всю файловую систему в один файл и, как правило, делает это быстрее, чем tarможет. Это утилита, специфичная для файловой системы, поэтому она может использовать преимущества внутренних функций fs так, как это не может сделать tar.

sysadmin1138
источник
Там много хороших ответов! XFS кажется интересным, но я боюсь, что это немного вне моей досягаемости.
Бенджамин
3

Я бы посоветовал вам сначала попробовать перейти на EXT4, если вы его еще не используете.

Google провел много исследований о том, почему EXT4 является хорошей идеей .

После этого вы должны изучить развертывание архитектуры распределенной файловой системы. Например:

cmcginty
источник
Я действительно уже использую EXT4, который выглядит великолепно!
Бенджамин
2

Возможно, упрощенный ответ, но моей первой мыслью было использование чего-то вроде GridFS, встроенного в MongoDB . Многие драйверы основного языка поддерживают его «из коробки», поэтому вы можете просто поменять его на разделы кода для чтения файлов. Кроме того, вы можете просто сделать существующие пути к каталогам ключами к этим файлам.

Одна из проблем, с которой вы можете столкнуться, заключается в том, что Mongo имеет тенденцию довольно медленно тормозить, если постоянно ищет с диска. Я предполагаю, что с 10 миллионами файлов большая часть ваших данных будет на диске. Насколько я помню, порции файлов в GridFS занимают 4 МБ, поэтому, если ваши файлы больше этого размера, вам придется выполнить несколько дорогостоящих операций, чтобы получить один файл. Я думаю, что ключ к этому будет состоять в том, чтобы ограждать ваши файлы на основе уже опрятной структуры каталогов, чтобы вы могли иметь несколько экземпляров Mongo, работающих на нескольких блоках, чтобы облегчить загрузку. Тем не менее, я не знаю, каковы ваши требования к производительности, так что, возможно, я слишком обдумываю это.

В чем выгода всего этого? Производительность, которая очень близко соответствует чтению диска, если все сделано правильно. Кроме того, Mongo поставляется с несколькими великолепными встроенными способами быстрого резервного копирования всей совокупности данных в экземпляре БД, даже при работающей базе данных.

daveslab
источник
Обязательно взглянем на GridFS, которого я не знал, но я думаю, что в конечном итоге я сохраню все на основе файловой системы, чтобы снизить объем работы, поскольку все уже работает!
Бенджамин
1

Если вы будете довольны моделью устройства для хранения данных, возможно, вы могли бы рассмотреть NexentaStor . Он работает ZFS на OpenSolaris под капотом, но все администрирование осуществляется через веб-интерфейс.

Есть несколько функций, которые помогут с вашей проблемой.

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

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

Том Шоу
источник
Спасибо, посмотрю на это. Возможно, это добавит немного сложности моему проекту!
Бенджамин
1

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

Есть соответствующая restoreутилита для восстановления резервных копий, созданных dump.

Он поддерживает инкрементное резервное копирование с использованием уровней - файлов резервных копий уровня 1, измененных из резервной копии последнего уровня 0 (полная), уровня 2 - измененных из резервной копии уровня 1 и т. Д.

Tometzky
источник
0

Для инкрементных резервных копий одним из вариантов может быть второе, теневое дерево для новых обложек. То есть у вас будет ваше основное дерево, которое используется для всех операций чтения. У вас также будет newfiles/012345.....jpgкаталог; Недавно добавленные обложки создают жесткую ссылку как здесь, так и в основном дереве. Выполняя резервное копирование, вы можете время от времени создавать резервные копии основного дерева, но гораздо реже делать резервные копии (гораздо меньшего) newfilesдерева.

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

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

Конечно, как только вы это сделаете, вы создадите новую резервную копию основного дерева.

bdonlan
источник
Интересный подход, спасибо, что поделились им. Но я боюсь, что это повлечет за собой множество изменений в приложении, и было бы трудно сохранить приложение и потребности в хранилище на двух отдельных уровнях.
Бенджамин
0

Добавление небольшого количества параллелизма обычно помогает.

У меня похожая проблема, чем у вас; в моем случае мне нужно сделать резервную копию около 30 миллионов файлов, большинство из которых HTML, PHP или JPEG. Для меня BackupPC + rsync через ssh работает нормально. Полное резервное копирование занимает около одного дня, но инкрементные копии обычно заканчиваются через пару часов.

Хитрость заключается в том, чтобы добавить каждый каталог основного уровня (0, 1, 2 ... a, b, c ...) в качестве новой цели для копирования в BackupPC и позволить ему выполнять резервное копирование параллельно, чтобы одновременно выполнять резервное копирование каталогов а / , б / , с / * и тд. В зависимости от вашей дисковой подсистемы, возможно, самый быстрый способ резервного копирования - от пары процессов до примерно 10 процессов.

Снимки LVM и резервное копирование на уровне блоков также является опцией, но с BackuPC и резервным копированием на уровне файлов вы все равно можете восстанавливать отдельные файлы или каталоги, если это необходимо.

Янне Пиккарайнен
источник
Я удивлен, что резервное копирование корневых каталогов одновременно решает проблему для вас, я ожидаю, что это будет на самом деле медленнее. Все ли каталоги на одном диске? Вы используете SSD?
Бенджамин
Файлы данных хранятся в сети SAN.
Янне Пиккарайнен
Хорошо, теперь имеет смысл, вы получаете эффективность благодаря одновременному доступу к нескольким файлам, потому что ваши разные папки, скорее всего, физически расположены на разных дисках в SAN или, по крайней мере, реплицированы на нескольких дисках, что обеспечивает одновременный доступ. Я использую только RAID-1, поэтому я предполагаю, что после двух одновременных обращений моя скорость, скорее всего, снизится.
Бенджамин
0

Benjamin,

Я думаю, что ваша проблема может быть решена по количеству файлов на уровне каталога!

Значительно ли меняется время доступа, если вы храните 20 000 файлов в каталоге?

Также вы пытались хранить метаданные файловой системы на отдельном диске с более быстрым доступом? (Например, на SSD).

Dragos
источник
0

Я бы порекомендовал вместо этого хорошую старую реляционную базу данных.

Я бы использовал PostgreSQL, скажем, с 256 многораздельными таблицами (cover_00, cover_01, ..., cover_ff) с данными изображения в виде bytea(двоичного) столбца с внешним хранилищем, с идентификатором файла в качестве первичного ключа. Извлечение образа будет быстрым (благодаря индексу первичного ключа), целостность данных будет гарантирована (база данных, соответствующая ACID), резервное копирование будет осуществляться в порядке дисков, поэтому поиск будет не слишком сложным.

Tometzky
источник