Azure SQL на личном опыте с высокой нагрузкой

Вот уже больше года мы активно используем Azure SQL для своих проектов.
Хотелось бы поедлиться опытом и подводными камнями на которые мы наткнулись за последний год.



Решил остановиться и описать один отдельный проект в общих чертах активно использующий azure SQL.

Суть проекта сводиться в обработке большого потока данных от удалённых мобильных клиентов.
На текущий момент база данных пополняется примерно 38-45 GB в месяц.

Наш выбор упал на Azure SQL поскольку:

1) Мы решили вывести весь проект-сервис в облако
2) Работа с MS SQL нашей комманде была уже очень знакома
3) Мы поверили в отказоустоичивость и стабильность работы базы данных
4) Есть возможность легко масштабировать производительность бд

На текущий момент в течении 24 часов мы обрабатываем примерно 1000000 подключений и сессий загрузки данных в БД в том числе примерно 1.2 GB текста каждых 24 часа.

Всё это работает в связке: Удалённый клиент -> Web сервис -> Azure SQL

По сути, удалённый клиент выгружает свои данные на веб сервис, который в свою очередь обрабатывает эти данные и загружает в базу данных.



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

Собственно одна из проблем с которой мы столкнулись:

При пиковых нагрузках база данных не справлялась и просто зависала отклоняя все подключения таймайутом.
Обратившись в суппорт Майкрософта нам обьяснили что мы попросту слишком загружаем базу данных и она не способна обработать все наши запросы.

Как оказалось проблема скрывалась в следующем: 

У каждой базы данных есть определённый размер лога транзакции и как только размер лога превышал допустимое значение база данных попросту зависала.

Обратившись в суппорт Майкрософта нам просто посоветовали наш sql запрос: 

DELETE FROM [unknown_table] WHERE [date_time] < '12-01-2012'

разбить на несколько поочерёдно запускаемых.

DELETE FROM [unknown_table] WHERE [date_time] < '01-01-2012'
DELETE FROM [unknown_table] WHERE [date_time] < '02-01-2012'
DELETE FROM [unknown_table] WHERE [date_time] < '03-01-2012'

Данное замечание справедливо для любого SQL запроса, буть до INSERT, SELECT,DELETE или UPDATE.

По сути смешное решение, но это решение было рекомендовано нам службой поддержки Microsoft.

Перевод письма Microsoft support:: «На текущий момент лог транзакций ограничен размером в 1GB но возможно в ближайшем будующем это измениться. Мы внимательно изучаем подобного рода проблемы сообщённые нашими клиентами. В ближайшем времени мы постараемся данное ограничение снять.»

Очередная проблема с которой мы столкнулись была производительность после переезда :

На начальном этапе проекта у нас работал локальный сервер в нашем офисе 
(2) Intel Xeon X5550 2.66 8MB/1333 QC CPU-1.

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

И мы для себя нашли очень удобную утилиту CSS SQL Azure Diagnostis



Которая позволяет проанализировать БД и сообщеает об ошибках либо недостающих желательных индексов как показано на картинке ниже:



Как было бы логично предположить, что это исправило наши проблемы с производительностью некоторых запросов.

То есть по сути после переноса базы данных из MS SQL на Azure SQL было необходимо/желательно перепроверить индексы и создать предлагаемые.

Однако утилита конечно же анализирует логи работы SQL запросов и если вы только мигрировали базу данных — рекоммендуемых недостающих индексов эта утилита показать не сможет.

Автор статьи: Владимир Юнев.