В этой статье приводится сравнение двух сервисов структурированного хранилища, поддерживаемых Windows Azure: Windows Azure Table Storage и Windows Azure SQL Database, ранее известного как SQL Azure. Целью данной статьи является сравнение этих технологий для того, чтобы вы могли понять их общие и различные характеристики. Это сравнение поможет вам вынести более обоснованное решение о том, какая из технологий будет лучше подходить под реализацию вашего сценария.
Введение
Когда речь заходит о постоянном хранении данных в Windows Azure, возникает два варианта облачных технологий: Windows Azure SQL Database и Windows Azure Table Storage.
Windows Azure SQL Database является сервисом реляционных баз данных, расширяющих базовую функциональность SQL Server в облако. С SQL Database вы можете разворачивать в облаке решения реляционных баз данных, и преимущества этого подхода включают в себя управляемую инфраструктуру, высокую доступность, масштабируемость, знакомую модель разработки и различные фреймворки и утилиты доступа к данным — все похоже на то, что мы видим с традиционной средой SQL Server. SQL Database также предлагает функциональность миграции, экспортирования и синхронизации в реальном времени локальных баз данных SQL Server с базами данных в Windows Azure SQL (с использованием SQL Data Sync).
Windows Azure Table Storage — это отказоустойчивый, сертифицированный по ISO 27001 сервис хранилища NoSQL (ключ-значение), который может быть полезным для приложений, хранящих большие объёмы нереляционных данных, для которых необходимы дополнительные структуры. Этот сервис предоставляет доступ на основе ключей к данным, у которых отсутствует схема. При этом, если хранить структурированные данные без схемы, нельзя создать отношения между данными.
Несмотря на ощутимые различия, оба сервиса являются высокодоступными управляемыми сервисами, для которых предоставляется 99.9% месячный SLA.
Table Storage vs. SQL Database
Как и SQL Database, Windows Azure Table Storage хранит структурированные данные. Основным различием между двумя сервисами является то, что SQL Database является системой управления реляционными базами данных на основе движка SQL Server и построена на стандартных принципах и основах реляционности, таким образом предоставляя такие возможности, как запросы Transact-SQL, транзакции ACID, хранимые процедуры, выполняемые на стороне сервера.
Windows Azure Table Storage — гибкое хранилище сущностей ключ-значение, которое позволяет быстро создать облачное приложение без замыкания модели данных приложения на конкретный набор схем. Этот сервис не является хранилищем реляционных данных и не даёт таких возможностей по управлению реляционными данными, как SQL Database (например, join-ов и хранимых процедур). Windows Azure Table Storage имеет ограниченную поддержку запросов на стороне сервера, но имеет функции транзакций. Кроме этого, разные записи внутри одной таблицы могут иметь разную структуру, и такой подход в Windows Azure Table Storage позволяет эффективно хранить и оперировать простыми реляционными данными.
Если ваше приложение хранит и оперирует большими массивами данных, для которых нет необходимости в использовании реляционных функций, Windows Azure Table Storage может быть более подходящим вариантом. Если же ваше приложение нуждается в обработке наборов данных, объединённых какими-либо схемами, SQL Database выглядит как более подходящий вариант, нежели Windows Azure Table Storage. Есть еще несколько факторов, которые необходимо учитывать перед тем, как решить, использовать SQL Database или Windows Azure Table Storage, некоторые из которых перечислены далее.
Соображения по выбору технологии
При определении технологии хранения данных, подходящей для конкретного решения, архитектору и разработчику необходимо учитывать следующие рекомендации:
Рассматривайте возможность использования Windows Azure Table Storage, когда:
· Ваше приложение должно хранить большие массивы данных (например, многие терабайты) в дешевом хранилище.
· Ваше приложение хранит и оперирует большими массивами данных, не имеющими сложных реляционных отношений, для которых необходимо использовать join-ы на стороне сервера, вторичные индексы или какую-то сложную логику, выполняющуюся на стороне сервера.
· Ваше приложение нуждается в гибкой схеме данных для хранения неоднородных по своей схеме объектов, структуру которой затруднительно определить на стадии проектирования.
· Вашему бизнесу нужны возможности по сохранению данных в случае катастрофических ситуаций с использованием географической разнесённости. Таблицы Windows Azure географически реплицируются по двум датацентрам, находящимся за несколько сотен миль друг от друга, но на одном континенте, что предоставляет дополнительную уверенность в сохранности данных в случае катастрофы.
· Вам нужно хранить более чем 150 Гб данных без использования шардинга или партиционирования.
· Вам нужен высокий уровень масштабирования без ручного шардинга данных.
Рассматривайте возможность использования Windows Azure SQL Database, когда:
· Ваше приложение выполняет обработку данных, у которых есть высокая степень структурированности с отношениями и схемы.
· Ваши данные по сути своей реляционны и нуждаются в реализации ключевых принципов программной модели реляционных данных для обеспечения целостности данных за счет правил уникальности данных, ограничений и различных типов ключей.
· Объем ваших данных может не превышать на одну выделенную единицу хранилища (базу данных) 150 Гб, однако вы можете партиционировать ваши данные на несколько баз данных при превышении этого лимита, который может быть изменен в будущем.
· Ваши существующие приложения, ориентированные на использование данных, уже используют SQL Server, вам же нужен доступ в облачное хранилище с использованием существующих фреймворков и возможность прозрачной миграции между локальной инфраструктурой и Windows Azure.
· Вы планируете использовать в вашем приложении хранимые процедуры T-SQL для осуществления вычислений внутри слоя данных, таким образом минимизируя количество round trips между приложением и хранилищем данных.
· Ваше приложение должно использовать spatial data, различные типы данных и паттерны доступа к данным с объединениями, агрегированием и сложными предикатами.
· Ваше приложение обеспечивает визуализацию и BI моделей данных с использованием утилит.
 Примечание |
| Много приложений в Windows Azure могут воспользоваться преимуществами обеих технологий, однако рекомендуется использование их в связке. |
Сравнение Windows Azure Table Storage и SQL Database
В таблицах ниже сгруппированы факторы сравнения обоих сервисов.
Основные возможности
В этом разделе сравниваются основные возможности, предоставляемые Windows Azure Table Storage и SQL Database.
| Критерий сравнения | Windows Azure Table Storage | SQL Database |
| Отношения между данными | Нет
Windows Azure Table Storage не предоставляет методов для создания отношений между данными. Вместо этого можно реализовать простые связи с использованием безсхемных свойств таблиц и структурирования данных в определенном формате. |
Да
Аналогично SQL Server, SQL Database позволяет определить отношения между данными, хранящимися в разных таблицах, с использованием внешних ключей. |
| Обработка на стороне сервера | Нет
Поддерживаются операции: insert,update, delete, select, не поддерживаются: объединения, внешние ключи, хранимые процедуры, триггеры, обработка на стороне сервера. |
Да
Стандартный набор функций SQL Server — хранимые процедуры, представления, сложные индексы, объединения, агрегирование. |
| Поддержка транзакций | Ограниченная
Поддерживаются транзакции в пределах одной таблицы и одной партиции, в транзакции — до 100 операций, при этом поддерживается оптимистичный параллелизм. |
Да
Поддерживаются традиционные ACID-транзакции внутри одной БД, между БД — не поддерживаются. Поддерживается оптимистичный параллелизм. |
| Географическая репликация | Да
По умолчанию таблица реплицируются в другие датацентры в пределах региона. |
Нет
На данный момент SQL Database не реплицируется в другие датацентры в пределах региона. |
| Схема в таблице | Relaxed
Каждая запись может иметь свой набор свойств. |
Управляемая
Схема определяется, но может быть изменена в любой момент, все записи должны соответствовать этой схеме. Рассмотрите возможность использования XML-типа или sparse-столбцов для дополнительной гибкости. |
| Сравнимо ли с существующими локальными хранилищами данных | Нет
Локальных альтернатив облачному хранилищу нет. |
Да
Аналог SQL Server с определенными ограничениями — General Guidelines and Limitations. |
| Вертикальное масштабирование | Автоматическое
Партицируется на основе свойства PartitionKey. Таблица может храниться в разных партициях на разных устройствах, что позволяет клиентам осуществлять параллельный доступ. |
Ручное
Шардинг между группой БД с использованием SQL Federations или собственного подхода к шардингу. |
| Типы данных | Простые
См. таблицу в «Дополнительная информация». |
Простые, сложные, определенные пользователем
SQL Database поддерживает большой набор типов данных, включая возможность определения типа пользователем. |
Дополнительная информация
· При создании таблицы у вас нет ни одного столбца и таблица сама по себе не структурированна и не имеет схемы. Имена столбцов являются частями записей, хранящихся в таблице, и могут быть различными для различных записей внутри одной таблицы. Таблица может даже состоять из двух сущностей с одним именем свойства, но разными типами, однако имена свойств должны быть уникальными внутри одной записи.
· Windows Azure Table Storage не поддерживает реляционность — объединения и агрегирования в запросах и транзакциях. Сущности с одним ключом партиции обслуживаются вместе в одном хранилище, и можно эффективно оперировать этими данными, а также модифицировать их в пределах одного запроса с использованием Entity Group Transactions.
· Есть некоторые ограничения, которые необходимо учитывать при использовании entity group transaction, например, максимальный размер пакета в 4 Мб и то, что все сущности в пакете должны иметь один ключ партиции.
· Windows Azure Table Storage предоставляет один кластерный индекс, а результаты всегда сортируются по значениям PartitionKey и RowKey, в порядке возрастания. Значения PartitionKey и RowKey уникально идентифицируют каждую запись в таблице и, если вы попробуете создать две записи с одинаковыми значениями этих свойств, будет выброшено исключение.
· Критерий пропускной способности — сложное уравнение со многими переменными, включающими в себя типы запросов и их сложность, паттерны доступа к данным, размер набора результатов, расстояние до инфраструктуры хранилища и сетевые задержки, поэтому хорошим советом является постоянно тестировать производительность и оценивать различные факторы, учитывая особенности конкретных приложений. Подробнее про best practices для таблиц: post.
· В таблицу ниже сведены поддерживаемые таблицами типы данных для свойств. Поддерживаемые типы данных для SQL Database: Data Types (Windows Azure SQL Database).
| Тип | Подробности |
| Binary | Массив байт до 64 KB. |
| Bool | Boolean. |
| DateTime | 64-битное значение UTC time. Диапазон значений от 1/1/1601 до 12/31/9999. |
| Double | 64-битное значение с плавающей точкой. |
| GUID | 128-битный GUID. |
| Int | 32-битный integer. |
| Int64 | 64-битный integer. |
| String | Значение в UTF-16 до 64 Кб. |
Продвинутые возможности
| Критерий сравнения | Windows Azure Table Storage | SQL Database |
| Доступно из локальных приложений или других платформ (кроме Windows Azure) | Да | Да |
| Модель согласованности | Строгая | Строгая |
| Поддержка Windows Communication Foundation (WCF) Data Services | Да | Да |
| Поддержка REST | Да
Поддержка по умолчанию. |
Да
Поддержка доступа на основе REST с помощью добавления слоя OData поверх БД . |
| Защита брандмауэром (ограничение по IP) | Нет | Да
Используется брандмауэер Windows Azure, конфигурируемый с портала или через консоль. |
| Transaction throttling behavior | Да
Подробнее — blog post. |
Да
Подробнее — статья. |
| Устойчивость к ошибкам | Да
Для обеспечения высокого уровня отказоустойчивости хранимые данные реплицируются в три копии внутри региона и еще в три копии в другой датацентр в этом же регионе. |
Да
В датацентре хранится три копии каждого экземпляра SQL Database. |
| Логирование и метрики | Да
Подробнее — blog post. |
Нет |
| Логи транзакций | Нет | Да
Размер лога транзакций ограничен 10 Гб с лимитом 1 Гб на одну транзакцию. |
Дополнительная информация
· Вы можете ограничить доступ к экземпляру SQL Database на сетевом уровне с помощью встроенного брандмауэра, сконфигурировав его правила на портале управления. К таблицам может подключиться же любой клиент, который может подключиться по HTTP/HTTPS к хранилищу Windows Azure.
· Windows Azure Table Storage предоставляется гарантии для всех транзакций вставки, обновления и удаления одной записи и для Entity Group Transaction. Для каждого запроса предоставляется Snapshot isolation. Запрос управляет представлением партиции с начала выполнения запроса и во время выполнения транзакции. За согласованность между несколькими таблицами отвечают разработчики приложения.
· Windows Azure Tables поддерживает логирование, позволяя вам видеть все выполняемые запросы. Логирование также предоставляет агрегированные метрики для запросов.
· Windows Azure SQL Database на данный момент не предоставляет логирования и метрик, имея, однако, набор dynamic management views (DMV), полезных для диагностики проблем с производительностью выполнения запросов, мониторинга подключений к БД, просмотра активных транзакций и изучения планов выполнения запросов.
· Так как Windows Azure SQL Database создана на основе движка SQL Server, некоторые концепции имеют место быть, например, TempDB и логи транзакций. Для предотвращения неконтролируемого разрастания лога транзакций, SQL Database накладывает лимит в 10 Гб на размер лога. Инфраструктура SQL Database управляет этими логами, к которым нет прямого доступа. В Windows Azure Table Storage же нет эквивалента этим логам, вместо этого там есть логирование и метрики, которые, правда, отслеживают запросы, но не изменяемые данные.
· Для предотвращения чрезмерного использования ресурсов в мультитенантной среде оба сервиса используют механизм throttling, который, однако, различается по принципам работы у этих сервисов. Например, SQL Database использует две стратегии throttling: soft throttling и hard throttling, о которых можно почитать здесь.
Емкость и квоты
| Критерий сравнения | Windows Azure Table Storage | SQL Database |
| Максимальный размер записи | 1 Мб
Не более 255 свойств, в которые включены три обязательных: PartitionKey,RowKey, Timestamp. |
2 Гб
До 1024 столбцов (30,000 если используются sparse-столбцы). Использование varchar(max), varbinary(max),xml, text, и image позволяет использовать дополнительно 2 Гб. |
| Максимальный размер данных | 100 Тб на таблицу
Один аккаунт хранилища (с таблицами, блобами и очередями) может быть до 100 Тб в размере, максимальный размер таблицы — 100 Тб. |
150 Гб на БД
Несмотря на возможность увеличения верхнего ограничения размера БД в будущем, обратите внимание на SQL Federations. |
| Максимальное количество записей, возвращаемых в одном запросе | 1,000
Не более 1000 записей в одном запросе. Если в результате больше этого количества, возвращается токен продолжения. |
Неограничено
Если неправильно настроить, может возникнуть проблема с ограничением количества из-за таймаутов запроса и подключения. |
Дополнительная информация
· Windows Azure Table Storage использует токен продолжения в заголовке ответа для того, чтобы указать, что в наборе данных более 1000 записей. Этот токен можно использовать для получения оставшихся данных. Для каждого запроса имеется snapshot consistency, тогда как для запросов с токенами продолжения — нет.
· Общий размер всех свойств в записи таблицы не может превышать 1 Мб, и в этот лимит входит размер имен свойств и их значения, в которые также входят обязательные свойства PartitionKey и RowKey.
· SQL Database на даннйы момент поддерживает БД размером от 5 Гб (в Web-редакции) до 150 Гб (в Business-редакции). Разработчик должен контролировать размер данных, чтобы он оставался в пределах этих ограничений, так как сконфигурированный размер БД не увеличивается по мере увеличения объема данных.
· Количество столбцов в простой таблице SQL Database ограничено 1024 (аналогично локальному SQL Server), с sparse-столбцами же таблица может содержать до 30 000 столбцов, 1023 из которых могут быть не sparse, 28976 же должны быть sparse.
Управление
| Критерий сравнения | Windows Azure Table Storage | SQL Database |
| Протокол управления и утилиты | REST поверх HTTP/HTTPS
Вы можете использовать Windows Azure Storage Explorer или стороннюю утилиту типа Cloud Storage Studio. |
ODBC/JDBC
REST поверх HTTP/HTTPS Вы можете использовать портал управления или SQL Server Management Studio. |
| Доступ к данным | OData
Вы можете получить доступ к данным с использованием HTTP(S) REST API или .NET Client Library for WCF Data Services, находящейся в составе Windows Azure SDK. |
ODBC/JDBC
Вы можете использовать приложения, написанные с использованием традиционных технологий доступа к данным, таких как ADO.NET и ODBC, которые могут осуществлять коммуникации с SQL Server для доступа к экземпляру SQL Database с минимальными изменениями в коде. |
| Поддержка Java API | Да | Да |
| Поддержка
Node.js API |
Да | Да |
| Поддержка
PHP API |
Да | Да |
| Поддержка
LINQ |
Да | Да |
| Поддержка
Python |
Да | Нет |
| Оффлайн-разработка | Да
Наличие локального эмулятора хранилища из состава Windows Azure SDK. |
Нет
SQL Express и другие редакции SQL Server — другие продукты, не предоставляющие полной эмуляции облачной среды Windows Azure SQL Database . |
Дополнительная информация
· Хотя SQL Database и может быть эмулирована локальной установкой SQL Server, этот подход не позволит сымитировать ситуацию, специфичную для облачного сервиса, например, throttling и другие ограничения.
· Windows Azure SQL Database предоставляет среду интерактивного выполнения запросов. Получить доступ к SQL Database можно также из консольных утилит, например, SSMS или сторонних утилит, поддерживающих ODBC.
· Возможности T-SQL у SQL Server и SQL Database разнятся — некоторые функции ограничены или вообще не поддерживаются, некоторые же имеют существенные различия (такие, как создание БД и Federations).
Аутентификация и авторизация
| Критерий сравнения | Windows Azure Table Storage | SQL Database |
| Аутентификация | Симметричный ключ
Shared Access Signatures Для аутентификации пользователей используется 512-битный HMAC ключ. |
SQL-аутентификация
Для аутентификации пользователей используется стандартная SQL-аутентификация. |
| Доступ на основе ролей | Нет | Да
Поддерживаются стандартные роли БД и приложения для SQL. |
| Windows Azure Active Directory (бывший ACS) | Нет | Нет |
| Федерация с провайдером идентификации | Нет | Нет |
Дополнительная информация
· Ролевая модель доступа, поддерживаемая SQL Database, предоставляет полный спектр возможностей по настройке различных режимов: read-only, write-only, read-write.
· Так как ни один из сервисов пока не поддерживает федеративную, на основе сертификатов или Active Directory, аутентификацию, вы должны убедиться, что учетные данные достаточно защищены, например, зашифрованы.
· Windows Azure Table предоставляет возможность подписывать URL-ы с помощью Table SAS (Shared Access Signature). SAS позволяет вам выдать доступ на время без выдачи секретного ключа к аккаунту.
Стоимость
| Критерий сравнения | Windows Azure Table Storage | SQL Database |
| Стоимость хранилища | $0.125
за гигабайт в месяц, вычисляется на основе дневной нагрузки. |
Вычисляется на основе размера БД. |
| Стоимость транзакции | $0.01
за 100,000 транзакций. |
$0.00
В SQL Database транзакции не оплачиваются. |
| Оплачиваемые операции | Все
К стоимости хранилища добавляется стоимость транзакций. |
Никакие
Стоимость не зависит от количества транзакций, только от размера БД. |
| Стоимость исходящего трафика | $0.12 — $0.19
за гигабайт, зависит от региона |
$0.12 — $0.19
за гигабайт, зависит от региона |
Дополнительная информация
· Стоимость исходящего трафика вычисляется на основе полного количества данных, выходящего за пределы датацентра в Интернет. Количество считается за определенный период.
· В отличие от SQL Database, Windows Azure Table Storage налагает дополнительные расходы за транзакции. Эта модель оплаты означает, что вы должны учитывать частоту выполнения транзакций как фактор, влияющий на общую стоимость.
Вывод
Решение о том, использовать в вашем случае Windows Azure Table Storage или Windows Azure SQL Database, зависит от многих факторов, которые, в свою очередь, сильно зависят от конкретных характеристик вашего приложения, его архитектуры, типа нагрузки, паттернов доступа к данным.
Windows Azure Table Storage поддерживает возможнось хранения больших объемов данных в масштабируемом облачном хранилище, до многих терабайт и миллиардов записей. Для реализации подобного уровня масштабирования Windows Azure Table Storage использует модель вертикального масштабирования для распределения записей между несколькими узлами хранилища — сервис использует модель NoSQL для поддержки подобного уровня масштабирования со строгой согласованностью. Если вам нужно дешевое хранилище, в котором можно хранить огромные объемы нереляционных или простых данных, рассматривайте возможность использования Windows Azure Table Storage.
Рассматривайте возможность использования Windows Azure SQL Database как расширяющего ваш локальный SQL Server в облако, при этом предлагающего знакомый инструментарий, поддержку ACID транзакций с различными уровнями изоляции и возможности обработки сложных данных. Если ваши данные реляционны и вам необходимо учитывать это в управлении ими, SQL Database может быть лучшим вариантом для использования.
Обратите внимание, что решение может не заключаться в выборе какой-то одной технологии — вы можете решить о том, как правильно использовать обе технологии в вашем конкретном сценарии наилучшим на то способом.
Автор: ahriman
