Объектное хранилище (также известное как объектно-ориентированное хранилище [1] или хранилище BLOB-объектов ) — это подход к хранению компьютерных данных , который управляет данными как «BLOB-объектами» или «объектами», в отличие от других архитектур хранения, таких как файловые системы , которые управляют данными как иерархией файлов, и блочное хранилище , которое управляет данными как блоками в секторах и дорожках. [2] Каждый объект обычно связан с переменным объемом метаданных и глобально уникальным идентификатором . Объектное хранилище может быть реализовано на нескольких уровнях, включая уровень устройства (устройство хранения объектов), системный уровень и уровень интерфейса. В каждом случае объектное хранилище стремится обеспечить возможности, не рассматриваемые другими архитектурами хранения, такие как интерфейсы, которые напрямую программируются приложением, пространство имен, которое может охватывать несколько экземпляров физического оборудования, и функции управления данными, такие как репликация данных и распределение данных на уровне детализации объектов.
Системы хранения объектов позволяют хранить огромные объемы неструктурированных данных , в которых данные записываются один раз и считываются один раз (или много раз). [3] Хранилище объектов используется для таких целей, как хранение объектов, таких как видео и фотографии на Facebook , песни на Spotify или файлы в онлайн-сервисах совместной работы, таких как Dropbox . [4] Одним из ограничений хранилища объектов является то, что оно не предназначено для транзакционных данных , поскольку хранилище объектов не было разработано для замены доступа к файлам NAS и их совместного использования; оно не поддерживает механизмы блокировки и совместного использования, необходимые для поддержания единой, точно обновленной версии файла. [3]
Джим Старки придумал термин « blob » [ когда? ] , работая в Digital Equipment Corporation, для обозначения непрозрачных сущностей данных. Терминология была принята для Rdb/VMS . «Blob» часто юмористически объясняется как сокращение от «двоичный большой объект». По словам Старки, этот бэкроним возник, когда Терри Маккивер, работая в отделе маркетинга в Apollo Computer, почувствовал, что термин должен быть сокращением. Маккивер начал использовать расширение «Basic Large Object». Позже это было затмено ретроспективным объяснением blob как «двоичные большие объекты». По словам Старки, «Blob ничего не стоит». Отвергнув аббревиатуру, он объяснил свою мотивацию, стоящую за этим созданием, сказав: «A blob — это то, что съело Цинциннатти [ так в оригинале ], Кливленд или что-то еще», имея в виду научно-фантастический фильм 1958 года «The Blob» . [5]
В 1995 году исследование под руководством Гарта Гибсона по защищенным сетевым дискам впервые выдвинуло концепцию разделения менее распространенных операций, таких как манипуляции с пространством имен, от обычных операций, таких как чтение и запись, для оптимизации производительности и масштабирования обоих. [6] В том же году была основана бельгийская компания FilePool для создания основы для функций архивирования. Хранилище объектов было предложено в лаборатории Гибсона в Университете Карнеги-Меллона в качестве исследовательского проекта в 1996 году. [7] Другой ключевой концепцией было абстрагирование записи и чтения данных в более гибкие контейнеры данных (объекты). Тонкозернистый контроль доступа через архитектуру хранения объектов [8] был далее описан одним из членов команды NASD, Говардом Гобиоффом, который позже стал одним из изобретателей файловой системы Google . [9]
Другие связанные работы включают проект файловой системы Coda в Университете Карнеги-Меллона , который начался в 1987 году и породил файловую систему Lustre . [10] Также существует проект OceanStore в Калифорнийском университете в Беркли, [11] который начался в 1999 году [12] и проект Logistical Networking в Университете Теннесси в Ноксвилле, который начался в 1998 году. [13] В 1999 году Гибсон основал Panasas для коммерциализации концепций, разработанных командой NASD.
Seagate Technology сыграла центральную роль в развитии объектного хранилища. Согласно Ассоциации индустрии сетевых хранилищ (SNIA), «Объектное хранилище возникло в конце 1990-х: спецификации Seagate от 1999 года представили некоторые из первых команд и то, как операционная система эффективно отстранилась от потребления хранилища». [14]
Предварительная версия «OBJECT BASED STORAGE DEVICES Command Set Proposal» от 25.10.1999 была представлена Seagate под редакцией Дэйва Андерсона из Seagate и была продуктом работы Национального консорциума индустрии хранения данных (NSIC), включая вклад Университета Карнеги-Меллона , Seagate, IBM, Quantum и StorageTek. [15] Эта статья была предложена INCITS T-10 ( Международный комитет по стандартам информационных технологий ) с целью формирования комитета и разработки спецификации на основе протокола интерфейса SCSI. В ней объекты определялись как абстрагированные данные с уникальными идентификаторами и метаданными, как объекты связаны с файловыми системами, а также многими другими инновационными концепциями. Андерсон представил многие из этих идей на конференции SNIA в октябре 1999 года. В презентации было раскрыто Соглашение об интеллектуальной собственности, которое было подписано в феврале 1997 года между первоначальными соавторами (Seagate представляли Андерсон и Крис Малакапалли) и охватывало преимущества объектного хранения, масштабируемых вычислений, независимости платформы и управления хранением. [16]
Одним из принципов проектирования объектного хранилища является абстрагирование некоторых нижних уровней хранилища от администраторов и приложений. Таким образом, данные раскрываются и управляются как объекты, а не блоки или (исключительно) файлы. Объекты содержат дополнительные описательные свойства, которые могут использоваться для лучшей индексации или управления. Администраторам не нужно выполнять функции хранения нижнего уровня, такие как построение и управление логическими томами для использования емкости диска или настройка уровней RAID для решения проблемы отказа диска.
Хранилище объектов также позволяет адресовать и идентифицировать отдельные объекты не только по имени файла и пути к файлу. Хранилище объектов добавляет уникальный идентификатор в пределах контейнера или по всей системе для поддержки гораздо больших пространств имен и устранения конфликтов имен.
Объектное хранилище явно отделяет метаданные файлов от данных для поддержки дополнительных возможностей. В отличие от фиксированных метаданных в файловых системах (имя файла, дата создания, тип и т. д.), объектное хранилище обеспечивает полнофункциональные, пользовательские, объектные метаданные для того, чтобы:
Кроме того, в некоторых реализациях объектно-ориентированных файловых систем:
Объектно-ориентированные устройства хранения данных ( OSD ), а также некоторые программные реализации (например, DataCore Swarm) управляют метаданными и данными на уровне устройства хранения данных:
Объектное хранилище предоставляет программные интерфейсы, позволяющие приложениям манипулировать данными. На базовом уровне это включает функции создания, чтения, обновления и удаления ( CRUD ) для основных операций чтения, записи и удаления. Некоторые реализации объектного хранилища идут дальше, поддерживая дополнительные функции, такие как управление версиями объектов/файлов , репликация объектов, управление жизненным циклом и перемещение объектов между различными уровнями и типами хранилищ. Большинство реализаций API основаны на REST , что позволяет использовать множество стандартных HTTP- вызовов.
Подавляющее большинство облачных хранилищ, доступных на рынке, используют архитектуру объектного хранилища. Некоторые примечательные примеры — Amazon Web Services S3 , дебютировавший в марте 2006 года, Microsoft Azure Blob Storage, Rackspace Cloud Files (чей код был передан в 2010 году проекту Openstack и выпущен как OpenStack Swift ), и Google Cloud Storage, выпущенный в мае 2010 года.
Некоторые распределенные файловые системы используют объектно-ориентированную архитектуру, где метаданные файлов хранятся на серверах метаданных, а данные файлов хранятся на серверах хранения объектов. Клиентское программное обеспечение файловой системы взаимодействует с отдельными серверами и абстрагирует их, чтобы представить полную файловую систему пользователям и приложениям.
Некоторые ранние воплощения объектного хранилища использовались для архивирования, поскольку реализации были оптимизированы для таких служб данных, как неизменяемость, а не производительность. EMC Centera и Hitachi HCP (ранее известный как HCAP) — два часто упоминаемых продукта объектного хранилища для архивирования. Другой пример — Quantum ActiveScale Object Storage Platform.
Около 2008 года на рынке появилось больше систем объектного хранения общего назначения. Привлеченные невероятным ростом «закрепленных» систем хранения в веб-приложениях, таких как Yahoo Mail, и ранним успехом облачного хранения, системы объектного хранения обещали масштаб и возможности облачного хранения с возможностью развертывания системы на предприятии или у начинающего поставщика услуг облачного хранения.
Некоторые системы хранения объектов поддерживают унифицированное хранилище файлов и объектов, что позволяет клиентам хранить объекты в системе хранения, в то время как другие клиенты одновременно хранят файлы в той же системе хранения. [17] Другие поставщики в области гибридного облачного хранения используют шлюзы облачного хранения для предоставления уровня доступа к файлам поверх объектного хранилища, реализуя протоколы доступа к файлам, такие как SMB и NFS.
Некоторые крупные интернет-компании разработали собственное программное обеспечение, когда продукты для хранения объектов не были коммерчески доступны или варианты использования были очень специфичными. Facebook, как известно, изобрел собственное программное обеспечение для хранения объектов под кодовым названием Haystack, чтобы эффективно решать свои особые потребности в управлении фотографиями в больших масштабах. [18]
Хранение объектов на уровне протокола и устройства было предложено 20 лет назад [ неоднозначно ] и одобрено для набора команд SCSI почти 10 лет назад [ неоднозначно ] как «Команды устройств хранения данных на основе объектов» (OSD), [19] однако оно не было введено в эксплуатацию до разработки платформы Seagate Kinetic Open Storage. [20] [21] Набор команд SCSI для устройств хранения объектов был разработан рабочей группой SNIA для комитета T10 Международного комитета по стандартам информационных технологий (INCITS). [22] T10 отвечает за все стандарты SCSI.
Один из первых продуктов для хранения объектов, Lustre , используется в 70% из 100 лучших суперкомпьютеров и примерно в 50% из 500 лучших . [23] По состоянию на 16 июня 2013 года сюда входят 7 из 10 лучших, включая четвертую по скорости систему в списке — китайскую Tianhe-2 и седьмую по скорости — суперкомпьютер Titan в Национальной лаборатории Оук-Ридж . [24]
Системы хранения объектов получили хорошее распространение в начале 2000-х годов в качестве архивной платформы, особенно в свете законов о соответствии, таких как закон Сарбейнса-Оксли . После пяти лет на рынке продукт Centera от EMC заявил о более чем 3500 клиентах и 150 петабайтах , поставленных к 2007 году. [25] Продукт HCP от Hitachi также заявляет о многих клиентах масштаба петабайт . [26] Более новые системы хранения объектов также получили некоторую популярность, особенно вокруг очень больших пользовательских приложений, таких как сайт аукциона eBay, где EMC Atmos используется для управления более чем 500 миллионами объектов в день. [27] По данным EMC на 3 марта 2014 года, было продано более 1,5 эксабайта хранилища Atmos. [28] 1 июля 2014 года Национальная лаборатория Лос-Аламоса выбрала Scality RING в качестве основы для среды хранения объемом 500 петабайт, которая станет одной из крупнейших в истории. [29]
Системы хранения «захваченных» объектов, такие как Haystack от Facebook, впечатляюще масштабировались. В апреле 2009 года Haystack управлял 60 миллиардами фотографий и 1,5 петабайтами хранилища, добавляя 220 миллионов фотографий и 25 терабайт в неделю. [18] Facebook недавно заявил, что они добавляют 350 миллионов фотографий в день и хранят 240 миллиардов фотографий. [30] Это может составить до 357 петабайт. [31]
Облачное хранилище стало повсеместным, поскольку многие новые веб- и мобильные приложения выбирают его в качестве обычного способа хранения двоичных данных . [32] Как хранилище для многих популярных приложений, таких как Smugmug и Dropbox , Amazon S3 вырос до огромных масштабов, сославшись на более чем 2 триллиона хранимых объектов в апреле 2013 года. [33] Два месяца спустя Microsoft заявила, что они хранят еще больше объектов в Azure — 8,5 триллиона. [34] К апрелю 2014 года Azure заявила о более чем 20 триллионах хранимых объектов. [35] Windows Azure Storage управляет Blob-объектами (пользовательскими файлами), таблицами (структурированным хранилищем) и очередями (доставкой сообщений) и учитывает их все как объекты. [36]
IDC начала ежегодно оценивать рынок объектно-ориентированных хранилищ, используя свою методологию MarketScape. IDC описывает MarketScape как: «...количественную и качественную оценку характеристик, которые определяют текущий и будущий успех поставщика на указанном рынке или сегменте рынка и дают меру его восхождения, чтобы стать Лидером или сохранить лидерство. Оценки IDC MarketScape особенно полезны на развивающихся рынках, которые часто фрагментированы, имеют несколько игроков и не имеют явных лидеров». [37]
В 2019 году IDC оценила Dell EMC , Hitachi Data Systems , IBM , NetApp и Scality как лидеров.
В первой версии стандарта OSD [38] объекты указаны с 64-битным идентификатором раздела и 64-битным идентификатором объекта. Разделы создаются и удаляются в пределах OSD, а объекты создаются и удаляются в пределах разделов. Нет фиксированных размеров, связанных с разделами или объектами; им разрешено расти в соответствии с ограничениями физического размера устройства или ограничениями логической квоты на разделе.
Расширяемый набор атрибутов описывает объекты. Некоторые атрибуты реализуются непосредственно OSD, например, количество байтов в объекте и время изменения объекта. Существует специальный атрибут тега политики, который является частью механизма безопасности. Другие атрибуты не интерпретируются OSD. Они устанавливаются для объектов системами хранения более высокого уровня, которые используют OSD для постоянного хранения. Например, атрибуты могут использоваться для классификации объектов или для фиксации связей между различными объектами, хранящимися в различных OSD.
Команда list возвращает список идентификаторов для объектов в разделе, опционально отфильтрованных по совпадениям с их значениями атрибутов. Команда list также может возвращать выбранные атрибуты перечисленных объектов.
Команды чтения и записи можно комбинировать или совмещать с командами получения и установки атрибутов. Эта возможность сокращает количество раз, когда высокоуровневая система хранения должна пересекать интерфейс с OSD, что может повысить общую эффективность.
Второе поколение набора команд SCSI, «Устройства хранения на основе объектов - 2» (OSD-2), добавило поддержку снимков, коллекций объектов и улучшило обработку ошибок. [39]
Снимок — это моментальная копия всех объектов в разделе в новый раздел. OSD может реализовать эффективное по пространству копирование с использованием методов копирования при записи , чтобы два раздела совместно использовали объекты, которые не изменялись между снимками, или OSD может физически скопировать данные в новый раздел. Стандарт определяет клоны, которые доступны для записи, и снимки, которые доступны только для чтения.
Коллекция — это особый вид объекта, который содержит идентификаторы других объектов. Существуют операции по добавлению и удалению из коллекций, а также операции по получению или установке атрибутов для всех объектов в коллекции. Коллекции также используются для отчетов об ошибках. Если объект поврежден из-за возникновения дефекта носителя (например, плохого места на диске) или программной ошибки в реализации OSD, его идентификатор помещается в специальную коллекцию ошибок. Система хранения более высокого уровня, использующая OSD, может запросить эту коллекцию и предпринять корректирующие действия по мере необходимости.
Граница между хранилищем объектов и хранилищем пар «ключ-значение» размыта, и хранилища пар «ключ-значение» иногда условно называют хранилищами объектов.
Традиционный интерфейс блочного хранилища использует ряд блоков фиксированного размера, которые нумеруются, начиная с 0. Данные должны иметь именно такой фиксированный размер и могут храниться в определенном блоке, который идентифицируется его логическим номером блока (LBN). Позже можно извлечь этот блок данных, указав его уникальный LBN.
В хранилище ключей и значений данные идентифицируются ключом, а не LBN. Ключом может быть «cat», «olive» или «42». Это может быть произвольная последовательность байтов произвольной длины. Данные (называемые значением в этом жаргоне) не обязательно должны быть фиксированного размера и также могут быть произвольной последовательностью байтов произвольной длины. Данные сохраняются путем представления ключа и данных (значения) в хранилище данных, а затем могут быть извлечены путем представления ключа. Эта концепция наблюдается в языках программирования. Python называет их словарями, Perl называет их хэшами, Java и C++ называют их картами и т. д. Некоторые хранилища данных также реализуют хранилища ключей и значений, такие как Memcached, Redis и CouchDB.
Объектные хранилища похожи на хранилища типа «ключ-значение» в двух отношениях. Во-первых, идентификатор объекта или URL (эквивалент ключа) может быть произвольной строкой. [40] Во-вторых, данные могут иметь произвольный размер.
Однако есть несколько ключевых различий между хранилищами «ключ-значение» и объектными хранилищами. Во-первых, объектные хранилища также позволяют связать ограниченный набор атрибутов (метаданные) с каждым фрагментом данных. Комбинация ключа, значения и набора атрибутов называется объектом. Во-вторых, объектные хранилища оптимизированы для больших объемов данных (сотни мегабайт или даже гигабайт), тогда как для хранилищ «ключ-значение» ожидается, что значение будет относительно небольшим (килобайты). Наконец, объектные хранилища обычно предлагают более слабые гарантии согласованности, такие как конечная согласованность , тогда как хранилища «ключ-значение» предлагают сильную согласованность .
Объектное хранилище может хорошо работать для неструктурированных данных, в которых данные записываются один раз и считываются один раз (или много раз). Статический онлайн-контент, резервные копии данных, архивы изображений, видео, фотографии и музыкальные файлы могут храниться как объекты.