Таблицы Azure или SQL Azure?

Хранилище таблиц Azure кажется менее дорогим, чем SQL Azure. Кроме того, он лучше масштабируется, чем SQL Azure.

С SQL Azure проще работать, если вы много работали с реляционными базами данных. Если вы переносили приложение, которое уже использовало базу данных SQL, то перенос его в SQL Azure был бы очевидным выбором, но это единственная ситуация, когда я бы рекомендовал его.

Основным ограничением Azure Tables является отсутствие вторичных индексов. Об этом было объявлено на PDC '09, и в настоящее время указано, что это произойдет в ближайшее время, но пока не было объявлено о сроках. (См. http://windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes?ref=title)

Я видел предлагаемое использование гибридной системы, в которой вы используете хранилище таблиц и BLOB-объектов для большей части своих данных, но используете SQL Azure для индексов, поиска и фильтрации. Однако у меня еще не было возможности попробовать это решение самостоятельно.

После того как вторичные индексы будут добавлены в хранилище таблиц, оно, по сути, станет облачной системой NoSQL и будет быть гораздо полезнее, чем сейчас.

Несмотря на схожие названия, таблицы SQL Azure и хранилище таблиц имеют очень мало общего.

Вот две ссылки, которые могут вам помочь:

• Хранилище таблиц, стократное увеличение стоимости
• Fat Entities в Table Storage

По сути, первый вопрос, который следует задать: Действительно ли мое приложение нуждается в масштабировании? Если нет, выберите SQL Azure.

Для тех, кто пытается сделать выбор между двумя вариантами, обязательно учтите в уравнении требования к отчетности. Отчеты SQL Azure и другие продукты для создания отчетов поддерживают SQL Azure по умолчанию. Если вам нужно создавать сложные или гибкие отчеты, вам, вероятно, следует избегать Table Storage.

Таблицы Azure дешевле, проще и лучше масштабируются, чем SQL Azure. SQL Azure — это управляемая среда SQL, многопользовательская по своей природе, поэтому вам следует проанализировать, соответствуют ли ваши требования к производительности SQL Azure. Была анонсирована расширенная версия SQL Azure, и на момент написания этой статьи она находится в предварительной версии (см. ЗДЕСЬ).

Я думаю, что решающими факторами для выбора между SQL Azure и таблицами Azure являются следующие:

• Вам нужно выполнять сложные соединения и использовать вторичные индексы? Если да, SQL Azure — лучший вариант.
• Вам нужны хранимые процедуры? Если да, SQL Azure.
• Вам нужны возможности автоматического масштабирования? Таблицы Azure — лучший вариант.
• Размер строк в таблице Azure не может превышать 4 МБ. Если вам нужно хранить большие данные в строке, лучше хранить их в хранилище больших двоичных объектов и ссылаться на URI большого двоичного объекта в строке таблицы.
• Вам нужно хранить огромные объемы полуструктурированных данных? Если да, таблицы Azure предпочтительнее.

Хотя таблицы Azure чрезвычайно выгодны с точки зрения простоты и стоимости, необходимо учитывать некоторые ограничения. См. ЗДЕСЬ некоторые начальные рекомендации.

Еще одно соображение — задержка. Раньше Microsoft запускала сайт с микробенчмарками пропускной способности и задержки для различных размеров объектов с хранилищем таблиц и SQL Azure. Поскольку этот сайт больше не доступен, я просто дам вам приблизительное представление из того, что я помню. Хранилище таблиц, как правило, имеет гораздо более высокую пропускную способность, чем SQL Azure. SQL Azure обычно имеет меньшую задержку (до 1/5).

Уже упоминалось, что table store легко масштабируется. Однако SQL Azure также можно масштабировать с помощью федераций. Обратите внимание, что федерации (фактически сегментирование) значительно усложняют ваше приложение. Я также не уверен, насколько сильно Federations влияет на производительность, но я полагаю, что есть некоторые накладные расходы.

Если непрерывность бизнеса является приоритетом, рассмотрите это с Azure Storage вы получаете дешевую георепликацию по умолчанию. С помощью SQL Azure вы можете сделать нечто подобное, но с большими усилиями с помощью SQL Data Sync. . Обратите внимание, что синхронизация данных SQL также приводит к снижению производительности, поскольку для отслеживания изменений данных требуются триггеры во всех ваших таблицах.

Я понимаю, что это старый вопрос, но все еще очень актуальный, поэтому я добавляю на него свой ответ.

CoderDennis и другие указали на некоторые факты: таблицы Azure дешевле, а таблицы Azure могут быть намного больше, эффективнее и т. д. Если вы на 100 % уверены, что будете придерживаться Azure, выбирайте таблицы.

Однако это предполагает, что вы уже выбрали Azure. Используя Azure Tables, вы замыкаетесь на платформе Azure. Это означает написание кода, очень специфичного для Azure Tables, который не просто будет перенесен на Amazon, вам придется переписать эти области вашего кода. С другой стороны, программирование для базы данных SQL с помощью LINQ будет намного проще переносить в другую облачную службу.

Это может не быть проблемой, если вы уже определились с облачной платформой.

Я предлагаю рассмотреть Azure Cache в сочетании с Azure Table. Одна только таблица имеет задержку 200-300 мс, с периодическими всплесками выше, что может значительно замедлить время отклика / интерактивность пользовательского интерфейса. Cache + Table кажется мне выигрышной комбинацией.

По вашему вопросу я хочу поговорить о том, как решить с помощью логики, выбрать таблицу SQL и какую из них нужно использовать таблицу Azure.

Как мы знаем, SQL Table — это механизм реляционной базы данных. но если у вас есть большие данные в одной таблице, таблица SQL неприменима, потому что SQL-запрос получает большие данные медленно.

В настоящее время вы можете выбрать Azure Table, запрос Azure Table настолько быстр, что SQL Table для больших данных, например, на нашем веб-сайте кто-то подписался на много статей, мы делаем статью как фид для пользователя, у каждого пользователя есть копия название статьи и описание, поэтому в таблице статей много данных, если мы используем таблицу SQL, выполнение каждого запроса может занять более 30 секунд. Но в Azure Table получить ленту статей пользователей с помощью PartitionKey и RowKey очень быстро.

Из этого примера вы можете узнать, как выбирать между таблицей SQL и таблицей Azure.

Интересно, со временем мы получим некоторые «независимые от поставщика» облачные API-библиотеки?

Я думаю, что вы должны сначала определить, что такое воронки использования вашего приложения. Будет ли ваша модель данных подвергаться частым изменениям или она будет стабильной? Вы должны иметь возможность выполнять сверхбыстрые вставки и чтения не так сложно? Вам нужен предварительный поиск Google? Хранение BLOB-объектов?

Это вопросы (и не только), которые вы должны задать и ответить себе, чтобы решить, будете ли вы, скорее всего, использовать подход NoSql или SQL для хранения ваших данных.

Учтите, что оба подхода могут легко сосуществовать и могут быть расширены с помощью хранилища BLOB.

И Azure Tables, и SQL Azure — это два разных зверя. Оба предназначены для разных сценариев, один недостаток azure table заключается в том, что вы не можете перейти с azure на любую другую платформу, если только вы не напишете в своем коде поставщиков, которые могут обрабатывать такие сдвиги.