Как преобразовать веб-приложение с отдельными БД в облако с одной БД?

Я сделал приложение для электронной коммерции, работающее на C#. Каждый экземпляр этого приложения прямо сейчас имеет свой собственный:

  1. Пул приложений IIS 7
  2. веб-сайт IIS 7
  3. База данных SQL Server 2008

Мой партнер сказал мне, что нам нужно отказаться от этого подхода и перейти в облако. Похоже, что SQL Azure взимает плату за базу данных. Так что этот подход будет очень дорогим для нас. Есть ли способ использовать одну гигантскую базу данных без необходимости переписывать весь уровень доступа к данным? *Или есть дешевый способ иметь сотни крошечных баз данных SQL Azure? *

примечание: каждая база данных всего занимает около 20 МБ.


person aron    schedule 28.09.2010    source источник
comment
Вам нужно отказаться от этого подхода и перейти в облако? Почему?   -  person FrustratedWithFormsDesigner    schedule 28.09.2010
comment
чувак, ты видел ning.com??? - Через 2 года это то, чего все будут ожидать. Создайте целую _________ (заполните пробел тем, что вы делаете) ... за 30 секунд.   -  person aron    schedule 28.09.2010
comment
чувак, это не четко объясняет твою потребность в облачной системе.   -  person FrustratedWithFormsDesigner    schedule 28.09.2010
comment
FrustratedWithFormsDesigner — Сэр, я хотел бы разместить 10 000 веб-сайтов с помощью своего приложения для электронной коммерции.   -  person aron    schedule 28.09.2010


Ответы (2)


Да, SQL Azure взимает плату за каждую базу данных, но на самом деле вы платите за размер базы данных. Например, БД объемом 1 ГБ обойдется вам в 9,99 долларов США в месяц, а БД объемом 10 ГБ будет стоить вам 99,99 долларов США в месяц. Базы данных в SQL Azure также в настоящее время имеют максимальный размер 50 ГБ.

Основываясь на этом и том, что вы сказали о своем приложении (возможно, сотнях БД), и предполагая, что каждая база данных будет содержать достаточно данных, чтобы оправдать оплату 1 ГБ БД, я бы продолжал использовать одну БД для каждого пример.

Если данные для каждого экземпляра на самом деле довольно малы, и даже если у вас есть сотни экземпляров, вы не достигнете предела в 50 ГБ, тогда вы сэкономите деньги (но не время), разделив свои данные и сохранив их только в одной базе данных.

Если стоимость является вашей главной заботой, и вы все равно думаете о перезаписи, я бы рассмотрел возможность использования Azure Table Storage (AZT), где тот же 1 ГБ данных будет стоить вам 0,15 доллара США в месяц для хранения (но вам придется отказаться от небольшого такие вещи, как внешние ключи и запросы с более чем 1 таблицей в них)

person knightpfhor    schedule 28.09.2010
comment
С точки зрения затрат [Azure Table Storage (AZT)] будет лучшим вариантом. Однако это приведет к серьезной перезаписи приложения. - person aron; 30.09.2010
comment
Существует также этот образец от MS, который полностью посвящен многопользовательским системам. fabrikamshipping.com - person knightpfhor; 13.10.2010

При 20 МБ на базу данных вы покрыли бы около 50 таких баз данных в одной базе данных Azure объемом 1 ГБ.

С новыми размерами базы данных ваш следующий размер увеличивается на 5 ГБ, и ваш счет амортизируется ежедневно на основе максимального объема хранилища, используемого в данный день. Таким образом, когда у вас меньше 1 ГБ, вам выставляется счет по тарифу 1 ГБ (9,99 долларов США в месяц / дней в месяце). Как только вы превысите 1 ГБ, вы перейдете на уровень 5 ГБ (49,95 долларов США в день в месяц). Это будет значительно дешевле, чем иметь 50 баз данных по 1 ГБ, которые будут работать прибл. 500 долларов в месяц.

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

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

person David Makogon    schedule 29.09.2010
comment
В этом (отличном) ответе отсутствует термин «мультиарендность»; это облегчает ОП поиск справочной информации в bingoogle. Многопользовательская база данных имеет смысл в этом сценарии, но в целом мультитенантное приложение имеет еще больше смысла с точки зрения облачных сценариев. - person tijmenvdk; 29.09.2010
comment
Мое приложение позволяет пользователям загружать код С#. Поэтому важно, чтобы каждый сайт имел свою собственную изолированную базу данных. Таким образом, если загрузить какой-либо вредоносный код SQL, это повлияет только на их собственную базу данных. Позволит ли мне это сделать один лазурный db? Могу ли я создать подбазы данных? или схемы, в которых строка подключения сайта конечного пользователя имеет ограниченный доступ? - person aron; 30.09.2010
comment
Запускается ли какой-либо код, загружаемый пользователями, в вашей базе данных? Могут ли пользователи вносить изменения в базу данных? - person knightpfhor; 04.10.2010
comment
Если вы разрешаете конечным пользователям загружать код в ваше облачное приложение, у вас могут возникнуть более серьезные проблемы, чем доступ к данным. Если вы решите разрешить им загружать код, вам нужно будет удалить прямой доступ к базе данных (не раскрывайте строку подключения к базе данных или учетные данные); вместо этого направьте весь доступ к данным через уровень данных с чем-то вроде WCF (в любом случае это обычно является хорошей практикой). С этим вам никогда не придется беспокоиться о чтении вредоносного кода из неправильных таблиц/строк. Вам по-прежнему потребуются некоторые учетные данные для каждого пользователя, которые позволят вашему уровню данных узнать их идентификатор клиента. - person David Makogon; 04.10.2010
comment
Имейте в виду: код конечного пользователя может просто связываться с библиотеками DLL поддержки Azure. Думайте о вредоносном коде среды выполнения вместо вредоносного кода SQL. Просто рассмотрите случайный вызов RoleEnvironment.RequestRecycle(), который заставит вас почесать голову, задаваясь вопросом, почему ваши экземпляры ролей продолжают перезагружаться. Или, может быть, небольшой обработчик событий, зарегистрированный в RoleEnvironment.Changing, который предоставляет вредоносный код, чтобы сделать что-то встроенное в изменения конфигурации вашего приложения? Возможно, это слишком сложно: как насчет жесткого цикла, который просто запускает вашу рабочую роль на 100% ЦП. - person David Makogon; 04.10.2010