MongoDB как хранилище файлов

Ответ 1

Я могу ответить только на MongoDB здесь, я не буду притворяться, что много знаю о HDFS и других подобных технологиях.

Реализация GridFs является полностью клиентской частью внутри самого драйвера. Это означает, что нет никакой особой нагрузки или понимания контекста файла, обслуживающего сам MongoDB, фактически сам MongoDB даже не понимает, что это файлы (http://docs.mongodb.org/manual/applications/gridfs/).

Это означает, что запрос любой части коллекции files или chunks приведет к тому же процессу, что и для любого другого запроса, посредством чего он загружает данные, которые ему нужны, в ваш рабочий набор (http://en.wikipedia.org/wiki/Working_set), который представляет собой набор данных (или всех загруженных данных в то время), требуемых MongoDB в течение определенного периода времени для поддержания оптимальной производительности. Он делает это, подбирая его в ОЗУ (хорошо технически это делает ОС).

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

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

С учетом этого мы уже попали в первую зацепку:

Будут ли кэшироваться файлы из gridfs в ram и как это повлияет на производительность чтения и записи?

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

Для больших файлов это не так. На большинстве компьютеров не будет 600 ГБ ОЗУ, и вполне вероятно, что на самом деле вполне нормально размещать 600 ГБ раздела одного файла на одном экземпляре mongod. Это создает проблему, так как этот файл, для обслуживания, должен вписаться в ваш рабочий набор, однако он не может быть больше, чем ваша оперативная память; на данный момент у вас может быть переполнение страницы (http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29), в результате чего сервер просто работает с ошибкой страницы 24/7, пытаясь загрузить файл. Писания здесь тоже не лучше.

Единственный способ обойти это - начать поместить один файл во многие осколки :\.

Примечание. Еще одна вещь, которую следует учитывать, заключается в том, что средний размер по умолчанию chunks "chunk" по умолчанию равен 256 Кбайт, поэтому много документов для файла объемом 600 ГБ. Этот параметр можно манипулировать большинством драйверов.

Что произойдет с gridfs, когда я попытаюсь написать несколько файлов одновременно. Будет ли какой-либо замок для операций чтения/записи? (Я буду использовать его только в качестве хранилища файлов)

GridFS, являясь только спецификацией, использует те же блокировки, что и в любой другой коллекции, как блокировки чтения, так и записи на уровне базы данных (2.2+) или на глобальном уровне (до 2.2). Эти два тоже мешают друг другу, т.е. Как вы можете обеспечить последовательное чтение документа, который записывается?

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

Возможно, есть другие решения, которые могут более эффективно решить мою проблему?

Я лично обнаружил, что S3 (как указано в @mluggy) в сокращенном формате резервирования лучше всего сохраняет только часть метаданных о файле в MongoDB, так же, как использование GridFS, но без коллекции chunks, пусть S3 обрабатывает все эти дистрибутивы, резервное копирование и прочее для вас.

Надеюсь, я был ясен, надеюсь, что это поможет.

Изменить: в отличие от того, что я случайно сказал, MongoDB не имеет блокировки уровня коллекции, это блокировка уровня базы данных.

Ответ 2

Я начну с ответа на первые два:

• При записи в GridFS есть блокировка записи, да. Нет блокировки для чтения.
• Файлы не будут кэшироваться в памяти при запросе их, но их метаданные будут.

GridFS не может быть лучшим решением для вашей проблемы. Записывающие блоки могут стать чем-то больным, когда вы имеете дело с подобным типом ситуации, особенно для огромных файлов. Существуют и другие базы данных, которые могут решить эту проблему для вас. HDFS - хороший выбор, но, как вы говорите, это очень сложно. Я бы рекомендовал рассмотреть механизм хранения, такой как Riak или Amazon S3. Они больше ориентированы на хранение файлов и не имеют серьезных недостатков. S3 и Riak имеют отличные административные возможности и могут обрабатывать огромные файлы. Хотя с Riak, последний раз я знал, вам нужно было сделать несколько файлов для хранения файлов более 100 Мб. Несмотря на это, как правило, лучше всего сделать некоторый уровень chunking для огромных размеров файлов. Существует много плохих вещей, которые могут произойти при передаче файлов в базы данных. От сетевых тайм-аутов до переполнения буфера и т.д. В любом случае ваше решение потребует значительного количества настроек для массовых размеров файлов.

Ответ 3

Рассматривали ли вы сохранение метаданных на MongoDB и запись фактических файлов на Amazon S3? Оба имеют превосходные драйверы, а последние - избыточное, облачное/cdn-готовое хранилище файлов. Я бы дал ему шанс.