Здравствуйте.
Предлагаю вашему вниманию перевод первой статьи из цикла сравнения сервисов, предоставляемых Windows Azure и Amazon, который пишется достаточно известным в облачных кругах специалистом — Gaurav Mantri.
В этой статье я сравню Windows Azure Table Storage и Amazon DynamoDB – WATS и ADDB соответственно.
С точки зрения функциональности WATS и ADDB предоставляют похожие возможности. Обе – NoSQL-системы, предназначенные для хранения большого количества данных. Amazon также имеет еще одну базу данных NoSQL – SimpleDB.
Важным моментом, который необходимо отметить, является то, что ADDB – не просто NoSQL-база данных. Это сервис баз данных. Да, это правда, что он используется для управления данными, однако вы контролируете степень масштабируемости системы с помощью пропускной способности, которая вам необходима. В этом смысле всё это весьма похоже на экземпляры сервиса вычислений Amazon или Windows Azure. В случае экземпляра сервиса вычислений вы выбираете, какой размер экземпляра вам нужен, и система реагирует на запрос. Аналогично в случае ADDB – вы сообщаете системе, как много операций чтения и записи будет производить ваше приложение в таблицу ADDB, и ADDB выделяет необходимые мощности.
Концептуально обе системы похожи:
- Обе системы – нереляционные NoSQL.
- Обе системы в целом являются хранилищами записей ключ-значение.
- Отсутствует поддержка отношений, которые доступны в реляционной базе данных.
- Подразумеваемая поддержка высокой доступности и гибкости.
- Обе системы предоставляют REST API для работы с очередями и сообщениями и другими библиотеками высокоуровневых языков, которые обычно являются врапперами, реализующими REST API. В обеих системах каждый релиз API имеет свою версию, выраженную в дате. На момент написания эти версии равны: WATS — 2011-08-18, ADDB — 2011-12-05.
Естественно, есть несколько существенных различий:
- В ADDB пропускная способность, которая вам необходима, это то, что выделяется вам при начале работы с системой, в случае же WATS пропускная способность контролируется системой. Поэтому система ADDB является более гибкой, однако требует больше “капитальной” работы.
- В отличие от SimpleDB, где на домен стоит лимит в 10 Гб, ADDB не имеет подобного ограничения – можно хранить сколько угодно данных. WATS также не ставит hard-лимитов на данные в таблице, но вы ограничены размером аккаунта хранилища (сейчас 100 Тб).
- ADDB может по вашему желанию индексировать ваши данные, в отличие от WATS. Технически WATS тоже индексирует ваши данные, но только по определенным атрибутам (PartitionKey, RowKey), и именно возможность иметь вторичные индексы в WATS является одной из наиболее запрашиваемых пользователями функций.
Концепции
Таблица: когда мы думаем о таблице, то первым, что приходит в голову, является утверждение, что это “что-то, что состоит из строк и столбцов”. Таблица в WATS и ADDB может выглядеть так, как мы представляем себе, но на самом деле это не так. Рассматривайте таблицу как контейнер, содержащий коллекции пар ключ-значение, отображающих данные. В реляционной модели мы определяем столбцы для таблиц, и строки содержат данные. Для хранения данных в таблице вы должны определить столбцы. Таблица в WATS и ADDB не содержит схему, то есть столбцы определять необходимости нет. Короче говоря, рассматривайте таблицу как мешок, куда вы складываете нужные данные.
Несмотря на то, что концептуально таблицы в обеих системах являются контейнерами для хранения данных, между ними есть несколько различий:
- По умолчанию в ADDB стоит лимит на количество таблиц в 256 штук (можно увеличить по запросу, в WATS ограничений нет. В WATS можно иметь сколько угодно таблиц, учитывая лимит на аккаунт хранилища (сейчас 100 Тб).
- Когда вы определяете в ADDB таблицу, вы должны определить первичный ключ для этой таблицы, который может быть одним атрибутом или несколькими. Все объекты в этой таблице должны иметь уникальные значения первичного ключа. В WATS первичный ключ формируется системой и является комбинацией атрибутов PartitionKey и RowKey. Каждая сущность в таблице должна иметь уникальную комбинацию этих атрибутов.
- При создании таблицы в ADDB вы должны указать выделяемую пропускную способность (количество операций чтения и записи), что недоступно в WATS. Вы можете позднее с помощью ADDB API менять эту пропускную способность. При истечении выделенной пропускной способности ADDB начинает ограничивать запросы (throttling).
Сущность и объект: То, что определяет данные в таблице. Каждая сущность (в WATS) и объект (item, ADDB) состоит из одного или более атрибутов. Атрибут – это коллекция пар ключ-значений (ключ-значение-данные в WATS). В реляционных базах данных это была бы строка. Здесь же каждая строка в таблице или домене не имеет связей с другими строками. Каждая сущность в WATS уникально идентифицируется двумя атрибутами: PartitionKey и RowKey — рассматривайте это как композитный первичный ключ. Каждая сущность должна иметь уникальную комбинацию этих атрибутов. В ADDB каждый объект уникально идентифицируется первичным ключом, который является одним из атрибутов объекта. Все объекты в таблице ADDB должны иметь первичный ключ.
Между сущностью и объектом есть несколько различий:
- В WATS на сущность приходится максимум 256 атрибутов, в ADDB ограничений нет. Каждая сущность WATS имеет три системных атрибута: PartitionKey, RowKey и Timestamp, таким образом количество определяемых пользователем атрибутов сокращается до 253. Значения атрибутов PartitionKey и RowKey можно определить самостоятельно, Timestamp же определяется системой и содержит значение даты и времени (UTC) создания или обновления сущности. Атрибуты PartitionKey и RowKey содержат тип String.
- Максимальный размер сущности в WATS выставлен в 1Мб, объект ADDB – 64 Кб.
- В WATS значения атрибутов могут иметь один из 8 типов данных: Binary, Boolean, DateTime, Decimal, Int32, Int64, Guid, и String, что предоставляет богатую модель данных. В ADDB набор доступных типов содержит: String, Number и String/Number Sets (массивы строк или чисел).
- В WATS данные индексируются только по PartitionKey и RowKey, индексирование по другим атрибутам пока недоступно. Данные в Windows Azure партиционируются по значению PartitionKey, что вызывает необходимость в его тщательном выборе, так как неправильный выбор значения может существенно снизить производительность. Замечательную статью можно почитать здесь. В ADDB же данные индексируются по атрибутам, из которых состоит первичный ключ таблицы.
ADDB поддерживает два типа первичных ключей:
- Hash Type Primary Key: В этом случае первичный ключ состоит из одного атрибута, hash. ADDB строит неструктурированный hash-индекс по атрибуту этого первичного ключа.
- Hash and Range Type Primary Key: В этом случае первичный ключ состоит из двух атрибутов. Первый атрибут – hash-атрибут, второй – range-атрибут. ADDB строит неструктурированный hash-индекс по hash-атрибуту и сортированный range-индекс по range-атрибуту.
Выделение пропускной способности
Одной из наиболее важных функций в ADDB является выделение пропускной способности, позволяющей настроить необходимую пропускную способность для приложения. Вкратце – выделение пропускной способности определяет, как много операций чтения и записи в минуту может быть совершено для таблицы ADDB. Основываясь на предоставленных вами значениях, ADDS выделяет соответствующие ресурсы, при этом вы можете обновить конфигурацию налету с использованием API или Amazon Management Console.
Выделение пропускной способности оперирует двумя терминами — Read Capacity Units для операций чтения и Write Capacity Units для операций записи.
Read Capacity Unit определяется как количество операций согласованного чтения в секунду в блоке 1 Кб. Так, если вы запросили 10 RCU, это значит, что вы можете выполнить операции согласованного чтения на 10 объектах до 1 Кб в размере в секунду. Если размер объекта более чем 1 Кб, количество объектов, которые вы можете прочитать в секунду, будет меньше. Например, если ваши объекты имеют размер 1 и 2 Кб, вы сможете совершить только 5 операций согласованного чтения в секунду перед тем, как система начнет вас ограничивать.Если вы хотите вместо согласованного чтения использовать согласованное в конечном счете чтение (eventually consistent read), пропускная способность обычно удваивается – если вы запросили 10 RCU, вы сможете сделать 20 операций согласованного в конечном счете чтения на объектах в 1 Кб и меньше.
Аналогично с Write Capacity Unit – количество операций чтения или записи на 1 Кб. Если запрошено 10 WCU, можно будет совершить запись 10 объектов до 1 Кб в размере в секунду. Если размер объекта превышает 1 Кб, количество объектов для записи в секунду уменьшается. Например, если размер объектов между 1 и 2 Кб, можно будет совершить 5 операций записи в секунду перед тем как система начнет ограничение.
Обратите внимание, что выделение пропускной способности имеет особенности в вопросе ценообразования, так как цены на ADDB формируются отдельно от остальных сервисов. По сути, вы платите за операции чтения и записи, зарезервированные вами. На момент написания статьи вы заплатили бы $0.01 / час за каждые 10 unit of write capacity и $0.01 / час за каждые 50 units write capacity в датацентре в US East (Virginia). В принципе, ценообразование аналогично тому, как формируются цены за экземпляры вычислительных сервисов, в случае которых вы запрашиваете виртуальную машину определенного размера (с определенными мощностями и RAM) и почасово платите за эту виртуальную машину вне зависимости от того, полностью ли вы загружаете ее или нет. Аналогично в ADDB – вы платите почасово за пропускную способность, которую вы запросили у Amazon, вне зависимости от степени ее использования.
Когда дело доходит до выделения пропускной способности, возникает несколько моментов, которые необходимо учитывать:
- Это настраивается для каждой таблицы.
- Минимальная пропускная способность – 5 RCU и 5 WCU на таблицу – для каждой таблицы вы платите минимум $0.001 ($0.01 * 5 / 50) для операций согласованного чтения и $0.005 для операций согласованной записи за час, даже если вы вообще не используете эту таблицу.
- Увеличение или уменьшение выделенной пропускной способности должно как минимум на 10% отличаться от предыдущего значения – например, если сейчас у вас 100 read capacity units и вы хотите увеличить это значение, новое значение должно быть равно или больше 110.
- Когда вы увеличиваете или уменьшаете пропускную способность, в одном запросе вы можете увеличить значение максимум вдвое – например, если сейчас у вас 100 read capacity units, это значение можно увеличить максимум до 200.
- Уменьшать выделенную пропускную способность можно один раз в день.
- На таблицу можно выделить максимум 10,000 read capacity units и 10,000 write capacity units (по умолчанию). По умолчанию между всеми таблицами в аккаунте — максимум 20,000 read capacity units и 20,000 write capacity units. Эти значения можно увеличить, написав Amazon.
Цены
Перед тем как мы поговорим о функциональности, предоставляемой каждой из систем, давайте посмотрим на ценообразование. В обеих системах нет “капитальных” затрат. К компонентам, входящим в ценообразование, относятся:
- Транзакция: В WATS вы платите за количество транзакций и их стоимость фиксирована ($0.01 за 10 000 транзакций). Таким образом, получается, что для вычисления окончательной цены необходимо умножить количество транзакций на их стоимость.
- Выделение пропускной способности: В ADDB вы платите за выделенную пропускную способность по фиксированным ценам за операции чтения и записи. Посчитать общую цену можно, умножив количество выделенных RCU и WCU на цену за час.
- Трансфер данных: Вы платите за количество переданных данных в и из системы. На момент написания поста обе системы предоставляют бесплатный входящий траффик. Данные, переносимые между ADDB и Amazon EC2 внутри одного региона бесплатны. Данные, переносимые между ADDB и Amazon EC2 в разных регионах оплачиваются согласно тарифам. В WATS оплачивается только исходящий траффик.
Ценообразование в ADDB более предсказуемо, нежели ценообразование в WATS, однако необходимо правильно подсчитать необходимую пропускную способность, чтобы не платить за лишние запросы или не вызывать их ограничение системой.
Список функций
Рассмотрим подробнее все функции из списка.
| WATS | ADDB | |
| Create Table/CreateTable | Да | Да |
Как следует из имени этой функции, она создает таблицу в WATS и ADDB. В отличие от SimpleDB, где операция CreateDomain является идемпотентной, в ADDB она таковой не является – если вы попытаетесь создать таблицу с именем существующей таблицы, система выкинет ошибку.
Есть несколько конвенций именования таблицы/домена, они сведены в таблицу ниже.
| WATS | ADDB | |
| Минимальная/максимальная длина | 3/63 | 3/255 |
| Чувствительность к регистру | Смешанный регистр | Смешанный регистр |
| Разрешенные символы | Alphanumeric | Alphanumeric, дефис (-), тире (_), точка (.) |
Есть еще несколько моментов:
- В WATS имя таблицы не может начинаться с цифры, более того, регистр имен таблиц сохраняет регистр, при котором они были созданы, но при использовании регистр неважен. Как упоминалось выше, по умолчанию можно создать до 256 таблиц на аккаунт ADDB. Для увеличения этого значения можно написать просьбу в Amazon: (http://www.amazon.com/gp/html-forms-controller/DynamoDB_Limit_Increase_Form).
- Эта операция в ADDB асинхронна, тогда как в WATS наоборот – она синхронна. При получении ADDB запроса на создание таблицы создается множество процессов (выделение ресурсов) и вам не разрешается использовать эту таблицу до завершения всех процессов и перевода таблицы в состояние Active.
- При создании таблицы в ADDB необходимо указать первичный ключ для этой таблицы и необходимую пропускную способность, которую можно изменить позднее с использованием UpdateTable (но первичный ключ менять нельзя).
| WATS | ADDB | |
| Query Tables/ListTables | Да | Да |
Функция возвращает список таблиц. Один запрос функции возвращает до 1000 таблиц в WATS и все таблицы в ADDB, если же остаются ещё таблицы или домены, возвращается также continuation token, позволяющий получить доступ к следующему набору таблиц или доменов.
| WATS | ADDB | |
| Максимальное количество записей на вызов функции | 1000 | - |
| Возвращение continuation token | Да | Да |
| WATS | ADDB | |
| Delete Table/DeleteTable | Да | Да |
Функция удаляет таблицу. В ADDB не идемпотента.
Для удаления таблицы в ADDB таблица должна быть в состоянии Active. Эта операция в ADDB асинхронна. В WATS, несмотря на то, что кажется, что она синхронна, она тоже асинхронна. При отправке запроса на удаление таблицы в WATS таблица помечается системой для удаления и становится недоступной, и удаляется только в процессе сборки мусора, поэтому настоящее время удаления таблицы может варьироваться в зависимости от размера данных в этой таблице. По моему опыту удаление очень большой таблицы может занять часы. В это время попытка создания таблицы с этим же именем приведет к ошибке (Conflict error – HTTP Status Code 409).
| WATS | ADDB | |
| UpdateTable | Нет | Да |
Функция используется для обновления выделенной пропускной способности для таблицы в ADDB. Можно увеличивать и уменьшать выделенную пропускную способность:
- Новое значение пропускной способности должно быть в пределах лимитов и без нарушений правил (см. выше раздел “выделение пропускной способност”)
- Таблица находится в состоянии Active.
| WATS | ADDB | |
| DescribeTable | Нет | Да |
Функция DescribeTable используется для получения следующей информации о таблице:
- CreationDateTime: Дана создания в UNIX epoch time.
- ItemCount: Количество объектов в таблице, обновляемое примерно каждые 6 часов, поэтому изменения могут не сразу привести к обновлению этого значения.
- KeySchema: Структура первичного ключа (простой или композитный).
- ProvisionedThroughput: Пропускная способность для таблицы, состоящая из значений LastIncreaseDateTime (если доступно), LastDecreaseDateTime (если доступно), ReadCapacityUnits и WriteCapacityUnits. Если пропускная способность для таблицы ни разу не менялась, ADDB не возвращает значения для этих элементов.
- TableSizeBytes: Общий размер таблицы в байтах. Amazon DynamoDB обновляет это значение примерно каждые 6 часов, поэтому изменения могут не сразу привести к обновлению этого значения.
- TableStatus: Текущее состояние таблицы (CREATING, ACTIVE, DELETING или UPDATING).
Обратите внимание, что результаты этой операции согласованы в конечном счете, поэтому не гарантируется, что вы получите самые свежие обновления.
| WATS | ADDB | |
| CRUD на одной сущности/объекте | Да | Да |
Обе системы позволяют выполнять операции Create, Read, Update, Delete (CRUD) на одной сущности/объекте.
Что необходимо помнить:
- Лимит на 256 атрибутов на сущность в WATS и отсутствие лимитов в ADDB. В WATS при 3 существующих системных атрибутах (PartitionKey, RowKey, и Timestamp) можно определить до 253 атрибутов.
- В WATS значения атрибутов могут быть 8 типов: Binary, Boolean, DateTime, Decimal, Int32, Int64, Guid, String. В ADDB: String, Number и String/Number Sets (массивы строк или чисел).
- Максимальный размер объекта в ADDB – 64 Кб, в WATS сущность может быть до 1 Мб в размере.
Создание
В WATS для операций создания можно использовать несколько операций, в ADDB все они объединениы в одну функцию (PutItem). Операция PutItem создает объект либо, если таблица содержит объект с указанным первичным ключом, этот объект полностью замещается. В WATS есть три функции для создания сущности:
- Insert Entity: Создает новую сущность в таблице. Если сущность с указанными значениями PartitionKey и RowKey уже существует, выкидывается ошибка.
- Insert or Merge Entity: Создает новую сущность в таблице. Если сущность с указанными значениями PartitionKey и RowKey уже существует, эта сущность будет объединена с новой сущностью, т.е. значения существующих в обеих сущностях атрибутов будут обновлены, атрибуты же, существующие только в новой сущности, будут добавлены, а атрибуты, существующие только в старой сущности, будут оставлены в старом состоянии.
- Insert or Replace Entity: Создает новую сущность в таблице. Если сущность с указанными значениями PartitionKey и RowKey уже существует, эта сущность будет заменена новой сущностью с помощью удаления старой сущности и создания новой сущности с указанными значениями PartitionKey и RowKey.
Чтение
В обеих системах операции чтения заключаются в запросе атрибутов сущности/объекта. В WATS это реализуется с помощью Query Entities и передачи PartitionKey и RowKey в качестве аргументов. В ADDB это реализовано с помощью GetItem и передачи в качестве аргументов первичного ключа объекта.
Обратите внимание, что по умолчанию операция GetItem совершает согласованное в конечном счете чтение. Однако можно указать этой функции осуществлять согласованное чтение, используя опциональный параметр ConsistentRead.
Обновление
В WATS существует несколько способов обновлять сущности, в ADDB же только два:
- PutItem: Операция PutItem создает объект либо, если объект с указанным первичным ключом уже существует, полностью заменяет его.
- UpdateItem: Если необходимо заменить несколько атрибутов существующего объекта вместо полной замены, можно использовать эту функциональность, предоставляющую гибкий контроль над изменением атрибутов.
В WATS доступно четыре функции для обновления сущности:
- Merge Entity: Если сущность с указанными значениями PartitionKey и RowKey уже существует, эта сущность будет объединена с новой сущностью, т.е. значения существующих в обеих сущностях атрибутов будут обновлены, атрибуты же, существующие только в новой сущности, будут добавлены, а атрибуты, существующие только в старой сущности, будут оставлены в старом состоянии.
- Update Entity: Операция заменяет существующую сущность на новую сущность, удаляя старую сущность и создавая новую с указанными значениями PartitionKey и RowKey.
- Insert or Merge Entity: Создает новую сущность в таблице. Если сущность с указанными значениями PartitionKey и RowKey уже существует, эта сущность будет объединена с новой сущностью, т.е. значения существующих в обеих сущностях атрибутов будут обновлены, атрибуты же, существующие только в новой сущности, будут добавлены, а атрибуты, существующие только в старой сущности, будут оставлены в старом состоянии.
- Insert or Replace Entity: Создает новую сущность в таблице. Если сущность с указанными значениями PartitionKey и RowKey уже существует, эта сущность будет заменена новой сущностью с помощью удаления старой сущности и создания новой сущности с указанными значениями PartitionKey и RowKey.
Обновление согласно условию (Conditional Updates): Обе системы поддерживают обновление согласно условию, однако действуют эти механизмы по-разному. В ADDB вы определяете условия на значениях существующих атрибутов, то есть определяете, что ADDB обновит значение атрибута1 только если значение другого атрибута атрибут2 равно какому-то значению. Обновление согласно условию в ADDB поддерживают проверку существования атрибута. В WATS все по-другому. В WATS все зависит от значения ETag сущности. Для обновления сущности согласно условию вы должны предоставить значение ETag сущности в одном из заголовков запросов (когда используете REST API), после чего WATS сравнивает это значение с текущим значением ETag обновляемой сущности и обновление совершается только если эти значения совпадают.
Удаление
Для удаления сущности в WATS можно использовать Delete Entity передавая PartitionKey и RowKey этой сущности в качестве входных аргументов. Аналогично удалению объекта в ADDB, вы используете DeleteItem с передачей первичного ключа этого объекта как входного аргумента.
DeleteAttributes в ADDB идемпотентна, то есть если вы пробуете удалить несуществующую сущность, ADDB не выкинет ошибку до тех пор, пока вы не используете удаление на основе условия. Если вы совершаете удаление согласно условию, в ADDB операция не идемпотентна. В WATS при попытке удаления несуществующей сущности будет выброшена ошибка (NotFound error – HTTP Status Code 404) .
Удаление согласно условию: Обе системы поддерживают удаление согласно условию, однако действуют эти механизмы по-разному. В ADDB вы определяете условия на значениях существующих атрибутов, то есть определяете, что ADDB удалит объект только если значение атрибута атрибут2 равно какому-то значению. Удаление согласно условию в ADDB поддерживает проверку существования атрибута. В WATS все по-другому. В WATS все зависит от значения ETag сущности. Для обновления сущности согласно условию вы должны предоставить значение ETag сущности в одном из заголовков запросов (когда используете REST API), после чего WATS сравнивает это значение с текущим значением ETag удаляемой сущности и удаление совершается только если эти значения совпадают.
| WATS | ADDB | |
| CRUD для нескольких сущностей/объектов | Да | Да |
Обе системы поддерживают выполнение операций CRUD для нескольких сущностей/объектов в пределах одного вызова сервиса.
В WATS для CRUD можно использовать Entity Group Transactions. В ADDB для этого можно использовать BatchWriteItem. Можно использовать также BatchGetItem для чтения нескольких объектов из нескольких таблиц с использованием первичных ключей.
Комментарии:
- В WATS это ограниченная транзакцией операция, то есть вся операция либо выполнится, либо нет. В ADDB это не так. Возможно, что несколько объектов могут не возвратиться, и в этом случае ADDB возвратит список объектов, для которых операция не удалась, и их можно обработать позднее.
- Нельзя обновлять объект, используя BatchWriteItem, только создавать и удалять.
- В ADDB максимальный размер запроса – 1 Мб, в WATS – 4 Мб.
- В ADDB есть лимит на 25 объектов в одной операции BatchWriteItem. В WATS в пределах одной entity group transaction этот лимит равен 100.
- BatchWriteItem в ADDB позволяет работать с несколькими таблицами в одном запросе, но entity group transaction в WATS требует как работу в пределах одной таблицы, так и то, что все сущности в этой операции имели одинаковое значение PartitionKey.
- BatchGetItem в ADDB осуществляет согласованное в конечном счете чтение. Согласованное чтение невозможно.
| WATS | ADDB | |
| Query Entities/Query (Scan) | Да | Да |
Используется для получения одной или более сущностей/объектов из таблицы на основе критерия.
Комментарии:
- В WATS Query Entities используется для получения списка сущностей, в ADDB же для этого используется две функции Query и Scan. Разница между вызовами этих функций заключается в том, что для функции Scan нет необходимости передавать первичный ключ. Так как данные в ADDB индексируются по первичному ключу, скорость Query гораздо выше Scan, которая просто сканирует всю таблицу. Query доступна только на таблицах с первичным ключом hash-and-range. Я думаю, и могу ошибаться, что если вы используете в ADDB функцию Query, вы можете использовать фильтр только на атрибутах, из которых состоит первичный ключ, для фильтра по другим атрибутам же необходимо использовать Scan. В WATS для фильтра необходимо указать запрос с использованием WCF ($filter).
- Обе системы спроектированы с учетом высокой доступности, задерживая на тайм-аут ваши запросы и возвращая результаты по частям. Из документации непонятно, когда запрос будет задержан на тайм-аут (в ADDB). WATS задерживает на тайм-аут запрос после 5 секунд выполнения.
- В WATS возможно получить запрос назад, если сервис пересекает граничное значение PartitionKey.
- В ADDB существует ограничение в 1 Мб на размер ответа, например, максимальный размер ответа может быть 1 Мб. Если запрос может возвратить больший набор данных, будет возвращена часть результата.
- Вы можете получать все запрошенные записи либо часть результата, либо вообще не получать результат даже с учетом наличия соответствующих данных. Когда возвращается часть результата или пустой набор, вне зависимости от наличия данных, соответствующих запросу, сервис всегда возвратит continuation token. Таким образом разработка логики обработки этого continuation token в приложении очень важна.
- Обе системы позволяют возвратить все атрибуты либо часть всех атрибутов в запросе. В ADDB вы определяете для этого параметр “AttributesToGet”. В WATS это можно реализовать с помощью имен атрибутов, которые вы хотите возвратить, в запросе $select, например, $select=PartitionKey,RowKey,Attribute1,…
Резюме
Резюмируя – обе системы сравнимы по функциональности. Есть некоторые различия в функциональности и, если разработчику держать их в уме в процессе разработки и планирования, вполне возможно создать систему, которая будет использовать оба сервиса, даже, возможно, с интеграцией. У каждой системы есть свои преимущества и недостатки и мы должны использовать эти преимущества и недостатки, чтобы решить, какая из систем лучше подойдет под наши нужды.
Автор: ahriman
