Когда следует использовать Sql Azure и когда следует использовать табличное хранилище?

Когда я должен использовать Sql Azure и когда следует использовать хранилище таблиц? Я думал, использовать табличное хранилище для сценариев обработки транзакций, например. дебетовым кредитным счетам типа сценария и использовать Sql Azure, когда данные не будут использоваться для транзакционных целей, например, для отчетности. Как вы думаете?

ОТВЕТЫ

Ответ 1

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

Можно рассмотреть несколько измерений: С другой стороны, SQL Azure относительно дорогая для гигабайта памяти, не масштабируется супер хорошо и ограничена 150gigs/database, однако, и это очень важно, транзакции не взимаются с SQL Azure, и ваши разработчики уже знают, как с этим бороться.

ATS - другое животное все вместе. Способный к мега-масштабируемости, он дешевый для хранения, но ему дорого стоить. Это также требует значительного количества мощности процессора от ваших узлов для управления. Это в основном заставляет ваши вычислительные узлы стать мини-серверами db, поскольку делегирование всей реляционной активности передается им.

Таким образом, на мой взгляд, часто доступным данным, которые не нуждаются в огромной масштабируемости и не имеют большого размера, должно быть предназначено для SQL Azure, иначе Azure Table Services.

Ваш конкретный пример - транзакционные данные из финансовых транзакций - идеальное место для ATS, а метаданные (профили аккаунтов, имена, адреса и т.д.) идеально подходят для SQL Azure.

Ответ 2

Игорь и Марк дали отличные ответы. Позвольте мне добавить немного больше...

С SQL Database (ранее называемой SQL Azure) теперь вы можете иметь базы данных объемом до 500 ГБ. Чтобы выйти за рамки этого, вам нужно разбить ваши данные. Примечание. Первоначально я предложил осколки с SQL-федерациями, но с тех пор эта функция была удалена.

ATS предлагает транзакции на уровне раздела (транзакции группы лиц). См. эту статью MSDN для получения дополнительной информации. Это не так надежно, как транзакции SQL Azure, но позволяет выполнять пакетные операции в одной транзакции.

РЕДАКТИРОВАТЬ Прошло больше года с тех пор, как этот вопрос был задан (и ответил). Один из сравнительных моментов был в отношении ценообразования. Хотя SQL Azure по-прежнему дороже, чем ATS, стоимость SQL Azure значительно снизилась за последний год. Базы данных теперь имеют многоуровневые цены, начиная с 4,99 долл. США за 100 МБ, увеличиваясь до 225 долл. США за 150 ГБ (большое снижение от цены за 9,99 долл./ГБ с прошлого года. Подробные данные о ценах здесь.

EDIT Aug 2014 Еще через год, еще одно обновление. В то время как сети/бизнес-уровни продолжают существовать, они затягиваются (и SQL-федерации больше недоступны). Теперь доступны новые уровни Basic, Standard и Premium (подробнее см. здесь).

Ответ 3

Некоторые из этих ответов не кажутся завершенными, поэтому я добавлю свои 2 цента.

Лазурная таблица Хорошие точки:

  • Сильная сторона - это способность хранить множество небольших данных; Таблица Azure основана на Azure Blob, но ориентирована на меньшие данные.
  • Намного дешевле Azure SQL Server
  • В любое время, когда вы знаете как ключ раздела, так и ключ строки, доступ к данным происходит очень быстро.
  • Entity transactions возможны, если вы помещаете две разные "схемы" в один и тот же ключ раздела.
  • Если общий размер строки меньше 980K (строка SQL)
  • Если каждое свойство МЕНЬШЕ 64 КБ (колонка SQL)
  • Он может действовать как бедный человек SQL.

Плохие точки таблицы Azure:

  • SQL является слабым местом. Не ожидайте использовать это на любой большой SQL-таблице или вы будете испытывать проблемы с производительностью.
  • Ограниченный SQL доступен, не ожидайте объединения любого типа, кроме того, что вы реализуете в Linq
  • Таблица Azure SQL не масштабируется, а также возможность хранить бесконечное количество данных
  • В любое время, когда вы не указываете ключ раздела и ключ строки в предложении WHERE, ожидайте медленного сканирования таблицы.
  • Ожидайте, что производительность сканирования таблицы ухудшится при добавлении большего количества строк.
  • Не ожидайте, что запросы таблицы Azue будут быстрыми, когда вы добавите больше строк.
  • Нижняя строка, если вы используете таблицу Azure, чтобы действовать как SQL, не добавляйте много данных. Если у вас много данных (гигабайт), просто не планируйте получать с него высокопроизводительные SQL-запросы. Вы будете экономить деньги, если вам не нужны эти обычные функции SQL.

Ответ 4

Когда дело доходит до транзакций, это просто наоборот: SQL Azure поддерживает транзакции; таблица хранения нет.

SQL Azure - это в основном SQL Server, работающий внутри Windows Azure, поэтому, если у вас есть существующее приложение, использующее SQL Server, SQL Azure обеспечивает хороший путь миграции. Тем не менее, существуют ограничения на то, насколько большой базы данных вы можете иметь на SQL Azure (в настоящее время 150 ГБ), поэтому существуют ограничения на то, насколько она может масштабироваться.

С другой стороны, хранение таблиц чрезвычайно масштабируемо, но требует другого способа мышления. Это не реляционная база данных. См. эта статья для приятного введения: http://msdn.microsoft.com/en-us/magazine/ff796231.aspx

Ответ 5

Реальный ответ: "Постарайтесь не использовать Azure Table Storage". Всякий раз, когда вы переходите от реляционной БД к базе данных без sql, вам, конечно же, придется изменить, как вы думаете о своей архитектуре хранения. Но проблемы с ОВД идут, а не просто "думать по-другому". Как отмечали другие люди, это не просто хранилище данных "Нет-SQL", это особенно низкоуровневый, ограниченный и очень низкопоставленный экземпляр хранилища No-SQL. Это не вопрос "думать по-другому" о САР; это вопрос ATS, не предоставляющий вам инструменты, необходимые для выполнения вашей работы - инструменты, которые предоставляют вам другие хранилища данных no-sql.

Единственное, что можно сказать о ATS, - это то, что вы можете быстро и легко вставлять в него много и много данных и с минимальными затратами на хранение. Тем не менее, вы в принципе не можете надеяться получить эти данные снова, если вам не повезло, чтобы иметь случай использования, который волшебным образом соответствует его модели хранения разделов-ключей/строк. Если вы этого не сделаете - и я подозреваю, что очень мало людей, вы будете делать много сканирования разделов и сами обрабатывать данные.

Кроме того, Azure Table Storage, похоже, находится в тупике с точки зрения разработки. Если вы посмотрите запрос "Вспомогательные вторичные индексы" на форумах обратной связи Azure (http://feedback.windowsazure.com/forums/217298-storage/suggestions/396314-support-secondary-indexes), вы увидите, что поддержка вторичных индексов была обещал еще в 2011 году, но прогресс не был достигнут. Также не было достигнуто никакого прогресса ни по одному из других верхних запросов для хранения таблиц.

Теперь я знаю, что Скотт Гатри - качественный парень, поэтому я надеюсь, что все это застое на фронте Table Storage является предисловием к Azure, фиксирующему его и придумывающим что-то действительно классное. Это моя надежда (хотя у меня нет доказательств этого случая). Но прямо сейчас, если у вас нет выбора, я настоятельно рекомендую использовать Azure Table Storage. Использовать Azure SQL; используйте собственный экземпляр MongoDB или какой-либо другой базы данных No-SQL; или использовать Amazon DynamoDB. Но не используйте Azure Table Storage.