Разница между хранением объектов и хранением файлов
Может кто-нибудь объяснить, в чем разница между хранилищем объектов и хранилищем файлов?
Я читаю о Object Storage на вики, также я читаю http://www.dell.com/downloads/global/products/pvaul/en/object-storage-overview.pdf, также я читаю документы amazons(S3), openstack swift и т.д. Но может ли кто-нибудь дать мне пример, чтобы лучше понять?
Разница лишь в том, что для объектов "хранилище объектов" мы добавляем больше метаданных?
Например, как сохранить изображение как объект, используя некоторый язык программирования (например, python)?
Благодарю.
10 ответов
IMO, Хранение объектов не имеет ничего общего с масштабированием, потому что кто-то может создать ФС, которая способна хранить огромное количество файлов, даже в одном каталоге.
Это также не о методах доступа. HTTP-доступ к данным в файловых системах был доступен во многих известных системах NAS.
Хранение / доступ по OID - это способ обработки данных, не заботясь о присвоении им имен. Это можно сделать и с файлами. Я считаю, что есть расширение протокола NFS, которое позволяет это.
Я хотел бы проверить это: объектное хранилище - это (новый / другой) "объектно-ориентированный" способ мышления данных, их доступа и управления.
Подумайте об этих моментах:
Какие снимки сегодня? Они являются точными копиями тома. При создании снимка все файлы тома также привязываются. Нравится им всем это или нет, нужно ли им всем или нет. Много места может быть использовано (потрачено впустую?) Для полного снимка тома, в то время как для захвата нужно было всего несколько файлов.
В системе хранения объектов вы редко будете видеть моментальные снимки томов, объекты будут сниматься, возможно, автоматически. Это версия объекта. Все объекты не должны быть версионными, каждый отдельный объект может определить, версионирован ли он.
Как файлы / тома защищены от катастрофы? Обычно в настройках аварийного восстановления (DR) целые тома / наборы томов настраиваются для репликации на сайт аварийного восстановления. Опять же, это не беспокоит, нужно ли копировать отдельные файлы или нет. Единицей защиты от стихийных бедствий является объем. Файлы плотвы.
В системе хранения объектов DR не ориентирован на объем. Метаданные объекта могут решить, сколько копий должно существовать и где (географические местоположения / домены разломов).
Аналогично для других функций:
Многоуровневое размещение - объекты, размещенные в уровнях / классах хранилища на основе его метаданных, независимых от других не связанных между собой объектов.
Жизнь - объекты перемещаются между уровнями, меняют количество копий и т. Д. По отдельности, а не как группа.
Аутентификация - при необходимости отдельные объекты могут проходить аутентификацию из разных доменов аутентификации.
Как видите, изменение мышления состоит в том, что в хранилище объектов все связано с объектом.
Сравните это с традиционным способом мышления, управления и доступа к более крупным контейнерам, таким как тома (содержащие файлы), а не к объектному хранилищу.
Приведенные выше функции и их объектно-ориентированное соответствие хорошо соответствуют требованиям неструктурированных данных и, следовательно, интересам.
Если система хранения ориентирована на объект (или файл), а не на объем в своем мышлении (независимо от протокола доступа или масштаба), то это система хранения объектов.
Раскрытие - я работаю на поставщика (NetApp), который разрабатывает и продает как большие файловые системы, так и платформы хранения объектов, я постараюсь сделать это как можно более независимым от реализации, но мои когнитивные предрассудки могут бессознательно влиять на мой ответ.
Существует много различий как с точки зрения доступа, так и с точки зрения программирования и реализации, однако, учитывая, что это, скорее всего, будут читать в первую очередь программисты, а не специалисты по инфраструктуре или хранилищам, я сосредоточусь на этом аспекте здесь.
Основное отличие от внешней / программной точки зрения состоит в том, что объект в хранилище объектов создается, удаляется или обновляется как единое целое, вы не можете добавлять данные к объекту и не можете обновить часть объекта. объект "на месте", однако вы можете заменить его, сохраняя при этом тот же идентификатор объекта. Создание, чтение, обновление и удаление объектов обычно выполняется с помощью относительно простых API-интерфейсов, которые почти всегда основаны на REST или REST и поощряют мышление, что хранилище является программируемым ресурсом или, возможно, многопользовательской удаленной службой. Хотя большинство хранилищ объектов известно о поддержке чтения байтового диапазона внутри объекта, в целом хранилища объектов изначально были предназначены для работы с целыми объектами. Хорошими примерами 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 с помощью удаленных вызовов процедур, а VSAN VMware хранит свои данные в чем-то, что они называют "хранилищем объектов", что позволяет с высокой скоростью обновлять образы виртуальных машин на месте.
Есть несколько фундаментальных отличий между Хранилищем Файлов и Хранилищем Объектов.
Файловое хранилище представляет собой иерархию файловой системы с каталогами, подкаталогами и файлами. Это здорово и прекрасно работает, когда количество файлов не очень велико. Это также хорошо работает, когда вы точно знаете, где хранятся ваши файлы.
Хранение объектов, с другой стороны, обычно представляет себя через. RESTful API. Нет понятия файловой системы. Вместо этого приложение сохранит объект (файлы + дополнительные метаданные) в хранилище объектов через. API PUT и хранилище объектов сохранят объект где-нибудь в системе. Платформа хранения объектов предоставит приложению уникальный ключ (аналог камерного билета) для этого объекта, который приложение будет хранить в базе данных приложения. Если приложение хотело бы получить этот объект, все, что ему нужно было бы сделать, это дать ключ как часть GET API, и объект был бы извлечен хранилищем объекта.
Надеюсь, теперь это ясно.
Простой ответ заключается в том, что системы хранения или службы, к которым осуществляется доступ к объектам, используют API и другие методы доступа к объектам для хранения, извлечения и поиска данных, в отличие от традиционных файлов или NAS. Например, с файлом или NAS вы получаете доступ к хранилищу, используя NFS (сетевая файловая система) или CIFS (например, общий доступ к файлам Windows), также называемый SMB или SAMBA, где у файла есть имя / дескриптор со связанными метаданными, определенными файловой системой.
Метаданные включают в себя информацию о создании, доступе, изменении и других датах, разрешениях, безопасности, типе приложения или файла или других атрибутах. Файлы ограничены файловой системой с точки зрения их размера, а также количества файлов на файловую систему. Аналогично, файловые системы ограничены их общим или совокупным размером с точки зрения емкости пространства и количества файлов в файловой системе.
Доступ к объектам отличается тем, что, хотя файловый интерфейс или интерфейс NAS, шлюзы или плагины доступны для многих решений или служб, первичный доступ осуществляется через API, где объект может иметь произвольный размер (до максимума объектной системы) вдоль с метаданными переменного размера (зависит от реализации системы объекта / сервиса). В большинстве систем / служб хранения объектов вы можете указывать в любом месте от нескольких килобайт пользовательских метаданных или гигабайт. Для чего вы используете GB метаданных? Как насчет в дополнение к обычной информации, добавление дополнительных данных для политик, управления, где находятся другие копии, миниатюры или небольшие предварительные просмотры видео, аудио и т. Д.
Некоторые примеры API или интерфейсов доступа к объектам включают простые сервисы хранения (S3) Amazon Web Services (AWS) или другие сервисы на основе HTTP и REST, SNIA CDMI. Различные решения также будут поддерживать доступ IOS (например, iphone/ipad), SOAP, Torrent, WebDav, JSON, XAM и другие, плюс NFS/CIFS. Кроме того, многие из систем или сервисов хранения объектов поддерживают программные привязки для python. API-интерфейсы позволяют вам по существу открыть поток, а затем получить или поместить, перечислить и другие функции, поддерживаемые API/ системой, чтобы определить, как вы будете его использовать.
Например, я использую файлы Rackspace Cloud и Amazon S3 (в дополнение к EBS и Glacier) для резервного копирования, хранения и архивирования данных. Я могу получить доступ к объектам, хранящимся через веб-браузер или инструменты, включая диск Jungle (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
В теории речь идет о системах хранения объектов, имеющих неограниченное количество объектов или размер объекта, в действительности большинство систем, решений, программного обеспечения или услуг ограничены тем, что они либо протестировали, либо поддерживают в настоящее время, что может составлять миллиарды объектов с объекты размером от 5 ГБ или больше. Обратите внимание на ограничения на конкретные услуги или продукты в отношении того, что на самом деле тестируется, поддерживается и что архитектурно возможно или что реализовано на webex или powerpoint.
Опять же, сама услуга и продукт / услуга / программное обеспечение зависят от количества объектов, размера объектов, размера метаданных и количества данных, которые можно перемещать / выводить через их API. Однако, как правило, можно предположить, что хранилище объектов может быть гораздо более масштабируемым (в зависимости от реализации), чем файловые системы (без использования глобального пространства имен, объединения, виртуализации файлов или других методов).
Также в моей книге "Облачные и виртуальные сети хранения данных (CRC Press)", которая называется Intel Recommended Reading, вы найдете больше информации о облачном и объектном хранилище.
Я скоро добавлю больше связанных материалов на www.objectstorage.us.
Ура гс
Хранилище объектов = блочное хранилище + расширенные метаданные - иерархия файлов
Блочное хранилище использует файловую систему для указания места хранения контента. Хранилище объектов использует идентификатор для указания содержимого и его контекста. Это мое понимание чтения Контент-адресованного и адресно-адресного
Блочное хранилище нуждается в файловой системе и структурировании, поэтому с большими файлами система требует больше ресурсов. Хранилище объектов имеет много контекста о файле и не нуждается в файловой иерархии. Объяснение на странице 7 статьи Dell ясно показывает это... Что меня беспокоило, так это то, что в масштабе самого жесткого диска это не объясняется. Я обнаружил, что сам жесткий диск всегда использует механизм хранения блоков (хотя, похоже, он меняется на) (хотя, похоже, он меняется на)
некоторые другие идеи можно найти здесь
О, если бы я мог проголосовать за некоторые ответы и проголосовать за других со счетом.
Тот, кто набрал наибольшее количество голосов, на момент написания этой статьи даже не объясняет различия.
Есть несколько фундаментальных отличий между Хранилищем Файлов и Хранилищем Объектов.
Файловое хранилище представляет собой иерархию файловой системы с каталогами, подкаталогами и файлами. Это здорово и прекрасно работает, когда количество файлов не очень велико. Это также хорошо работает, когда вы точно знаете, где хранятся ваши файлы.
Хранение объектов, с другой стороны, обычно представляет себя через. RESTful API. Нет понятия файловой системы. Вместо этого приложение сохранит объект (файлы + дополнительные метаданные) в хранилище объектов через. API PUT и хранилище объектов сохранят объект где-нибудь в системе. Платформа хранения объектов предоставит приложению уникальный ключ (аналог камерного билета) для этого объекта, который приложение будет хранить в базе данных приложения. Если приложение хотело бы получить этот объект, все, что ему нужно было бы сделать, это дать ключ как часть GET API, и объект был бы извлечен хранилищем объекта.
Надеюсь, теперь это ясно.
Это объяснило большую часть этого; но вы спорили о метаданных. Следующее - из того, что я читал последние два дня, и, поскольку это не решено, я опубликую.
Хранилище объектов не имеет никакого смысла в папках или какой-либо организационной структуре, которая облегчает организацию человека. Хранилище файлов, конечно же, имеет все те папки, которые позволяют человеку легко организовывать и перетасовывать... В серверной среде с астрономическим количеством файлов в масштабе, папки - просто пустая трата пространства и время.
Базы данных вы говорите? Ну, он не говорит о самом хранилище объектов, он говорит, что ваша служба http (php, web-почта и т. Д.) Имеет уникальный идентификатор в своей базе данных для ссылки на файл, который может иметь узнаваемое человеком имя.
Метаданные, ну где хранится этот файл, говорите? Вот для чего нужны метаданные. Ваш отдельный файл разделен на кучу маленьких кусочков и распределен по географическому расположению, серверам и жестким дискам. Эти небольшие фрагменты также содержат больше данных, они содержат информацию о четности для других фрагментов данных или, возможно, даже полное дублирование.
Метаданные используются для определения местоположения каждого фрагмента данных для этого файла в разных географических точках, центрах обработки данных, на серверах и жестких дисках, а также для восстановления любых разрушенных фрагментов после сбоя оборудования. Это делает это автоматически. Это даже плавно переместит эти части, чтобы иметь лучшее распространение. Он даже воссоздаст кусок, который ушел, и сохранит его на новом хорошем жестком диске.
Это может быть простое объяснение; но я думаю, что это может помочь вам лучше понять. Я считаю, что хранилище файлов может делать то же самое с метаданными; но файловое хранилище - это хранилище, которое вы можете организовать как человек (папки, иерархия и т. д.), тогда как хранилище объектов не имеет иерархии, папок, просто плоский контейнер хранения.
На самом деле вы можете смонтировать ведро / контейнер и получить доступ к объектам или подпапкам (и их объектам) из Linux. Например, у меня в Ubuntu установлена программа s3fs, в которой я настроил точку монтирования одного из моих блоков S3 и могу выполнять обычные функции cp, ls и другие, как если бы это была другая файловая система. Ключевым моментом является получение программного инструмента, которого существует множество, которое позволяет вам отобразить контейнер / контейнер и представить его как точку монтирования. Есть также программные инструменты, которые позволяют вам получить доступ к S3 и другим контейнерам / контейнерам через iSCSI в дополнение к NAS.
Большинство компаний с объектно-ориентированными решениями выбирают комбинацию хранилищ блоков / файлов / объектов на основе требований производительности / стоимости.
С точки зрения варианта использования:
В конечном счете, объектное хранилище было создано для обработки неструктурированных данных, которые стремительно растут, гораздо быстрее, чем структурированные данные.
Например, если база данных представляет собой структурированные данные, неструктурированным будет слово doc или PDF.
Как вы ищете 1 миллиард PDF-файлов в файловой системе? (если бы это могло даже спасти так много во-первых).
Как быстро вы могли бы искать только метаданные 1 миллиарда файлов?
Хранилище объектов в настоящее время используется больше для долгосрочного или архивного, дешевого и глубокого хранения, которое отслеживает более подробную информацию о том, что это за данные. Эти метаданные становятся очень мощными при поиске или анализе очень больших наборов данных. Иногда вы можете получить то, что вам нужно, из метаданных, даже не обращаясь к самим данным. Решения для хранения объектов обычно могут автоматически реплицироваться с помощью встроенного географического переключения при отказе.
Проблема в том, что приложение должно быть переписано для использования методов доступа к объектам, а не файловой иерархии (что проще с точки зрения разработчика приложений). Это действительно изменение в философии хранения данных и хранения более действенной информации об этих данных с точки зрения управления и использования.
Быстрый пример может быть изображение сканирования МРТ. В Файловой системе у вас есть дата владельца / создания, но не более того. Если бы это был объект, вся информация, связанная с МРТ, могла бы храниться вместе с ним в метаданных, таких как имя пациента, местоположение центра МРТ, запрашивающий доктор, страховой перевозчик и т. Д.
Блок / файл лучше подходят для локального доступа или OTLP, где производительность важнее, чем сохранение и стоимость.
Например, вы не хотели бы ждать минуты, пока откроется документ Word, но вы могли бы подождать несколько минут до завершения процесса интеллектуального анализа данных / бизнес-аналитики.
Другим примером может быть юридический поиск, где вы должны искать все от 5 лет назад до настоящего времени. С политиками хранения для уменьшения активного набора данных и стоимости, как бы вы это сделали, не восстанавливаясь с ленты?
Хранение объектов - отличное решение для замены долгосрочных архивных методов, таких как лента.
Настройка репликации и отработки отказа для блоков и файлов может оказаться очень дорогой на предприятии и обычно требует очень дорогого программного обеспечения и услуг.
Примечание. На более низком уровне доступ к хранилищу объектов происходит через API RESTful, который больше похож на веб-запрос, чем на доступ к файлу в конце пути.
Вот хорошая статья, которую стоит прочитать: https://cloudian.com/blog/object-storage-vs-file-storage/ процитированный из статьи:
Прежде всего, хранилище объектов преодолевает многие ограничения, с которыми сталкивается хранилище файлов. Думайте о хранилище файлов как о хранилище. Когда вы впервые кладете туда коробку с файлами, кажется, что у вас достаточно места. Но по мере роста потребностей в данных вы будете заполнять хранилище до полной емкости, прежде чем узнаете об этом. Хранилище объектов, с другой стороны, похоже на склад, только без крыши. Вы можете продолжать добавлять данные бесконечно - небо это предел. Если вы в основном извлекаете файлы меньшего размера или отдельные файлы, то объем файлового хранилища зависит от производительности, особенно при относительно небольших объемах данных. Однако, как только вы начнете масштабировать, вы можете задаться вопросом: "Как мне найти нужный мне файл?". В этом случае вы можете рассматривать хранилище объектов как парковку камердинера, тогда как хранение файлов больше похоже на самостоятельную парковку (да, другая аналогия, но потерпите меня!). Когда вы тянете свою машину на небольшой участок, вы точно знаете, где находится ваш автомобиль. Однако представьте, что эта партия была в тысячу раз больше - найти вашу машину будет сложнее, верно? Поскольку хранилище объектов имеет настраиваемые метаданные и все объекты живут в плоском адресном пространстве, это похоже на передачу ваших ключей камердинеру. Ваш автомобиль будет где-то храниться, и когда вам это понадобится, камердинер заберет автомобиль для вас. Может потребоваться немного больше времени, чтобы забрать вашу машину, но вам не нужно беспокоиться о том, чтобы бродить вокруг и искать ее.
Эта ссылка объясняет различия между ними: http://www.dell.com/downloads/global/products/pvaul/en/object-storage-overview.pdf
Я думаю, что в Белой книге хорошо объясняется идея хранения объектов. Я не знаю ни одного стандартного способа использования устройств хранения объектов (в смысле SCSI OSD) из пользовательского приложения.
Хранение объектов используется в некоторых крупномасштабных продуктах хранения, таких как устройства хранения Panasas. Однако эти устройства затем экспортируют файловую систему конечному пользователю. ИМХО справедливо сказать, что идея экранного меню T10 никогда не набирала обороты.
Связанные идеи со стандартом OSD можно найти в облачных системах хранения, таких как S3 и RADOS.