База данных Azure SQL и MS SQL Server на выделенной машине

В настоящее время я запускаю экземпляр MS SQL Server 2014 (12.1.4100.1) на выделенном компьютере, который я арендую за 270 долларов США в месяц, со следующими характеристиками:

Процессор Intel Xeon E5-1660 (шесть физических ядер 3,3ghz + hyperthreading + turbo- > 3.9ghz)
64 ГБ зарегистрированной памяти DDR3 ECC
240 ГБ Intel SSD
Передача полосы пропускания 45000 ГБ.

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

Я запускал несколько наборов запросов бок о бок, один против базы данных на выделенной машине, и один из базы данных P2 Azure SQL. Результаты были шокирующими: моя выделенная машина превосходила (с точки зрения времени выполнения) Azure db огромным запасом каждый раз. Как правило, выделенный экземпляр db заканчивается в пределах от 1/2 до 1/3 времени, которое потребовалось для выполнения Azure db.

Теперь я понимаю много преимуществ платформы Azure. Он управлялся по сравнению с моей не управляемой установкой на выделенном компьютере, у них есть восстановление в определенный момент времени лучше, чем у меня, брандмауэр легко настраивается, гео-репликация и т.д. И т.д. Но у меня есть база данных с сотни таблиц с десятками и сотнями миллионов записей в каждой таблице, а иногда приходится запрашивать несколько стыков и т.д., так что производительность с точки зрения времени выполнения действительно имеет значение. Я просто нахожу это шокирующим, что услуга в $930/month работает плохо, рядом с арендой выделенных машин стоимостью 270 долларов США в месяц. Я все еще довольно новичок в SQL в целом и очень новичок в серверах и т.д., Но разве это не похоже на кого-то еще? Кто-нибудь, возможно, имеет некоторое представление о том, чего я здесь не вижу, или другие "управляемые" функции базы данных Azure SQL, которые, как предполагается, составляют разницу в цене?

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

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

EDIT: Позвольте мне пересмотреть мой вопрос, чтобы, возможно, сделать его более понятным: это то, что я вижу с точки зрения максимальной производительности исполнения, ожидаемой, когда выделенный сервер @$270/месяц хорошо превзошел Microsoft Azure SQL DB P2 уровень @$930/месяц? Игнорируйте другие "льготы", такие как управляемые или неуправляемые, игнорируйте намеренное использование, такое как Azure, предназначенные для производства и т.д. Мне просто нужно знать, не хватает ли я чего-то с Azure SQL DB или если я действительно должен получить МНОГО лучше производительность из одного выделенного компьютера.

Ответ 1

Существует альтернатива от Microsoft до Azure SQL DB:

"Предоставление виртуальной машины SQL Server в Azure"

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-provision-sql-server/

Подробное объяснение различий между двумя предложениями: "Понимание базы данных Azure SQL и SQL Server в лазурных виртуальных машинах"

https://azure.microsoft.com/en-us/documentation/articles/data-management-azure-sql-database-and-sql-server-iaas/

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

Ответ 2

Перф и наличие в стороне, есть несколько других важных факторов, которые следует учитывать:

Общая стоимость: стоимость аренды в размере 270 долларов США является лишь одним из многих факторов стоимости. Пространство, мощность и hvac - это другие физические затраты. Тогда есть стоимость администрирования. Подумайте, что вам нужно делать каждый патч во вторник и когда Windows или SQL Server отправляет пакет обновления или накопительное обновление. Даже если вы не тестируете их перед выкатыванием, это все равно требует времени и усилий. Если вы проверите, тогда появится вторая машина и дублируется экземпляр продукта и рабочая нагрузка для тестирования.
Безопасность: есть LOT, написанный о том, как плохо, опасно и рискованно хранить любые данные, которые вам нравятся в облаке. Лично я видел худшие реализации и процессы безопасности на локальных серверах (даже в банках и федеральных агентствах), чем я видел с одним из основных поставщиков облачных вычислений (Microsoft, Amazon, Google). Это большая работа, и все в порядке. Кроме того, вы можете видеть и проверять свои SLA безопасности (см. Azure в http://azure.microsoft.com/en-us/support/trust-center/).
Масштабируемость: не только необработанная масштабируемость, но и затраты и усилия для масштабирования. Недавно Azure SQL DB выпустила огромную версию P11, которая имеет 7x вычислительную емкость P2, с которой вы тестировали. Масштабирование вверх и вниз не мгновенно, а очень просто и быстро. Лучшая часть (для меня в любом случае), она может быть удалена до некоторой более высокой версии, когда я запускаю большие запросы или операции переопределения, а затем снова возвращаюсь для "нормальных" нагрузок. Это сложно сделать с обычным SQL Server на голом металле - либо арендовать/покупать действительно большую коробку, которая сидит без дела в 90% случаев или просто время простоя. Немного легче, если в VM; вы можете увеличить объем памяти в Интернете, но все равно нужно отскочить экземпляр, чтобы увеличить процессор; ваша Azure SQL DB остается в режиме онлайн во время операций масштабирования вверх/вниз.

Ответ 3

(Отказ от ответственности: я работаю в Microsoft, хотя не на Azure или SQL Server).

"Azure SQL" не эквивалентен "SQL Server" - и я лично желаю, чтобы мы предложили своего рода "размещенный SQL-сервер" вместо Azure SQL.

На поверхности два одинаковые: они являются реляционными системами баз данных с мощью T-SQL для их запроса (ну, они оба, под капотом используют одну и ту же СУБД).

Azure SQL отличается тем, что идея состоит в том, что у вас есть две базы данных: база данных разработки с использованием локального SQL Server (в идеале 2012 года или позже) и производственная база данных Azure SQL. Вы не должны изменять базу данных Azure напрямую, и вы обнаружите, что SSMS не предлагает инструменты проектирования (Table Designer, View Designer и т.д.) Для Azure SQL. Вместо этого вы разрабатываете и работаете со своей локальной базой данных SQL Server и создаете файлы "DACPAC" (или специальные "изменения" XML файлов, которые могут быть сгенерированы SSDT), которые затем изменяют вашу Azure DB таким образом, что она копирует ваш Dev DB, вид системы "репликация проекта".

В противном случае, как вы заметили, Azure SQL предлагает встроенную отказоустойчивость, резервное копирование, упрощенное администрирование и т.д.

Что касается производительности, возможно, вам не хватало индексов или других оптимизаций? Вы также можете заметить немного более высокую задержку с Azure SQL по сравнению с локальным SQL Server, я видел время ping (от Azure VM до узла Azure SQL) около 5-10 мс, а это значит, что вы должны проектировать свое приложение на меньшее, chatty или параллелизировать операции поиска данных, чтобы уменьшить время загрузки страницы (при условии, что это веб-приложение, которое вы создаете).

Ответ 4

SQL DB имеет встроенную доступность (что может повлиять на производительность), возможность восстановления времени и функции DR. У вас есть возможность масштабировать вверх/вниз вашу БД на основе вашего использования, чтобы снизить стоимость. Вы можете улучшить производительность своего запроса, используя глобальный запрос (данные очертаний). SQl DB управляет автоматическими обновлениями и исправлениями и значительно улучшает историю управляемости. Возможно, вам придется заплатить небольшую премию за это. Кэширование уровня приложений/равномерное распределение нагрузки, понижение в сторону холода и т.д. Могут помочь улучшить производительность вашей базы данных и оптимизировать стоимость.