Как стать автором
Обновить

Комментарии 4

мы расскажем вам о технической части решения, которое позволило одной из крупнейших компаний по продаже лотерейных билетов в России увеличить объём продаж в 3 раз

Логики предложения в статье так и не увидел.

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

С другой
При работе с Azure SQL необходимо очень рационально расходовать DTU, чтобы не нарваться на заоблачные цены

ЕМПИН, под капотом Azure SQL тот же MSSQL сервер на вполне обычном серверном железе (если не low-end даже, судя по статье cdn2.hubspot.net/hubfs/2334522/reports/Azure%20%20performance%20report%201-2017-ENG.pdf).
То есть, могу сделать вывод, что лотерейщики сделали 2 изменения одновременно (оптимизировали запросы и индексы, и переехали на Azure), и смасштабировались не благодаря, а вопреки прозводительности Azure SQL; видимо, оптимизации таки оказались очень значительными, что и подтверждает фраза
Описанные подходы позволяют увеличить скорость системы в 10-40 раз
Масштабирование в основном за счёт масштабирование фронтенда на базе App Services.

До переноса в Azure, там был MySQL, так что там было всё нескольок сложнее, чем простая оптимизациия запросов и индексов. Там было разделение данных, выделение статики и т.д.
Отличная техническая статья для блога Microsoft, многое говорит об отношении —

взамен этого у вас есть некоторая расчетная величина производительности, называемая DTU (Data Transfer Unit).

В расчете этого параметра участвует конечно же и CPU, и количество операций ввода/вывода с диском и с логом, правда точный состав формулы неизвестен.


То есть «Платите нам деньги за то, не знаю что. Сколько? А сколько скажем, столько и платите». Супер вообще.
Есть вполне понятное определение, что такое DTU docs.microsoft.com/en-us/azure/sql-database/sql-database-what-is-a-dtu

+ есть калькулятор, который может его посчтиать для вашего конкретного воклоада dtucalculator.azurewebsites.net

Так что вы немного преувеличиваете.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий