Разница между хранилищем объектов и хранилищем файлов

Ответ 1

IMO, хранение объектов не имеет ничего общего с масштабом, потому что кто-то может создать FS, способный хранить огромное количество файлов даже в одном каталоге.

Это также не о методах доступа. HTTP-доступ к данным в файловых системах доступен во многих известных системах NAS.

Хранение/доступ по OID - это способ обработки данных, не беспокоясь о его именовании. Это можно сделать и в файлах. Я считаю, что есть расширение протокола NFS, которое позволяет это.

Я хотел бы это сделать: хранилище объектов - это (новый/различный) "объектно-ориентированный" способ мышления данных, его доступа и управления.

Подумайте об этих моментах:

Что такое снимки сегодня? Это временные копии тома. Когда снимок сделан, все файлы в томе также защелкиваются. Независимо от того, нравится им это всем или нет, нужны ли они всем или нет. Много места можно использовать (потрачено впустую?) Для полного моментального снимка тома, в то время как нужно всего лишь несколько файлов.

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

Как защищаются файлы/тома от катастрофы? Как правило, при установке аварийного восстановления (DR) все тома/тома настраиваются для репликации на сайт DR. Опять же, это не мешает, хотят ли отдельные файлы реплицироваться или нет. Единицей защиты от стихийных бедствий является объем. Файлы мелкие.

В системе хранения объектов DR не является объемной. Метаданные объекта могут определять, сколько копий должно существовать и где (геопозиции/области ошибок).

Аналогично для других функций:

• Tiering - объекты, помещенные в уровни хранения/классы хранения на основе его метаданных, независимо от других несвязанных объектов.

• Жизнь. Объекты перемещаются между уровнями, изменяют количество копий и т.д. отдельно, а не как группу.

• Аутентификация. При необходимости отдельные объекты могут пройти аутентификацию из разных доменов аутентификации.

Как вы можете видеть, изменение мышления заключается в том, что в хранилище объектов все об объекте.

Сравните это с традиционным способом мышления и управления и доступа к более крупным контейнерам, таким как тома (содержащие файлы), не является хранилищем объектов.

Вышеприведенные функции и их объектно-ориентированность хорошо соответствуют требованиям неструктурированных данных и, следовательно, интересам.

Если система хранения является объектом (или файлом) централизованной, а не объемной в своем мышлении (независимо от протокола доступа или шкалы), это система хранения объектов.

Ответ 2

Существуют некоторые очень существенные различия между хранилищем файлов и хранилищем объектов.

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

С другой стороны, хранение объектов обычно представляет собой. RESTful API. Нет понятия файловой системы. Вместо этого приложение будет сохранять объект (файлы + дополнительные метаданные) в хранилище объектов через. API PUT и хранилище объектов будут сохранять объект где-то в системе. Платформа хранения объектов предоставит приложению уникальный ключ (аналогичный билету камердинера) для этого объекта, который приложение будет хранить в базе данных приложения. Если приложение хочет получить этот объект, все, что им нужно сделать, это предоставить ключ как часть API GET, и объект будет извлечен из хранилища объектов.

Надеюсь, теперь это ясно.

Ответ 3

Раскрытие - я работаю на поставщика (NetApp), который разрабатывает и продает как большие файловые системы, так и платформы хранения объектов, я постараюсь сделать это как можно более независимым от реализации, но мои когнитивные искажения могут бессознательно влиять на мой ответ.

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

Основное отличие от внешней/программной точки зрения состоит в том, что объект в хранилище объектов создается, удаляется или обновляется как единое целое, вы не можете добавлять данные к объекту и не можете обновить часть объекта. объект "на месте", однако вы можете заменить его, сохраняя при этом тот же идентификатор объекта. Создание, чтение, обновление и удаление объектов обычно выполняется с помощью относительно простых API-интерфейсов, которые почти всегда основаны на REST или REST и поощряют мышление, что хранилище является программируемым ресурсом или, возможно, многопользовательской удаленной службой. В то время как большинство хранилищ объектов известно о поддержке чтения байтового диапазона внутри объекта, в целом хранилища объектов изначально были предназначены для работы с целыми объектами. Хорошими примерами API хранилища объектов являются API, используемые Amazon S3 (стандарт по умолчанию для доступа к хранилищу объектов), OpenStack Swift и REST API службы BLOB-объектов Azure. Описание внутренних реализаций этих API будет само по себе книгой.

С другой стороны, файлы в файловой системе имеют более широкий набор функций, которые могут быть применены к ним, включая добавление данных и обновление данных на месте. Модель программирования является более сложной, чем хранилище объектов, и к ней теперь почти всегда обращаются программно через стиль интерфейса "POSIX", и в целом она пытается наиболее эффективно использовать процессор и память и поощряет мышление, что файловая система является частным локальным ресурсом., NFS и SMB позволяют сделать файловую систему доступной как многопользовательский ресурс, однако программисты часто относятся к ним с подозрением, поскольку иногда они имеют небольшие различия в том, как они реагируют, по сравнению с "локальными" файловыми системами, несмотря на их полную поддержку POSIX. семантика. Чтобы обновить файлы в локальной файловой системе, вы, вероятно, будете использовать такие API-интерфейсы, как https://www.classes.cs.uchicago.edu/archive/2017/winter/51081-1/LabFAQ/lab2/fileio.html или https://msdn.microsoft.com/en-us/library/mt794711(v=vs.85).aspx. Говоря об относительных достоинствах реализации файловой системы, например, NTFS против BTRFS против XFS против WAFL против ZFS имеет тенденцию приводить к религиозной войне, которая редко стоит кому-то времени, хотя, если вы купите мне пиво, я с радостью поделюсь с вами своим мнением.

С точки зрения варианта использования, если вы хотите сохранить большое количество фотографий, видео или артефактов двоичной сборки, то хранилище объектов часто является хорошим выбором. С другой стороны, если вы хотите постоянно хранить данные в двоичном дереве и обновлять эти данные на месте на носителе, тогда хранилище объектов просто не будет работать, и вам будет гораздо лучше с файловой системой (вы также можете использовать необработанные блочные устройства). для этого, но я не видел, чтобы кто-нибудь делал это с начала 90-х)

Другое большое отличие состоит в том, что файловые системы спроектированы так, чтобы быть строго согласованными, и к ним обычно обращаются по сетям с низкой или средней задержкой (50 микросекунд - 50 миллисекунд), тогда как хранилища объектов часто в конечном итоге согласуются и распределяются по инфраструктуре без совместного использования ресурсов, соединенной вместе по низкой Глобальные сети с высокой задержкой полосы пропускания и их время до первого байта иногда можно измерить кратными целым секундам. Выполнение большого количества небольших (4K - 16K) случайных операций чтения из хранилища объектов может вызвать проблемы с производительностью.

Другое основное преимущество хранилища объектов по сравнению с файловой системой заключается в том, что вы можете быть достаточно уверены, что все, что вы положили в хранилище объектов, останется там до тех пор, пока вы не попросите его снова, и что в нем никогда не останется свободного места, пока вы продолжаете платить для ежемесячных платежей. Эти ресурсы обычно работают в больших масштабах со встроенной репликацией, контролем версий, автоматическим восстановлением и т.д. И т.д., И ничто иное, как катастрофа в стиле урагана Харви, не приведет к исчезновению данных (даже в этом случае у вас есть простые варианты сделать еще одну копию в другом месте). С файловой системой, особенно той, которой, как вы ожидаете, будете управлять вы или ваши локальные сотрудники, вы должны надеяться, что все будет скопировано и что оно не заполняется случайно и приводит к тому, что все тает, когда вы больше не можете обновлять свои данные.

Я пытался быть совестливым, но, чтобы добавить в заблуждение слова "файловая система" и "хранилище объектов", применяются к вещам, которые не похожи на описания, которые я использовал выше, например, NFS, сетевая файловая система на самом деле не файловая система, ее способ реализации API хранения posix через удаленные вызовы процедур, и VMwares VSAN хранит свои данные в чем-то, что они называют "хранилищем объектов", что обеспечивает высокую скорость обновления на месте образов виртуальных машин.

Ответ 4

Простым ответом является то, что доступ к объектам, к которым обращаются системы хранения или службы, использует API-интерфейсы и другие методы доступа к объектам для хранения, поиска и поиска данных в отличие от традиционного файла или NAS. Например, с файлом или NAS вы получаете доступ к хранилищу с использованием NFS (Network File System) или CIFS (например, общий доступ к файлам Windows), а также SMB aka SAMBA, где файл имеет имя/дескриптор с соответствующими метаданными, определенными файловой системой.

Метаданные включают информацию о создании, доступе, изменениях и других датах, разрешениях, безопасности, приложении или типе файла или других атрибутах. Файлы ограничены файловой системой с точки зрения их размера, а также количеством файлов в файловой системе. Аналогично, файловые системы ограничены их суммарным или совокупным размером с точки зрения емкости пространства и количества файлов в файловой системе.

Доступ к объекту отличается тем, что в то время как файловые или NAS-интерфейсы или шлюзы или плагины доступны для многих решений или служб, первичный доступ осуществляется через API, где объект может иметь произвольный размер (максимально до объекта система) вместе с метаданными переменного размера (в зависимости от реализации объектной системы/службы). В большинстве систем хранения/служб хранения объектов вы можете указать где угодно от нескольких килобайт определенных пользователем метаданных или GBytes. Для чего вы использовали GBytes метаданных? Как в дополнение к нормальной информации, добавив больше данных для политик, руководств, где находятся другие копии, миниатюры или небольшие предварительные просмотры видео, аудио и т.д.

Некоторые примеры API или интерфейсов доступа к объектам включают простые службы хранения данных Amazon Web Services (AWS) (S3) или другие основанные на HTTP и REST, SNIA CDMI. Различные решения также будут поддерживать доступ к IOS (например, iphone/ipad), SOAP, Torrent, WebDav, JSON, XAM и другие, а также NFS/CIFS. Кроме того, многие системы хранения данных или службы поддерживают программные привязки для python среди других. API-интерфейсы позволяют вам по существу открыть поток, а затем получить или поместить, перечислить и другие функции, поддерживаемые API/системой, чтобы определить, как вы будете использовать его.

Например, я использую как файлы Rackspace Cloud, так и Amazon S3 (в дополнение к EBS и Glacier) для резервного копирования, хранения и архивирования данных. Я могу получить доступ к объектам, хранящимся через веб-браузер или инструменты, включая Jungle disk (JD), с которым я делаю резервное копирование и синхронизацию файлов. JD обрабатывает управление объектами и перемещает данные как в Rackspace, так и в Amazon для меня. Если бы я был склонен, я мог бы также программировать с помощью API-интерфейсов, а затем напрямую обращаться к любому из тех сайтов, которые предоставляют мои учетные данные безопасности, чтобы делать что-то с моими хранимыми объектами.

Вот ссылка на объект и облако хранения праймер из сеанса, который я сделал в Голландии в прошлом году, который содержит несколько простых примеров объектов и доступа. http://storageio.com/DownloadItems/Nijkerk_Nov2012/SIO_IndustryTrends_CloudObjectStorage.pdf

Используя программную привязку, вы должны определить свои структуры данных или объекты в своей программе, а затем использовать API или вызовы для хранения, извлечения, списка данных, доступа к метаданных и т.д. Если есть определенная система хранения объектов, программное обеспечение или услугу, с которой вы хотите работать или должны знать, как программировать, перейдите на их сайт, и вы должны найти их информацию о SDK или API с примерами. С объектами, как только вы создаете свой начальный ковш или контейнер в службе или с продуктом/системой, вы просто создаете и храните дополнительные объекты по мере продвижения.

Вот ссылка в качестве примера для API/программирования AWS S3: http://docs.aws.amazon.com/AmazonS3/latest/API/IntroductionAPI.html

В теории говорят, что системы хранения объектов имеют неограниченное количество объектов или размер объекта, в действительности большинство систем, решений, программного обеспечения или услуг ограничены тем, что они либо тестировали, либо в настоящее время поддерживают, что может быть миллиардами объектов с размерами объектов 5GByte или больше. Обратите внимание на лимиты на конкретные услуги или продукты относительно того, что на самом деле проверено, поддерживается или что возможно в архитектуре или что реализовано на веб-сайте или PowerPoint.

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

Также в моей книге Cloud and Virtual Data Storage Networking (CRC Press), рекомендованной Intel, вы найдете дополнительную информацию о облачном и хранилище объектов.

Я буду добавлять дополнительные материалы на сайт www.objectstorage.us в ближайшее время.

Приветствия gs

Ответ 5

Хранилище объектов = Блокировка хранилища                 + Богатые метаданные                 - Иерархия файлов

Блок Storage использует файловую систему для указания места хранения содержимого. Хранилище объектов использует идентификатор, указывающий на контент и его контекст. Это мое понимание чтения Content-address vs. location-address

Блокировать хранилище нужна файловая система и структурирование, поэтому при больших файлах sytems приносит больше накладных расходов. В хранилище объектов много контекста файла и не требуется иерархия файлов. Объяснение на стр. 7 документ Dell ясно показывает это. Что меня беспокоило, было то, что по шкале самого жесткого диска это не объясняется. Я обнаружил, что сам жесткий диск всегда использует механизм хранения блоков (хотя это, похоже, меняется)  (хотя это, похоже, меняется на)

можно найти некоторые другие идеи здесь

Ответ 6

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

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

Существуют некоторые очень существенные различия между хранилищем файлов и хранилищем объектов.

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

С другой стороны, хранение объектов обычно представляет собой. RESTful API. Нет понятия файловой системы. Вместо этого приложение будет сохранять объект (файлы + дополнительные метаданные) в хранилище объектов через. API PUT и хранилище объектов будут сохранять объект где-то в системе. Платформа хранения объектов предоставит приложению уникальный ключ (аналогичный билету камердинера) для этого объекта, который приложение будет хранить в базе данных приложения. Если приложение хочет получить этот объект, все, что им нужно сделать, это предоставить ключ как часть API GET, и объект будет извлечен из хранилища объектов.

Надеюсь, теперь это ясно.

Это объясняет большую его часть; но вы спорили о метаданных. Следующее из того, что я читал за последние два дня, и поскольку это не было разрешено, я опубликую.

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

Базы данных, которые вы говорите? Ну, он не говорит о самом хранилище объектов, он говорит, что ваш http-сервис (php, webmail и т.д.) Имеет уникальный идентификатор в своей базе данных для ссылки на файл, который может иметь узнаваемое имя человека.

Метаданные, ну где же этот файл хранится вы говорите? Для чего нужны метаданные. Один файл разбивается на кучу мелких предметов и распространяется из географического местоположения, серверов и жестких дисков. Эти небольшие кусочки также содержат больше данных, они содержат информацию о четности для других частей данных или, возможно, даже полное дублирование.

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

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

Ответ 7

В большинстве компаний с объектно-ориентированными решениями используется сочетание хранилища блоков/файлов/объектов на основе требований производительности/стоимости.

С точки зрения использования:

В конечном итоге хранилище объектов было создано для обработки неструктурированных данных, которые растут взрывоопасно, гораздо быстрее, чем структурированные данные.

Например, если база данных представляет собой структурированные данные, неструктурированным будет слово doc или PDF.

Как вы можете искать 1 миллиард PDF файлов в файловой системе? (если он может даже сохранить это в первую очередь).

Как быстро можно было искать только метаданные из 1 миллиарда файлов?

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

Проблема заключается в том, что приложение должно быть переписано для использования методов доступа к объектам, а не иерархии файлов (что проще с точки зрения приложения). Это действительно изменение философии хранения данных и сохранение более действенной информации об этих данных с точки зрения управления, а также использования.

Быстрый пример может быть изображением MRI-сканирования. В Файловой системе у вас есть дата владельца/создания, но не больше. Если бы это был объект, вся информация, окружающая МРТ, могла быть сохранена вместе с ней в метаданных, таких как имя пациента, местоположение центра МРТ, запрашивающий доктор, страховой агент и т.д.

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

Например, вы не хотите ждать минут для открытия Word-документа, но вы можете подождать несколько минут для завершения процесса интеллектуального анализа данных/бизнес-аналитики.

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

Хранилище объектов - отличное решение для замены долгосрочных архивных методов, таких как лента.

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

Примечание. На более низком уровне доступ к хранилищу объектов происходит через RESTful API, который больше похож на веб-запрос, чем на доступ к файлу в конце пути.

Ответ 8

В этой ссылке объясняются различия между ними: http://www.dell.com/downloads/global/products/pvaul/en/object-storage-overview.pdf

Ответ 9

Я думаю, что в "Белой книге" довольно хорошо объясняется идея хранения объектов. Я не знаю какого-либо стандартного способа использования устройств хранения объектов (в смысле OSD SCSI) из пользовательского приложения.

Хранилище объектов используется в некоторых крупномасштабных продуктах хранения, таких как устройства хранения Panasas. Однако эти устройства затем экспортируют файловую систему конечному пользователю. ИМХО справедливо сказать, что идея T10 OSD никогда не набирала оборотов.

Связанные идеи с стандартом OSD можно найти в облачных системах хранения, таких как S3 и RADOS.

Ответ 10

На самом деле вы можете монтировать ведро/контейнер и обращаться к объектам или подпапкам (и их объектам) из Linux. Например, у меня установлена ​​s3fs на Ubuntu, что я установил точку монтирования в один из своих кодов S3 и смог выполнять обычные cp, ls и другие функции так же, как если бы это была другая файловая система. Ключом является получение программного обеспечения, из которого есть много, что позволяет отображать ведро/контейнер и представлять его как точку монтирования. Существуют также программные средства, которые позволяют вам получить доступ к S3 и другим ковшим/контейнерам через iSCSI в дополнение к NAS.

Ответ 11

Вот хорошая статья, которую стоит прочитать: https://cloudian.com/blog/object-storage-vs-file-storage/ процитированный из статьи:

Прежде всего, хранилище объектов преодолевает многие ограничения, с которыми сталкивается хранилище файлов. Думайте о хранилище файлов как о хранилище. Когда вы впервые кладете туда коробку с файлами, кажется, что у вас достаточно места. Но по мере роста потребностей в данных вы будете заполнять хранилище до полной емкости, прежде чем узнаете об этом. Хранилище объектов, с другой стороны, похоже на склад, только без крыши. Вы можете продолжать добавлять данные бесконечно - это предел. Если вы в основном извлекаете файлы меньшего размера или отдельные файлы, то хранилище файлов отличается высокой производительностью, особенно при относительно небольших объемах данных. Однако, как только вы начнете масштабировать, у вас может возникнуть вопрос: "Как мне найти нужный мне файл?" В этом случае вы можете думать о хранении объектов как о парковке камердинеров, в то время как хранение файлов больше похоже на самостоятельную парковку (да, другая аналогия, но потерпите меня!). Когда вы тянете свою машину на небольшой участок, вы точно знаете, где находится ваш автомобиль. Однако представьте, что эта партия была в тысячу раз больше - найти вашу машину будет сложнее, верно? Поскольку хранилище объектов имеет настраиваемые метаданные и все объекты живут в плоском адресном пространстве, это похоже на передачу ваших ключей камердинеру. Ваш автомобиль будет где-то храниться, и когда вам это понадобится, камердинер заберет автомобиль для вас. Может понадобиться немного больше времени, чтобы забрать вашу машину, но вам не нужно беспокоиться о том, чтобы бродить вокруг в поисках ее.