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

Я могу ответить только за 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 кэшироваться в ОЗУ и как это повлияет на производительность чтения и записи?

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

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

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

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

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

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

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

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

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

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

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