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

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

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

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

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

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

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

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

Это очень похоже на более легкую проблему, с которой сталкиваются серверы новостей 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, подождите, пока он не укажет полноту, при необходимости запросите проверку для проверки, а затем удалите диск. Конечно,

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

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

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

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

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

Есть несколько вариантов. Самое простое и должно работать со всеми файловыми системами 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.

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

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

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

• http://www.xtreemfs.org/
• http://code.google.com/p/kosmosfs/
• http://hadoop.apache.org/hdfs/

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

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

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

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

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

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

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

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

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

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

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

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

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

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

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

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

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

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

Benjamin,

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

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

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

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

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