Подходит ли SQL Azure для интенсивной обработки SQL? - PullRequest
4 голосов
/ 23 июля 2011

Я ищу несколько советов о том, является ли SQL Azure подходящей платформой для одноразовой, кратковременной интенсивной обработки пакета данных SQL. (то есть "хруст" данных)

Мой сценарий выглядит следующим образом:

У меня есть база данных 32 ГБ, содержащая одну таблицу данных. Таблица содержит пространственные данные, определенные с использованием типа данных geometry, а также различные столбцы связанных атрибутов. Мне нужно выполнить некоторую разовую обработку этих данных, которая включает в себя выполнение ряда вычислительно-дорогостоящих запросов (как, кажется, большинство пространственных запросов!)

Когда я проверил эти запросы на подмножестве данных на моем собственном сервере, они заняли несколько часов. Я ожидаю, что, если я попытаюсь выполнить их для всего набора данных локально, он заблокирует мой SQL Server на несколько дней (или, возможно, он умрет, пытаясь), что я пытаюсь избежать.

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

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

Просто чтобы прояснить -

  • Я ожидаю, что это будет разовая операция. Или, может быть, будет выполняться один раз в год.
  • После завершения обработки у меня нет намерений продолжать размещать данные «в облаке» - я бы хотел получить обработанный набор данных и снова разместить его на месте.
  • Простота получения данных на платформу и обратно с нее, очевидно, важна, поскольку я не стремлюсь постоянно «переносить» что-либо. Если я правильно понимаю, вы не сможете создавать резервные копии / восстанавливать базы данных в Azure, и создание сценариев для данных будет очень болезненным.
  • Мне комфортно с Management Studio, и любая платформа, которая позволяла мне использовать это как интерфейс для выполнения запросов и выборочной проверки результатов, была бы полезна.

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

Ответы [ 3 ]

1 голос
/ 23 июля 2011

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

База данных SQL Azure предоставляет крупномасштабную многопользовательскую службу базы данных на общих ресурсах.Чтобы обеспечить хорошее взаимодействие со всеми клиентами базы данных SQL Azure, ваше подключение к службе может быть закрыто из-за следующих условий:

  • Чрезмерное использование ресурсов
  • Длительные запросы
  • Отдельные длительные транзакции между операторами BEGIN TRAN и END TRAN
  • Свободные соединения

Это отличается от того, как локальный экземпляр SQL Serverработает.

от: http://msdn.microsoft.com/en-us/library/ee730903.aspx

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

Если SQL Azure не может работать для вас, то для вас может быть лучше развернуть отдельный экземпляр SQL где-нибудь (возможно, для экземпляра AWS?), Чтобы выполнить эти одноразовые вычисления.

0 голосов
/ 04 октября 2011

Несколько вопросов / вопросов:

  1. Код, который вы выполняете, написан на T-SQL или на каком-либо другом языке программирования?
  2. Может ли обработка выполняться параллельноили он должен быть последовательным?
  3. Где сейчас узкие места?Это в вычислениях или в поиске / хранении данных?

Учитывая то, что вы сказали до сих пор, и проблемы, которые я видел в прошлом с большими базами данных, я бы задал вопрос, является ли SQL Server подходящим хранилищемтехнологии на всех.Правда, он предназначен для транзакционных запросов, но у вас есть только одна таблица базы данных.Это означает, что весь аспект «реляционной базы данных» выходит из окна, если только он сам не ссылается (что может создать мир других проблем, поэтому я пока проигнорирую это и предположу, что это не так).Конечно, есть способы убедиться, что вы не столкнетесь с условиями гонки при обработке данных с использованием хранилища NoSQL, и я не могу представить, что транзакции будут абсолютно необходимы.При выполнении вычислений, если не удается сохранить результат, повторите попытку.В худшем случае вы переделываете вычисления.

32 ГБ данных для SQL Server в одной таблице - это МНОГО данных, и я предполагаю, что там, вероятно, есть какие-то индексы.Если ваш SQL Server не настроен должным образом (с использованием большого количества физических шпинделей и распределением данных между ними), вы можете легко столкнуться с серьезными проблемами производительности в SQL из-за дискового ввода-вывода.

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

Мой совет - изучить использование таблиц Azure (в основном это NoSQL).таблица), потому что это позволит вам разделить данные на несколько узлов.Такое разбиение позволяет вам масштабировать объем хранимых данных до 100 ТБ, не снижая при этом скорость запросов.

Кроме того, база данных SQL Azure 32 ГБ обойдется вам в 400 долларов в месяц, а хранилище таблиц Azure 40 ГБ с5 миллионов транзакций с хранилищем обойдутся вам всего в 11 долларов в месяц.Вам нужно будет добавить «стоимость» рабочих узлов, но теоретически они должны быть эквивалентны.Таким образом, опция «Таблицы» дешевле в месяц, но если это бизнес, поддерживающий проект, тогда стоимость, вероятно, будет намного меньше, чем время, затрачиваемое на его разработку.

Вам нужно будет учесть время, которое нужно потратить32 ГБ данных в облако.Загрузка базы данных SQL может занять довольно много времени, и вам каким-то образом понадобится получить данные там.Зависит от того, насколько быстро вы можете направить данные в облако, и сможете ли вы начать обработку до того, как все это будет сделано.

Проблема, с которой я столкнусь, заключается в том, чтобы использовать таблицы Azure вместо SQLAzure, вам нужно будет сделать некоторые компромиссы.Скорее всего, вам потребуется преобразовать данные в таблицы Azure, затем написать код обработки и т. Д. В конце концов, это может не стоить этого.

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

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

Я не хочу давать здесь ответ "все зависит", но если вы дадите некоторые дополнительные детали,Я был бы рад обновить это и дать вам лучшее представление о том, куда идти и что делать.

0 голосов
/ 23 июля 2011

Зависит от характера рабочей нагрузки.Вы упоминаете «выполнение ряда вычислительно дорогих запросов»;однако мне не ясно, если у вас много маленьких, но повторяющихся команд или одна большая работа, которая должна работать в течение всего периода выполнения пакета.Первый может работать в SQL Azure в форме логики повторных попыток подключения, а второй - нет.В любом случае вы также можете рассмотреть возможность рефакторинга логики обработки в .NET.

Действительно, большинство операций пакетной обработки перераспределяются в облаке как рабочие процессы благодаря механизму регулирования SQL Azure;в основном код .NET запускается в Windows Azure, считывает необходимые данные из SQL Azure, выполняет необходимые вычисления в памяти и сохраняет результаты обратно в SQL Azure.В зависимости от типа рабочей нагрузки, это, вероятно, лучший подход, так как вы можете разработать его таким образом, чтобы он хорошо масштабировался;следовательно, это может существенно сократить общее время выполнения (при условии, что вы можете разбить логику обработки данных на более мелкие части и выполнить ее в .NET вместо SQL Azure).

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

...