Приветствую любителей облачных вычислений.
Предлагаю посмотреть на сравнение сервисов Windows Azure Blob Storage и Google Cloud Storage (при этом автор не забывает упомянуть и про Amazon AS3).
Я подумал, что неплохо было бы написать статью по сравнению хранилища Google App Engine и Windows Azure. В этой статье мы сравним Windows Azure Blob Storage и Google Cloud Storage.
Первая часть цикла — Сравнение Windows Azure Table Storage и Amazon DynamoDB
Вторая часть цикла — Сравнение Windows Azure Blob Storage и Amazon Simple Storage Service (S3) — ч. I
Третья часть цикла — Сравнение Windows Azure Blob Storage и Amazon Simple Storage Service (S3)–Часть II, резюме
Аббревиатуры: Windows Azure Blob Storage - WABS и Google Cloud Storage – GCS, Amazon S3 – AS3.
Концептуально WABS и GCS предоставляют аналогичную функциональность – проще говоря, обе системы представляют из себя облачные файловые системы, позволяющие хранить большие объемы неструктурированных данных (обычно в виде файлов).
Обе системы предоставляют REST API для работы с файлами и папками и другими библиотеками высокоуровневых языков, которые обычно являются врапперами REST API. Каждый релиз API имеет свою версию, в WABS она имеет значение даты, в GCS – цифры. На момент написания статьи версия WABS была равна 2011-08-18, GCS — version 2.0.
Похожая функциональность в двух системах:
Перед тем, как мы поговорим подробнее об этих двух сервисах, я считаю важным пояснить некоторые концепции. Если вы знакомы с базовыми концепциями WABS и GCS, можете пропустить этот раздел.
Контейнеры блобов и корзины: Если эти сервисы – файловые системы в облаке, рассматривайте контейнер блобов WABS и корзину GCS как папку или директорию. В аккаунте хранилища WABS или аккаунте GCS вы можете иметь ноль и более контейнеров блобов и корзин, которые могут содержать блобы или объекты соответственно.
Комментарии:
Блобы и объекты: Блобы WABS и объекты GCS – это файлы в вашей облачной файловой системе, расположенные в контейнерах блобов и корзинах.
Комментарии:
Двумя наиболее важными функциями является загрузка и скачивание, давайте обсудим сначала их, потом сравним остальные функции.
Давайте поговорим о загрузке блобов и объектов в контейнеры и корзины. Есть два механизма загрузки – можно загружать блоб или объект полностью в рамках одного запроса или разделить их на куски (блоки или страницы WABS, в GCS они не имеют какого-то специального имени).
Если загружаемые данные имеют небольшой размер и у вас хорошая скорость подключения, вы можете полностью загрузить эти данные в одном запросе. В WABS для этого используется Put Blob. В GCS- PUT Object или POSTObject.
Можно разделять большие данные, которые неэффективно загружать в одном запросе полностью. Обе системы позволяют разбивать данные на куски (блоки или страницы в WABS, в GCS они не имеют какого-то специального имени) и загружать постепенно. В WABS для блочных блобов необходимо использовать PutBlock и Put Block List, для страничных — Put Page. В GCS для этого используются функции POST Object и PutObject.
Есть много причин, по которым можно решить, загружать ли данные кусками:
Давайте посмотрим, как загрузить данные кусками в каждой из систем. Например, вы хотите загрузить кусками файл размером 100 Мб.
Допустим, каждый кусок имеет размер в 1 Мб (несмотря на то, что нет необходимости иметь куски одинакового размера) – вам необходимо совершить загрузку 100 кусков. Берем блочный блоб, каждый из блоков (кусков) которого имеет уникальный идентификатор (BlockId). Для его загрузки используем функцию PutBlock. BlockId – строка, зашифрованная Base64, максимальный размер которой ограничен 64 байтами. Все BlockId (100 в нашем случае) должны быть одной длины. При этом неважно, в каком порядке вы будете загружать блоки – вы можете загружать их и параллельно. После загрузки блока WABS кладет его куда-то в хранилище, и хранит 7 дней. После загрузки всех блоков вызываем Put Block List, подтверждая (commit) эти блоки. До момента вызова этой функции к блобу обратиться нельзя и, если вы не подтвердили блоки в течение 7 дней, они будут удалены системой. После вызова функции, основываясь на порядке списка BlockId, WABS воссоздаст блоб и пометит его как доступный. Нет разницы, какие значения будут иметь BlockId (все они могут быть GUID), но важно, в каком порядке вы отправите список BlockId при использовании Put Block List.
Ограничения:
В случае GCS загрузка большого файла кусками называется “Resumable Uploads”. Сначала необходимо сообщить GCS, что вы начали процесс загрузки, вызовом POST Object. Обычно эта функция используется для загрузки файла с помощью HTML-форм но в этом случае вы не определяете файл. Вы можете определить заголовки запроса, с помощью которых сообщить GCS, что вы начали процесс загрузки. После окончания загрузки GCS возвратит ответ, содержащий Upload Id, уникально идентифицирующий процесс загрузки. Этот Id нужно сохранить, так как он понадобится при загрузке кусков. Далее необходимо попробовать загрузить файл, используя функциюPut Object и передав ей Upload Id и содержимое объекта. Если всё получится, GCS ответит HTTP-кодом 200 Ok, но, если операция не будет выполнена, вам придется запросить у GCS количество загруженных байт. GCS возвратит HTTP-код 308 Resume Incomplete. Далее можно будет продолжить загрузку данных с использованием Put Object.
Мысли:
Давайте посмотрим, как можно скачивать блобы и объекты. Для этого есть два механизма – либо скачивать целый блоб или объект в одном запросе, либо кусками.
В каждой системе есть только одна функция для скачивания — Get Blob в WABS и GET Object в GCS.
Если объект имеет большой размер и вы не уверены, сможете ли скачать его за один раз, вы можете качать кусками, используя ту же функцию с добавлением заголовка Range и определив диапазон байт, необходимый для скачивания.
Процесс скачивания:
У всех трех систем есть общие моменты, например:
Когда я впервые читал о GCS, я обнаружил, что есть много общего у GCS и AS3, например:
Когда мы начали обсуждать основную функциональность GCS, могло так показаться, что GCS предоставляет меньшую функциональность, нежели WABS и AS3, однако в GCS есть функции, которых нет ни в одной другой платформе. Например:
При использовании обеих систем отсутствуют «капитальные» затраты. Модель ценообразования относительно проста и основана на потреблении. В обеих системах счет выставляется на основе использования и он может состоять из трех компонентов:
Доступна также специальная модель ценообразования и обе системы предоставляют различные пакеты оплаты. Подробнее про ценообразование — https://www.windowsazure.com/en-us/pricing/details/ для WABS и https://developers.google.com/storage/docs/pricingandterms для GCS.
В таблицу сведены функции, предоставляемые WABS и GCS. В нем содержатся только поддерживаемые обеими системами функции.
В следующей таблице приведен список функций, поддерживаемых только в WABS.
Рассмотрим подробнее эти функции.
Эта функция создает новый контейнер блобов или корзину.
Важным моментом, который необходимо помнить, является то, что контейнеры блобов ограничиваются аккаунтом хранилища, тогда как корзины GCS ограничиваются проектом GCS. Когда вы создаете аккаунт хранилища WABS, вы определяете его расположение (датацентр), и ваши контейнеры блобов располагаются в конкретном датацентре в конкретной географической локации. Когда вы создаете корзину в GCS, вы определяете регион, в котором будет создана эта корзина, таким образом, можно распределить корзины по всем датацентрам в GCS, если есть такая необходимость. Для того, чтобы сделать то же самое в WABS, вам нужно создать по аккаунту хранилища в каждом датацентре, в котором вы хотите разместить контейнеры.
Есть несколько правил именования контейнеров блобов и корзин, они сведены в таблицу ниже.
Ещё правила по именованию:
Примечания:
Функция возвращает список всех контейнеров блобов или корзин, которые принадлежат аутентифицировавшемуся владельцу в GCS.
Комментарии:
Функция удаляет контейнер блобов или корзину.
Комментарии:
Функция используется для получения списка блобов и объектов в контейнере или корзине. Функции в системах выполняют одно и то же, учитывая:
Различия:
Функция используется для указания ACL для контейнеров или корзин, и в WABS можно также указать одну или более политик доступа. В GCS можно также сконфигурировать CORS (но нельзя конфигурировать CORS и ACL в одном запросе).
Для контейнера блобов значения ACL могут быть:
Для корзин значения ACL могут быть равны:
Удобным в GCS является то, что можно дать пользователям различные наборы разрешений, например, user1 может иметь READ ACL, user2 – WRITE ACL, в WABS такой гибкости нет, разрешения ставятся только на контейнер блобов.
Удобным в WABS является то, что, помимо ACL можно задавать до 5 политик доступа к контейнеру, которые определяют временной набор разрешений к этому контейнеру. Например, можно создать политику доступа с разрешением на запись на контейнер блобов, которая будет действовать только день. Использование политик позволяет генерировать специальный URL с сигнатурой и выдавать его пользователям (гибкая функциональность Shared Access Signatures). Сигнатуры позволяют выдать права на доступ на контейнеры и блобы на более детальном уровне на определенное время.
Функция используется для получения ACL для контейнера блобов или корзины, и в WABS эта функция также возвращает политики доступа, определенные для контейнера.
Для получения ACL корзины нужно вызвать GET Bucket со строковым параметром “acl”, для получения CORS же – со строковым параметром “cors”. Если не указан ни тот ни другой, возвращается список объектов в корзине.
Функция добавляет блоб в контейнер блобов и объект в корзину. Эту функцию можно использовать для указания ACL существующему объекту в GCS или копирования объекта из одной корзины в другую.
Комментарии:
Функция добавляет объект в указанную корзину, используя HTML-форму. POST является альтернативой PUT и позволяет реализовать загрузку объекта браузером. Параметры, переданные PUT с помощью HTTP-заголовков, передаются с POST как тело зашифрованного сообщения multipart/form-data.
Функция позволяет скачать блоб из контейнера или корзины.
Комментарии:
Функция удаляет блоб или объект из хранилища.
Комментарии:
· WABS позволяет определить предусловия, которые должны быть удовлетворены для успешного завершения этой функции (If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match).
Функция копирует блоб или объект куда-либо из исходного расположения.
Комментарии:
· Обе системы позволяют определить предусловия, которые должны быть удовлетворены для успешного завершения этой функции (If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match). Эти условия можно определить как на исходнике, так и на конечной копии в WABS и на исходнике в GCS.
· WABS позволяет копировать объекты из контейнера в контейнер только в пределах одного аккаунта хранилища. В GCS подобного ограничения нет. Если корзины, между которыми происходит обмен, принадлежат к одному проекту, объект будет скопирован. Однако, если вы создали объект, используя API для загрузки кусками, вы не сможете копировать объект из региона в регион.
· Обе системы позволяют вам скопировать существующие метаданные или указать метаданные для конечной копии.
Советы:
Функция используется для получения свойств блоба и метаданных объекта, но не возвращает содержимое блоба или объекта.
Комментарии:
Функция возвращает определенные пользователем метаданные для блоба или объекта. Эту функцию можно использовать для получения свойств конкретной версии блоба или объекта. Для получения этой информации необходимо указать дату/время снапшота блоба в WABS.
Как мы увидели из статьи, обе системы предоставляют похожий набор функций, однако некоторые функции наличествуют в одной системе, но отсутствуют в другой. Несмотря на это, нельзя говорить о большом различии в функциональности.
Примечание от переводчика
Читая этот обзор, не покидало ощущение, что Google разумно решили не строить лисапедов, а пойти по проторенной успешной дороге Amazon — об этом говорит практически полная идентичность некоторых параметров. Учитывая, что Amazon запустили свой сервис в 2006, а Google в 2010, вполне может быть, что так оно и было. Однако у Google есть действительно замечательные функции, которых недостает в остальных сервисах — тот же CORS, например. В целом же можно даже попробовать заявить, что темпы развития сервисов Google и Microsoft во временном контексте выше темпов Amazon.
Спасибо за внимание, как только будут разработаны очередные материалы, я обязательно их переведу и предоставлю вашему вниманию.
Предлагаю посмотреть на сравнение сервисов Windows Azure Blob Storage и Google Cloud Storage (при этом автор не забывает упомянуть и про Amazon AS3).
Я подумал, что неплохо было бы написать статью по сравнению хранилища Google App Engine и Windows Azure. В этой статье мы сравним Windows Azure Blob Storage и Google Cloud Storage.
Первая часть цикла — Сравнение Windows Azure Table Storage и Amazon DynamoDB
Вторая часть цикла — Сравнение Windows Azure Blob Storage и Amazon Simple Storage Service (S3) — ч. I
Третья часть цикла — Сравнение Windows Azure Blob Storage и Amazon Simple Storage Service (S3)–Часть II, резюме
Аббревиатуры: Windows Azure Blob Storage - WABS и Google Cloud Storage – GCS, Amazon S3 – AS3.
Концептуально WABS и GCS предоставляют аналогичную функциональность – проще говоря, обе системы представляют из себя облачные файловые системы, позволяющие хранить большие объемы неструктурированных данных (обычно в виде файлов).
Обе системы предоставляют REST API для работы с файлами и папками и другими библиотеками высокоуровневых языков, которые обычно являются врапперами REST API. Каждый релиз API имеет свою версию, в WABS она имеет значение даты, в GCS – цифры. На момент написания статьи версия WABS была равна 2011-08-18, GCS — version 2.0.
Похожая функциональность в двух системах:
- Обе системы являются облачными файловыми системами с двухуровневой иерархией.
- Обе системы позволяют хранить большие объемы данных долго и дешево.
- Обе системы позволяют защитить содержимое от несанкционированного доступа.
- Обе системы предоставляют свои механизмы контроля доступа для защиты данных. В GCS это ACLs и Query String Authentication в WABS — ACLs и Shared Access Signatures.
- Обе системы позволяют хранить сколь угодно большое количество версий исходного объекта, но механизм версионирования в двух системах различается.
Концепции
Перед тем, как мы поговорим подробнее об этих двух сервисах, я считаю важным пояснить некоторые концепции. Если вы знакомы с базовыми концепциями WABS и GCS, можете пропустить этот раздел.
Контейнеры блобов и корзины: Если эти сервисы – файловые системы в облаке, рассматривайте контейнер блобов WABS и корзину GCS как папку или директорию. В аккаунте хранилища WABS или аккаунте GCS вы можете иметь ноль и более контейнеров блобов и корзин, которые могут содержать блобы или объекты соответственно.
Комментарии:
- Такого понятия, как вложенные контейнеры блобов или корзины, нет. Оба сервиса предоставляют двухуровневую иерархию без вложенности. Однако обе системы позволяют создать иллюзию иерархии папок с использованием префиксов.
- Ограничений на количество контейнеров и корзин нет.
- Обе системы предоставляют возможность логировать запросы ресурсов – эта функция называется в GCS “logging”, в WABS – “Storage Analytics”. Разница состоит в том, что в GCS логирование работает на уровне корзины, в WABS же – на уровне аккаунта хранилища. В GCS данные логирования кладутся в отдельную определенную пользователем корзину, в WABS же – в предопределенные таблицы и контейнеры, которые создаются автоматически при включении логирования.
Блобы и объекты: Блобы WABS и объекты GCS – это файлы в вашей облачной файловой системе, расположенные в контейнерах блобов и корзинах.
Комментарии:
- Отсутствует ограничение на количество хранимых блобов и объектов, при этом в GCS это количество просто неизвестно, в WABS же это количество ограничено размером аккаунта хранилища (100 Тб).
- Максимальный размер объекта в WABS – 1 Тб, в GCS – не определен.
- В WABS есть два типа блобов – блочные, удобные для стриминга (например, картинок, видео, документов) и имеющие максимальный размер в 200 Гб, и страничные, удобные для операций случайного доступа/записи и имеющие максимальный размер в 1 Тб. Общим случаем использование страничного блоба является монтирование VHD в качестве диска в роли Windows Azure. В GCS подобного разделения нет.
- Обе системы предоставляют богатую функциональность по управлению блобами и объектами. Вы можете копировать, загружать, скачивать и совершать другие операции.
- Обе системы предоставляют возможность защиты содержимого от неавторизованного доступа, причем механизм списков контроля доступа более подробно настраиваем в GCS, где на каждый файл в корзине можно создать собственный ACL. В WABS все происходит на уровне контейнера блобов.
Двумя наиболее важными функциями является загрузка и скачивание, давайте обсудим сначала их, потом сравним остальные функции.
Загрузка блобов и объектов
Давайте поговорим о загрузке блобов и объектов в контейнеры и корзины. Есть два механизма загрузки – можно загружать блоб или объект полностью в рамках одного запроса или разделить их на куски (блоки или страницы WABS, в GCS они не имеют какого-то специального имени).
Загрузка в одном запросе
Если загружаемые данные имеют небольшой размер и у вас хорошая скорость подключения, вы можете полностью загрузить эти данные в одном запросе. В WABS для этого используется Put Blob. В GCS- PUT Object или POSTObject.
Загрузка кусками
Можно разделять большие данные, которые неэффективно загружать в одном запросе полностью. Обе системы позволяют разбивать данные на куски (блоки или страницы в WABS, в GCS они не имеют какого-то специального имени) и загружать постепенно. В WABS для блочных блобов необходимо использовать PutBlock и Put Block List, для страничных — Put Page. В GCS для этого используются функции POST Object и PutObject.
Есть много причин, по которым можно решить, загружать ли данные кусками:
- Необходимо загрузить весьма большие данные. Обратите внимание, что в WABS один блочный блоб ограничен размером 200 Гб, страничный – 1 Тб, в GCS же можно иметь один объект до 5 Тб. Такие объемы непрактично загружать в одном запросе.
- Невысокая скорость подключения.
- Обе системы являются облачными сервисами, предназначенными для обработки запросов сотен и тысяч пользователей одновременно, и обе системы ограничат ваши запросы, если они выполняются дольше установленного лимита – в WABS это 10 минут на загрузку 1 Мб данных.
- Разделение больших данных на куски позволяет выполнять параллельную загрузку (соответственно, более быстро загружать данные).
- В случае обрыва загрузки куска вы можете повторить его загрузку, если же оборвется загрузка больших данных, загружающихся в одном запросе, придется загружать всё заново, что неэффективно.
- Ограничения системы – WABS не позволяет в одном запросе загружать данные, если их размер превышает 64 Мб.
Давайте посмотрим, как загрузить данные кусками в каждой из систем. Например, вы хотите загрузить кусками файл размером 100 Мб.
WABS
Допустим, каждый кусок имеет размер в 1 Мб (несмотря на то, что нет необходимости иметь куски одинакового размера) – вам необходимо совершить загрузку 100 кусков. Берем блочный блоб, каждый из блоков (кусков) которого имеет уникальный идентификатор (BlockId). Для его загрузки используем функцию PutBlock. BlockId – строка, зашифрованная Base64, максимальный размер которой ограничен 64 байтами. Все BlockId (100 в нашем случае) должны быть одной длины. При этом неважно, в каком порядке вы будете загружать блоки – вы можете загружать их и параллельно. После загрузки блока WABS кладет его куда-то в хранилище, и хранит 7 дней. После загрузки всех блоков вызываем Put Block List, подтверждая (commit) эти блоки. До момента вызова этой функции к блобу обратиться нельзя и, если вы не подтвердили блоки в течение 7 дней, они будут удалены системой. После вызова функции, основываясь на порядке списка BlockId, WABS воссоздаст блоб и пометит его как доступный. Нет разницы, какие значения будут иметь BlockId (все они могут быть GUID), но важно, в каком порядке вы отправите список BlockId при использовании Put Block List.
Ограничения:
- Блоб можно разделить на максимум 50000 блоков.
- Блоб может иметь максимум 100000 неподтвержденных блоков в любой момент времени.
- Набор неподтвержденных блоков не может иметь размер, больший 400 Гб.
- Все BlockId блоков одного блоба должны быть одной длины, т.е. недопустима ситуация, когда они будут равны block8, block9, block11.
- Максимальная длина BlockId – 64 байт.
GCS
В случае GCS загрузка большого файла кусками называется “Resumable Uploads”. Сначала необходимо сообщить GCS, что вы начали процесс загрузки, вызовом POST Object. Обычно эта функция используется для загрузки файла с помощью HTML-форм но в этом случае вы не определяете файл. Вы можете определить заголовки запроса, с помощью которых сообщить GCS, что вы начали процесс загрузки. После окончания загрузки GCS возвратит ответ, содержащий Upload Id, уникально идентифицирующий процесс загрузки. Этот Id нужно сохранить, так как он понадобится при загрузке кусков. Далее необходимо попробовать загрузить файл, используя функциюPut Object и передав ей Upload Id и содержимое объекта. Если всё получится, GCS ответит HTTP-кодом 200 Ok, но, если операция не будет выполнена, вам придется запросить у GCS количество загруженных байт. GCS возвратит HTTP-код 308 Resume Incomplete. Далее можно будет продолжить загрузку данных с использованием Put Object.
Мысли:
- Я думаю, мы можем избавиться от первого вызова к возврату объекта функции, в которой мы пытаемся загрузить весь файл в надежде получить код 200 OK. Если я пытаюсь загрузить файл на 100 Мб, я весьма уверен, что он не загрузится в один заход. Вместо того, чтобы пытаться загрузить весь этот файл, я могу пропустить первые два шага и просто загрузить кусок этого файла, получить его статус и затем перезагрузить его или загрузить следующий кусок.
- Я не уверен, как можно параллельно загружать куски в GCS, когда GCS при запросе количества загруженных байт возвращает заголовок Range. В WABS есть BlockId, в AS3 номер части, что облегчает задачу параллельной загрузки.
Скачивание блобов и объектов
Давайте посмотрим, как можно скачивать блобы и объекты. Для этого есть два механизма – либо скачивать целый блоб или объект в одном запросе, либо кусками.
В каждой системе есть только одна функция для скачивания — Get Blob в WABS и GET Object в GCS.
Скачивание в одном запросе
Если данные имеют небольшой размер и у вас хорошая скорость подключения, вы можете скачать объект полностью, используя Get Blob в WABS и GET Object в GCS.
Скачивание кусками
Если объект имеет большой размер и вы не уверены, сможете ли скачать его за один раз, вы можете качать кусками, используя ту же функцию с добавлением заголовка Range и определив диапазон байт, необходимый для скачивания.
Процесс скачивания:
- Определить размер объекта. Например, он «весит» 100 Мб.
- Определить размер кусков. Например, вам удобно качать куски по 1 Мб.
- Вызывать Get Blob или Get Object и передавать им соответствующие значения в заголовке Range. Если вы качаете последовательно, ваш первый запрос будет иметь значение этого заголовка “0 – 1048575” (0 – 1 Мб), второй запрос — “1048576 – 2097151” (1 – 2 Мб) и так далее.
- После скачивания положить кусок куда-либо.
- После скачивания всех кусков создать пустой файл размером 100 Мб и заполнить этот файл скачанными кусками.
Общие моменты между WABS, AS3 и GCS
У всех трех систем есть общие моменты, например:
- Все три системы являются облачными файловыми системами с двухуровневой иерархией.
- Все три системы позволяют хранить большие объемы данных долго и дешево.
- Все три системы предоставляют двухуровневую иерархию (корзины/объекты в AS3/GCS и контейнеры блобов/блобы в WABS).
- Все три системы предоставляют RESTful-интерфейс для взаимодействия с собственными сервисами и библиотеки высокоуровневых языков, которые обычно являются врапперами REST.
Общее с AS3
Когда я впервые читал о GCS, я обнаружил, что есть много общего у GCS и AS3, например:
- Одна терминология: обе системы используют похожую терминологию типа корзин и объектов (в WABS они называются контейнерами блобов и блобами).
- Одинаковые имена операций: обе системы используют одинаковое наименование операций. Например, функция из API, возвращающая список корзин, в обеих системах называется GET Service.
- Одинаковая структура ценообразования: обе системы имеют похожу структуру ценообразования. В WABS все транзакции стоят одинаково, AS3 же и GCS имеют стоимость транзакций, которая варьируется в зависимости от выполняющейся операции.
- Один стиль хостинга: обе системы поддерживают virtual-hosted-style (например, http://mybucket.s3.amazon.com/myobject) и path-style (например, http://s3-eu-west-1.amazonaws.com/mybucket/myobject), тогда как WABS поддерживает только path-style (например, http://myaccount.blob.core.windows.net/myblobcontainer/myblob).
- Похожая модель согласованности: Обе системы предоставляют похожую модель согласованности. Например, обе системы предоставляют модель устойчивости strong read-after-write для всех запросов PUT и модель, устойчивую в конечном счете для всех операций List (GET).
Уникальные моменты в GCS
Когда мы начали обсуждать основную функциональность GCS, могло так показаться, что GCS предоставляет меньшую функциональность, нежели WABS и AS3, однако в GCS есть функции, которых нет ни в одной другой платформе. Например:
- OAuth 2.0-аутентификация: Это уникальная и современная функция, которая устраняет необходимость предоставления учетных данных пользователями и приложениями, когда им необходимо получить доступ к данным. Подробнее: https://developers.google.com/storage/docs/authentication#oauth.
- Cookie-based аутентификация: GCS позволяет совершать аутентифицированные в браузере запросы (для тех, у кого нет аккаунта GCS). Для этого необходимо настроить ACL и дать пользователям URL объекта. Подробнее: https://developers.google.com/storage/docs/authentication#cookieauth.
- Cross — Origin Resource Sharing (CORS): Ещё одна уникальная и современная функция, доступная только в GCS. Спецификация CORS, разработанная W3C, является политикой, применяемой в приложениях, работающих на стороне клиента для предотвращения взаимодействия между ресурсами из различных origin (реализация same-origin policy). Однако эта функция предотвращает не только опасное поведение, но и вполне полезные и законные взаимодействия между известными origins. GCS поддерживает эту спецификацию, позволяя настроить корзины для возвращения CORS-совместимых ответов. Подробнее: https://developers.google.com/storage/docs/cross-origin. Обратите внимание, что функция находится на стадии “Experimental” (другими словами, в бете :)). Я не уверен на 100%, но вроде бы того же самого можно достигнуть, используя контейнер блобов $root в WABS.
Ценообразование
При использовании обеих систем отсутствуют «капитальные» затраты. Модель ценообразования относительно проста и основана на потреблении. В обеих системах счет выставляется на основе использования и он может состоять из трех компонентов:
- Количество транзакций: Оплата производится согласно количеству произведенным транзакций – грубо говоря, одна транзакция – это один вызов функции в системе. Есть существенное различие между двумя системами – в WABSстоимость транзакции фиксирована ($0.01 за 10000 транзакций), в GCSона варьируется в зависимости от типа транзакции. Если вы совершаете операции PUT, COPY, POST, LIST, вы платите большую цену за транзакцию ($0.01 за 1000 транзакций), за GET и другие платите меньшую ($0.01 за 10 000 транзакций). О запросах на удаление не пишется, но предполагаю, что они в GCS бесплатны.
- Хранилище: Вы платите за количество данных, хранимое в каждой системе.
- Траффик: Вы платите за количество переданных данных в и из системы. На момент написания поста обе системы предоставляют бесплатный входящий траффик. Не упоминается, оплачивается ли стоимость передачи данных внутри одного датацентра в GCS.
Доступна также специальная модель ценообразования и обе системы предоставляют различные пакеты оплаты. Подробнее про ценообразование — https://www.windowsazure.com/en-us/pricing/details/ для WABS и https://developers.google.com/storage/docs/pricingandterms для GCS.
Функции
В таблицу сведены функции, предоставляемые WABS и GCS. В нем содержатся только поддерживаемые обеими системами функции.
В следующей таблице приведен список функций, поддерживаемых только в WABS.
| WABS |
GCS |
|
| Set Blob Service Properties |
Да |
Нет |
| Get Blob Service Properties |
Да |
Нет |
| Set Container Metadata |
Да |
Нет |
| Get Container Metadata |
Да |
Нет |
| Set Blob Properties |
Да |
Нет |
| Set Blob Metadata |
Да |
Нет |
| Snapshot Blob |
Да |
Нет |
| Lease Blob |
Да |
Нет |
| Put Block |
Да |
Нет |
| Put Block List |
Да |
Нет |
| Get Block List/List Parts |
Да |
Нет |
| Put Page |
Да |
Нет |
| Get Page Ranges |
Да |
Нет |
Рассмотрим подробнее эти функции.
| WABS |
GCS |
|
| Create Container/PUT Bucket |
Да |
Да |
Эта функция создает новый контейнер блобов или корзину.
Важным моментом, который необходимо помнить, является то, что контейнеры блобов ограничиваются аккаунтом хранилища, тогда как корзины GCS ограничиваются проектом GCS. Когда вы создаете аккаунт хранилища WABS, вы определяете его расположение (датацентр), и ваши контейнеры блобов располагаются в конкретном датацентре в конкретной географической локации. Когда вы создаете корзину в GCS, вы определяете регион, в котором будет создана эта корзина, таким образом, можно распределить корзины по всем датацентрам в GCS, если есть такая необходимость. Для того, чтобы сделать то же самое в WABS, вам нужно создать по аккаунту хранилища в каждом датацентре, в котором вы хотите разместить контейнеры.
Есть несколько правил именования контейнеров блобов и корзин, они сведены в таблицу ниже.
| WABS |
GCS |
|
| Минимальная/максимальная длина название |
3/63 |
3/63 |
| Чувствительность к регистру |
Нижний регистр |
Нижний регистр |
| Разрешенные символы |
Alphanumeric и дефис (-) |
Alphanumeric, дефис (-) и точка (.) |
Ещё правила по именованию:
- Имена контейнеров блобов должны начинаться с буквы или цифры, но не с дефиса, при этом после дефиса опять же должна идти буква или цифра, несколько последовательно идущих дефисов не разрешены.
- Имена корзин GCS должны состоять из меток, разделенных точкой, где каждая метка должна начинаться и кончаться буквой в нижнем регистре или цифрой, и имя корзины не должно выглядеть как IP-адрес (например, 127.0.0.1).
- Несмотря на то, что имена корзин могут содержать от 3 до 63 символов, если имя содержит точки, тогда имя корзины может быть до 222 символов, учитывая количество точек.
- Имена корзин не могут начинаться с префикса goog.
Примечания:
- При создании контейнера или корзины вы можете задать ACL (опционально), если же он не указан, то контейнер или корзина становятся приватными, то есть доступными только владельцу. В GCS при создании нельзя определить ACL – при создании применяется System Default ACL. Подробнее: https://developers.google.com/storage/docs/accesscontrol#default. Изменить ACL или применить CORS на корзину можно после ее создания.
- WABS позволяет определить собственные метаданные для контейнера, которые являются коллекций значений ключ-значение и имеют максимальный размер в 8 Кб. В GCS это недоступно.
| WABS |
GCS |
|
| List Containers/GET Service |
Да |
Да |
Функция возвращает список всех контейнеров блобов или корзин, которые принадлежат аутентифицировавшемуся владельцу в GCS.
Комментарии:
- Один вызов этой функции в WABS возвратит максимально 5000 контейнеров, если же их в аккаунте хранилища больше, то будет возвращен также continuation token. По умолчанию WABS возвращает до 5000 контейнеров, но вы можете указать и меньшее количество. В GCS это количество не упоминается.
- В WABS можно совершать фильтрацию на стороне сервера с использованием префикса, с которого должны начинаться имена контейнеров, которые попадут в выборку.
- В WABS можно указать, нужно ли возвращать метаданные для контейнера блобов вместе со списком.
| WABS |
GCS |
|
| Delete Container/DELETE Bucket |
Да |
Да |
Функция удаляет контейнер блобов или корзину.
Комментарии:
- Может так выглядеть, что эта операция выглядит как синхронная, в реальности же она не такая. Когда вы отправляете запрос на удаление контейнера блобов, он помечается для удаления и становится недоступным, после чего удаляется в процессе сборки мусора, поэтому реальное время удаления контейнера может варьироваться в зависимости от размера данных в этом контейнере. По моему опыту удаление очень большого контейнера может занять часы, и в это время попытка создания контейнера с таким же именем приведет к ошибке (Conflict Error – HTTP 409). В связи с этим необходимо планировать, что делать в это время.
- В GCS корзина должна быть пустой перед удалением. Сначала необходимо удалить все объекты из корзины, после чего удалить ее. Иначе будет возвращена ошибка 409 Conflict.
| WABS |
GCS |
|
| List Blobs/GET Bucket (List Objects) |
Да |
Да |
Функция используется для получения списка блобов и объектов в контейнере или корзине. Функции в системах выполняют одно и то же, учитывая:
- Обе функции позволяют ограничить результирующую выборку нужным количеством объектов.
- Обе функции имеют максимальное количество объектов, которое они могут возвратить за один вызов функции – в WABS это 5000, в GCS – 1000.
- Обе функции поддерживают разделители, которые представляют из себя символ, группирующий блобы или объекты. Наиболее используемый разделитель — /. Как указывалось выше, обе системы поддерживают двухуровневую иерархию, и использование разделителя может создать иллюзию иерархию типа папки. Например, у вас есть следующие объекты: images/a.png, images/b.png, images/c.png, logs/1.txt, logs/2.txt, files.txt. Когда вы хотите вызвать функцию и передаете ей разделитель /, обе системы возвратят следующие значения: images, logs, files.txt.
- Обе функции поддерживают фильтрацию на стороне сервера с использованием префиксов. Когда ваш запрос содержит префикс, обе системы возвратят объекты, которые имеют название, которое начинается с этого префикса. Используя пример выше, если мы передадим префикс “images” без разделителей, обе системы возвратят следующие значения: images/a.png, images/b.png, images/c.png.
- Обе функции могут использовать маркер, который является, по сути, continuation token, и используется для указания обеим системам, что надо начинать получать список объектов, начиная с этого маркера.
- Обе системы возвращают объекты в алфавитном порядке.
Различия:
- Один вызов функции в WABS возвратит максимум 5000 блобов, GCS – 1000 объектов.
- При получении списка можно указать WABS, что необходимо возвращать также снапшоты блобов. В GCS этого сделать нельзя.
- При получении списка можно указать WABS, что необходимо возвращать метаданные для блобов. В GCS метаданные для объектов не возвращаются – для этого необходимо использовать HEAD Object.
- При получении списка можно указать WABS, что необходимо возвращать список блобов, которые ещё не подтверждены (commited), т.е. частично загружены, GCS же может возвращать только те объекты, которые уже полностью загружены.
- Можно использовать эту функцию для получения конфигурации ACL или CORS для корзины.
| WABS |
GCS |
|
| Set Container ACL/PUT Bucket (ACL or CORS) |
Да |
Да |
Функция используется для указания ACL для контейнеров или корзин, и в WABS можно также указать одну или более политик доступа. В GCS можно также сконфигурировать CORS (но нельзя конфигурировать CORS и ACL в одном запросе).
Для контейнера блобов значения ACL могут быть:
Для корзин значения ACL могут быть равны:
- READ: Разрешено получение списка объектов в корзине.
- WRITE: Разрешено создание, перезапись и удаление объектов в корзине.
- FULL_CONTROL: С этим значением предоставляются разрешения READ, WRITE.
Удобным в GCS является то, что можно дать пользователям различные наборы разрешений, например, user1 может иметь READ ACL, user2 – WRITE ACL, в WABS такой гибкости нет, разрешения ставятся только на контейнер блобов.
Удобным в WABS является то, что, помимо ACL можно задавать до 5 политик доступа к контейнеру, которые определяют временной набор разрешений к этому контейнеру. Например, можно создать политику доступа с разрешением на запись на контейнер блобов, которая будет действовать только день. Использование политик позволяет генерировать специальный URL с сигнатурой и выдавать его пользователям (гибкая функциональность Shared Access Signatures). Сигнатуры позволяют выдать права на доступ на контейнеры и блобы на более детальном уровне на определенное время.
| WABS |
GCS |
|
| Get Container ACL/GET Bucket (ACL or CORS) |
Да |
Да |
Функция используется для получения ACL для контейнера блобов или корзины, и в WABS эта функция также возвращает политики доступа, определенные для контейнера.
Для получения ACL корзины нужно вызвать GET Bucket со строковым параметром “acl”, для получения CORS же – со строковым параметром “cors”. Если не указан ни тот ни другой, возвращается список объектов в корзине.
| WABS |
GCS |
|
| Put Blob/PUT Object |
Да |
Да |
Функция добавляет блоб в контейнер блобов и объект в корзину. Эту функцию можно использовать для указания ACL существующему объекту в GCS или копирования объекта из одной корзины в другую.
Комментарии:
- В обеих системах функция перезапишет существующий объект с указанным именем.
- Обе системы позволяют определить свойства для объектов (cache control, тип содержимого и т.д.)
- Обе системы позволяют послать хэш MD5 содержимого для проверки консистентности данных.
- В GCS можно при создании объекта задать на него ACL, чего нельзя сделать в WABS.
- Обе системы позволяют указывать метаданные для блобов и объектов в форме коллекции пар ключ-значение. В WABS максимальный размер этих метаданных – 8 Кб, в GCS – неизвестно.
- При создании страничного блоба с использованием этой функции вы только инициируете страничный блоб, но не кладете в него данные. Для вставки данных необходимо использовать функцию Put Page.
- При создании блочного блоба или объекта в GCS данные отправляются в запросе.
- Максимальный размер блочного блоба, созданного с использованием этой функции, равен 64 Мб. Если размер больше, блоб должен быть разделен на блоки и загружен с помощью Put Block и Put Block List.
- WABS позволяет определить предусловия, которые должны быть удовлетворены для успешного завершения этой функции (If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match).
| WABS |
GCS |
|
| POST Object |
Нет |
Да |
Функция добавляет объект в указанную корзину, используя HTML-форму. POST является альтернативой PUT и позволяет реализовать загрузку объекта браузером. Параметры, переданные PUT с помощью HTTP-заголовков, передаются с POST как тело зашифрованного сообщения multipart/form-data.
| WABS |
GCS |
|
| Get Blob/GET Object |
Да |
Да |
Функция позволяет скачать блоб из контейнера или корзины.
Комментарии:
- Можно качать кусками, указав количество байт в заголовке Range.
- В WABS функция также возвращает метаданные для скачиваемого блоба.
- В GCS можно использовать эту функцию для получения содержимого объекта или его ACL.
- Обе системы позволяют определить предусловия, которые должны быть удовлетворены для успешного завершения этой функции (If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match).
- Можно использовать эту функцию для получения версий блобов– для получения версии блоба нужно указать дату/время снапшота блоба.
| WABS |
GCS |
|
| Delete Blob/DELETE Object |
Да |
Да |
Функция удаляет блоб или объект из хранилища.
Комментарии:
- В WABS можно использовать эту функцию для удаления только снапшотов без удаления исходника. Если исходник удаляется, все его снапшоты также удаляются.
- Эту функцию можно использовать для удаления конкретных версий блоба– для этого нужно указать дату/время снапшота блоба в WABS.
· WABS позволяет определить предусловия, которые должны быть удовлетворены для успешного завершения этой функции (If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match).
| WABS |
GCS |
|
| Copy Blob/Put Object – Copy |
Да |
Да |
Функция копирует блоб или объект куда-либо из исходного расположения.
Комментарии:
· Обе системы позволяют определить предусловия, которые должны быть удовлетворены для успешного завершения этой функции (If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match). Эти условия можно определить как на исходнике, так и на конечной копии в WABS и на исходнике в GCS.
· WABS позволяет копировать объекты из контейнера в контейнер только в пределах одного аккаунта хранилища. В GCS подобного ограничения нет. Если корзины, между которыми происходит обмен, принадлежат к одному проекту, объект будет скопирован. Однако, если вы создали объект, используя API для загрузки кусками, вы не сможете копировать объект из региона в регион.
· Обе системы позволяют вам скопировать существующие метаданные или указать метаданные для конечной копии.
- В GCS при копировании удаляется определенный ACL и на объект ставится ACL по умолчанию. Собственный ACL можно определить в процессе копирования, используя соответствующий заголовок запроса.
Советы:
- Обе системы не поддерживают переименование объекта. Переименование объекта можно реализовать, сначала скопировав объект, после чего удалив его.
- Можно также «повысить» версию блоба или объекта до «текущей» версии. Для этого нужно указать как исходник для копирования версионированный блоб (указав на его снапшот) или объект (указав на его Version Id) и конечную копию как неверсионированный блоб или объект.
| WABS |
GCS |
|
| Get Blob Properties/HEAD Object |
Да |
Да |
Функция используется для получения свойств блоба и метаданных объекта, но не возвращает содержимое блоба или объекта.
Комментарии:
- Get Blob Properties в WABS и HEAD Object в GCS возвращает набор определенных пользователем метаданных, стандартных свойств HTTP и системных свойств для блоба или объекта.
- WABS позволяет определить предусловия, которые должны быть удовлетворены для успешного завершения этой функции (If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match).
- Эту функцию можно использовать для получения свойств конкретной версии блоба. Для получения этой информации необходимо указать дату/время снапшота блоба. Если эти параметры опущены, возвращается информация о текущей версии.
- Если необходимо возвратить только определенные пользователем метаданные для блоба в WABS, нужно использовать Get Blob Metadata.
| WABS |
GCS |
|
| Get Blob Metadata/HEAD Object |
Да |
Да |
Функция возвращает определенные пользователем метаданные для блоба или объекта. Эту функцию можно использовать для получения свойств конкретной версии блоба или объекта. Для получения этой информации необходимо указать дату/время снапшота блоба в WABS.
Резюме
Как мы увидели из статьи, обе системы предоставляют похожий набор функций, однако некоторые функции наличествуют в одной системе, но отсутствуют в другой. Несмотря на это, нельзя говорить о большом различии в функциональности.
Примечание от переводчика
Читая этот обзор, не покидало ощущение, что Google разумно решили не строить лисапедов, а пойти по проторенной успешной дороге Amazon — об этом говорит практически полная идентичность некоторых параметров. Учитывая, что Amazon запустили свой сервис в 2006, а Google в 2010, вполне может быть, что так оно и было. Однако у Google есть действительно замечательные функции, которых недостает в остальных сервисах — тот же CORS, например. В целом же можно даже попробовать заявить, что темпы развития сервисов Google и Microsoft во временном контексте выше темпов Amazon.
Спасибо за внимание, как только будут разработаны очередные материалы, я обязательно их переведу и предоставлю вашему вниманию.
