Ответ 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 не имеет блокировки уровня коллекции, это блокировка уровня базы данных.