Я использую библиотеку, которая отображает большой файл ресурсов. Я подумываю сохранить этот файл ресурсов в ведре gcloud и использовать GCSFuse, чтобы сделать файл доступным для mmapping, вместо того, чтобы создавать собственное решение для загрузки файла вручную.
По соображениям производительности я хочу знать, когда файл фактически загружается, когда я использую mmap для файла в корзине через gcsfuse: если он загружается сразу, когда я использую mmap, это идеально. Если куски загружаются, когда я обращаюсь к различным частям файла через указатель mmapped, я полагаю, что это будет медленнее из-за нескольких вызовов ведра, и я бы, вероятно, использовал другой метод, если это так.
Это конкретная деталь реализации, поэтому обязательно прочтите документацию. README.md от 6ab0a79 говорит следующее:
Скачивание содержимого объекта
При первом изменении вновь открытого файла gcsfuse загружает все содержимое объекта резервного копирования из GCS. Содержимое хранится в локальном временном файле, расположение которого контролируется флагом --temp-dir. Позже, когда файл закрывается или выполняется fsync'd, gcsfuse записывает содержимое локального файла обратно в GCS в качестве нового поколения объекта.
Файлы, которые не были изменены, читаются по частям по запросу. gcsfuse использует эвристику для определения того, когда файл читается последовательно, и в этом случае будет выдавать меньшее количество больших запросов чтения к GCS.
Следствием этого является то, что gcsfuse относительно эффективен при чтении или записи целых больших файлов, но не будет особенно быстрым для небольшого числа случайных записей в больших файлах, и в меньшей степени то же самое верно для небольших случайных чтений. Производительность при копировании больших файлов в GCS сравнима с gsutil (примечания к тестированию см. В проблеме №22). Как обсуждалось выше, возникают некоторые накладные расходы из-за размещения данных в локальном временном файле.
Обратите внимание, что новые и измененные файлы также полностью размещаются в локальном временном каталоге до тех пор, пока они не будут записаны в GCS из-за закрытия или fsync'd. Поэтому пользователь должен убедиться, что имеется достаточно свободного места для обработки поэтапного содержимого при записи больших файлов.
Обратите внимание на то, что запись загружается целиком, запись всего объекта более эффективна, а также удивительное поведение в semantics.md. Будет более эффективно пропустить уровень объединенной файловой системы и напрямую читать и записывать целые фрагменты ваших данных в виде больших двоичных объектов хранилища с помощью GCS SDK. Но это существенное изменение в том, как это приложение использует хранилище.