В вашем приложении есть два разных элемента. Существует сервер приложений, который содержит приложение ASP .Net, и сервер базы данных.
Серверы веб-приложений по своей природе не имеют состояния, поэтому масштабирование сервера приложений будет очень простым. Просто разверните приложение на нескольких экземплярах, а затем установите балансировщик нагрузки перед ними.
Для сервера базы данных все гораздо сложнее. Реляционные базы данных из-за их транзакционной и реляционной природы очень трудно масштабировать, и это обычно включает в себя написание пользовательского кода на уровне приложения только для поддержки схемы масштабирования. Это на самом деле важный аспект, потому что масштабируемость не будет просто достигнута прозрачным путем добавления большего количества оборудования (больше машин), но вам также придется инвестировать в кодирование. Вероятно, два самых популярных способа масштабирования с помощью Sql Server - зеркалирование и разбиение. Масштабирование, когда Sql Server разворачивается внутри облака, само облако никак не помогает, оно все равно будет основано на встроенных параметрах.
Помимо сложности, связанной с несвободными решениями БД, до определенного уровня, горизонтальное масштабирование может оказаться намного дороже, чем вертикальное. Для примера рассмотрим следующие сценарии:
1 x 10000 $ машина + 1 x 8000 $ Sql Server профессиональная лицензия = 18000 $
10 x 1000 $ машин + 10 x 8000 $ Sql Server профессиональных лицензий = 90000 $
Поскольку для этого требуется только одна лицензия на Sql Server, дорогая машина в конечном итоге будет намного дешевле, чем использование 10 дешевых машин с 10 лицензиями.
И теперь, когда я подошел к точке расширения в облаке, вещи немного усложняются. Облачные провайдеры дают вам виртуальные машины. Виртуальные машины достаточно хороши для разделения процессорной и оперативной памяти, и при необходимости вы можете увеличить мощность своей машины, увеличив мощность процессора и объем памяти. Это нормально, но базы данных сильно зависят от скорости ввода-вывода (жесткого диска), и это одна из областей, где виртуальные машины не очень хороши.
В связи с облачным предложением Amazon и Sql Server я могу порекомендовать эту очень хорошую статью (на самом деле я получил ее, перейдя по ссылке, предоставленной @marc_s). Чтобы добиться хорошей скорости ввода-вывода при расширении сценариев, автор использует EBS тома. Проблема этого подхода заключается в том, что тома EBS - это не жесткие диски внутри сервера, на котором вы развернули БД, а скорее тома хранения, доступные по сети, что значительно снижает их эффективность.
Если вы не связаны с Amazon, вы можете попробовать облачные провайдеры, которые также предлагают физические машины (выделенные серверы) в своей инфраструктуре. Насколько я знаю gogrid делают это, но могут быть и другие. Идея заключалась бы в том, чтобы развернуть базу данных на выделенном сервере (с хорошей производительностью ввода-вывода), а серверы приложений - на виртуальных машинах (которые будут масштабироваться по горизонтали).
У Microsoft также есть облачное предложение, которое называется Windows Azure , и оно может быть одним из самых интересных на данный момент, но, на мой взгляд, оно разочаровано предложением их реляционных баз данных.Для этого у них есть специальный сервис, который называется Sql Azure .Одним из его основных преимуществ является то, что им легче администрировать, чем обычной базой данных, но с другой стороны, оно весьма ограничено масштабированием.Единственный вариант масштабирования - это размер базы данных, который достигает только 50 ГБ.Они не упоминают ничего о производительности, которую обеспечивает БД, и вы не можете делать какие-либо конфигурации, связанные с этим.Скорее всего, производительность ниже, чем у дешевого выделенного сервера (на самом деле в StackOverflow есть сообщения, в которых люди жалуются на скорость Sql Azure по сравнению с физическими машинами).Вы можете масштабировать с помощью шардинга, но, как упоминалось выше, это влияет и ограничивает структуру БД и способ ее использования в коде.
В вывод :
- Если вы создаете бизнес-приложение с очень большим спросом на реляционные данные, то облачные провайдеры могут быть не лучшим вариантом.Возможно, вы решите использовать свое собственное оборудование или, возможно, провайдеров, которые предоставляют вам возможность использовать выделенные серверы.
- Возможно, вы захотите создать свое приложение, используя решение для баз данных nosql.Они гораздо более масштабируемы, но, с другой стороны, у них есть некоторые ограничения функций (нет транзакций, нет объединений, ограниченные индексы).Sql Table Storage может быть местом для начала, если вы заинтересованы в этом подходе.Вы также можете рассмотреть гибридный подход, при котором часть ваших данных будет храниться в реляционной базе данных, а часть - в nosql.
- Перед масштабированием базы данных проверьте, нет ли других данных.варианты, которые вы могли бы попробовать в первую очередь.Например, проверьте, есть ли неэффективные запросы, или создайте уровень кэширования, который в зависимости от приложения может вывести из базы данных много нагрузки.