Лазурные таблицы или SQL Azure?

Ответ 1

Azure Table Storage выглядит дешевле, чем 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)

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

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

Ответ 2

Несмотря на аналогичные имена, SQL Azure Tables и Table Storage имеют очень мало общего.

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

• Хранилище таблиц, коэффициент затрат 100x
• Живые объекты в хранилище таблиц

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

Ответ 3

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

Ответ 8

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

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

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

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

Ответ 9

Интересно, сможем ли мы в конечном итоге с некоторыми "независимыми от поставщиков" облачными библиотеками api?

Ответ 10

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

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

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

Ответ 11

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