Варианты хранения данных (создание облачных приложений в реальном мире с помощью Azure)

Майк Уоссон, Рик Андерсон (, том Dykstra)

Скачивание решения ИТ-проекта или Загрузка электронной книги

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

Большинство пользователей используются для реляционных баз данных, и они обычно задают другие варианты хранения данных при проектировании облачного приложения. Результат может быть неоптимальной производительностью, большими затратами или хуже, так как NoSQL (нереляционные) базы данных могут обрабатывать некоторые задачи более эффективно, чем реляционные базы данных. Когда клиенты запрашивают у нас помощь в решении проблемы с хранилищем критических данных, часто это связано с тем, что у них есть реляционная база данных, где один из вариантов NoSQL бы лучше работала. В таких ситуациях клиент был бы лучше, если бы он реализовал решение NoSQL перед развертыванием приложения в рабочей среде.

С другой стороны, это также ошибочно полагать, что база данных NoSQL может делать все правильно или достаточно хорошо. Не существует одного оптимального варианта управления данными для всех задач хранилища данных. различные решения для управления данными оптимизированы для различных задач. Большинство реальных облачных приложений имеют разнообразные требования к хранению данных и часто обслуживаются с помощью сочетания нескольких решений для хранения данных.

Цель этой главы — предоставить вам более широкие возможности хранения данных, доступные для облачного приложения, а также некоторые основные рекомендации по выбору тех, которые соответствуют вашему сценарию. Перед разработкой приложения лучше учитывать доступные варианты и думать о их сильных и слабых сторонах. Изменение параметров хранения данных в рабочем приложении может оказаться чрезвычайно сложным, например, при необходимости изменения подсистемы Jet, когда плоскость находится в полете.

Варианты хранения данных в Azure

Облако позволяет относительно легко использовать различные реляционные и NoSQL хранилища данных. Ниже приведены некоторые платформы хранения данных, которые можно использовать в Azure.

В таблице показаны четыре типа баз данных NoSQL:

  • Базы данных "ключ — значение " хранят один сериализованный объект для каждого значения ключа. Они хорошо подходят для хранения больших объемов данных, которые нужно извлекать по одному элементу с известным значением ключа, если при этом совершенно не требуются запросы по другим свойствам элемента.

    Хранилище BLOB-объектов Azure — это база данных "ключ-значение", которая работает как хранилище файлов в облаке, со значениями ключей, которые соответствуют именам папок и файлов. Вы получаете файл по его папке и имени файла, а не ищете значения в его содержимом.

    Хранилище таблиц Azure также является базой данных "ключ — значение". Каждое значение называется сущностью (аналогично строке, определяемой ключом секции и ключом строки) и содержит несколько свойств (аналогично столбцам, но не все сущности в таблице должны совместно использовать одни и те же столбцы). Запросы к столбцам, отличным от ключа, чрезвычайно неэффективны, поэтому их следует избегать. Например, можно хранить данные профиля пользователя с одним разделом, в котором хранятся сведения об отдельном пользователе. Вы можете хранить такие данные, как имя пользователя, хэш пароля, Дата рождения и т. д., в отдельных свойствах одной сущности или в отдельных сущностях в одной секции. Но не нужно запрашивать всех пользователей с заданным диапазоном дат рождения, и нельзя выполнять запрос JOIN между таблицей профиля и другой таблицей. Хранилище таблиц является более масштабируемым и дешевле, чем реляционная база данных, но не включает сложные запросы и объединения.

  • Документдатабасес — это базы данных ключей и значений, в которых значения являются документами. "Документ" не используется в смысле документа Word или Excel, но означает набор именованных полей и значений, любой из которых может быть дочерним документом. Например, в таблице журнала заказа документ заказа может содержать поля номер заказа, Дата заказа и клиент. в поле "клиент" могут быть поля "имя" и "адрес". База данных кодирует данные полей в таком формате, как XML, YAML, JSON или BSON. или может использовать обычный текст. Одна из функций, устанавливающих базы данных документов отдельно от баз данных "ключ — значение", — это возможность запрашивать неключевые поля и определять вторичные индексы, чтобы сделать запросы более эффективными. Эта возможность делает базу данных документов более подходящей для приложений, которым требуется получить данные на основе критериев, более сложных по сравнению с ключом документа. Например, в базе данных документов в журнале заказов на продажу можно запрашивать различные поля, такие как идентификатор продукта, идентификатор клиента, имя клиента и т. д. MongoDB — это популярная база данных документов.

  • Базы данных-семейства столбцов — это хранилища данных "ключ — значение", которые позволяют структурировать хранилище данных в коллекции связанных столбцов, именуемых семействами столбцов. Например, база данных переписи может иметь одну группу столбцов для имени человека (первая, средняя, последняя), одну группу для адреса человека и одну группу для сведений профиля пользователя (DOB, Gender и т. д.). Затем база данных может хранить каждое семейство столбцов в отдельной секции, сохраняя все данные для одного пользователя, связанного с одним и тем же ключом. Затем можно считывать все сведения о профиле, не требуя считывания всех сведений об имени и адресе. Cassandra — это популярная база данных для семейства столбцов.

  • В базах данных Graph данные хранятся в виде коллекции объектов и связей. База данных графа предназначена для того, чтобы позволить приложению эффективно выполнять запросы, которые проходят через сеть объектов и связи между ними. Например, в базе данных персонала объектами могут являться сотрудники и вам может потребоваться выполнить такой запрос, как "найти всех сотрудников, которые прямо или косвенно подчиняются Сергею". Neo4j — это популярная база данных графов.

По сравнению с реляционными базами данных, параметры NoSQL обеспечивают гораздо более высокую масштабируемость и экономичность при хранении и анализе неструктурированных данных. Компромисс заключается в том, что они не предоставляют широкие возможности для запросов и надежной целостности данных в реляционных базах данных. NoSQL хорошо подойдет для данных журнала IIS, в которых задействованы большие объемы томов без необходимости присоединять запросы. NoSQL будет работать не так хорошо для банковских транзакций, что требует абсолютной целостности данных и включает множество связей с другими данными, связанными с учетной записью.

Также существует новая категория платформы баз данных с именем невскл , которая сочетает масштабируемость базы данных NoSQL с возможностью запросов и целостностью реляционной базы данных. Базы данных Невскл предназначены для распределенного хранения и обработки запросов, что часто сложно реализовать в базах данных «Олдскл». Нуодб — это пример базы данных невскл, которую можно использовать в Azure.

Hadoop и MapReduce

Большие объемы данных, которые можно хранить в базах данных NoSQL, могут быть трудными для эффективного анализа. Для этого можно использовать такую платформу, как Hadoop , которая реализует функциональность MapReduce . По сути, процесс MapReduce выполняется следующим образом:

  • Ограничьте размер данных, которые необходимо обработать, выбирая из хранилища данных только те данные, которые действительно необходимо проанализировать. Например, вы хотите узнать описывающего своей базы пользователей по году рождения, чтобы выбрать только год рождения из хранилища данных профиля пользователя.
  • Разбейте данные на части и отправляйте их на разные компьютеры для обработки. Компьютер A вычисляет число людей с 1950-1959 датами, компьютер B выполняет 1960-1969 и т. д. Эта группа компьютеров называется кластером Hadoop.
  • Помещайте результаты каждой части обратно вместе после завершения обработки частей. Теперь у вас есть сравнительно короткий список, сколько людей для каждого года рождения и задача вычисления процентных долей в этом общем списке является управляемой.

В Azure HDInsight позволяет обрабатывать, анализировать и получать новые ценные сведения из больших данных с помощью возможностей Hadoop. Например, его можно использовать для анализа журналов веб-сервера:

  • Включите ведение журнала веб-сервера в учетной записи хранения. Это настраивает Azure для записи журналов в службу больших двоичных объектов для каждого HTTP-запроса к приложению. Служба BLOB-объектов по сути является облачным хранилищем файлов и хорошо интегрируется с HDInsight.

    Журналы в хранилище BLOB-объектов

  • По мере того как приложение получает трафик, журналы IIS веб-сервера записываются в хранилище больших двоичных объектов.

    Журналы веб-сервера

  • На портале щелкните New - Data Services - HDInsight - Быстрое созданиеи укажите имя кластера hdinsight, размер кластера (число узлов данных кластера hdinsight), а также имя пользователя и пароль для кластера hdinsight.

    HDInsight

Теперь можно настроить задания MapReduce для анализа журналов и получения ответов на такие вопросы:

  • Какое время суток использует мое приложение для получения наибольшего или минимального трафика?
  • Из каких стран исходят исходящий трафик?
  • Каков средний доход в области, из которой поступил трафик. (Есть общедоступный набор данных, который обеспечивает доходы по IP-адресу, и вы можете сопоставить его с IP-адресом в журналах веб-сервера.)
  • Как отношение доходов окружения к конкретным страницам или продуктам на сайте?

Вы можете использовать ответы на такие вопросы, чтобы ориентироваться на рекламу в зависимости от вероятности того, что клиент заинтересовался или скорее всего купит определенный продукт.

Как объясняется в главе «Автоматизация всех», большинство функций, которые можно выполнять на портале, могут быть автоматизированы и включают настройку и выполнение заданий анализа HDInsight. Типичный сценарий HDInsight может содержать следующие шаги:

  • Подготавливает кластер HDInsight и свяжите его с учетной записью хранения для входных данных хранилища BLOB-объектов.
  • Передайте исполняемые файлы задания MapReduce (. jar или. exe) в кластер HDInsight.
  • Отправьте MapReduce, который хранит выходные данные в хранилище BLOB-объектов.
  • Дождитесь завершения задания.
  • Удаление кластера HDInsight.
  • Получите доступ к выходным данным из хранилища BLOB-объектов.

Выполнив сценарий, который делает это, вы сократите время, в течение которого будет подготовлен кластер HDInsight, что снизит затраты.

Платформа как услуга (PaaS) и инфраструктура как услуга (IaaS)

Приведенные выше варианты хранения данных включают решения "платформа как услуга" (PaaS) и "инфраструктура как услуга" (IaaS). PaaS означает, что мы работаем с аппаратной и программной инфраструктурой, а вы просто используете службу. База данных SQL — это функция PaaS в Azure. Вы запрашиваете базы данных, и в фоновом режиме Azure устанавливает и настраивает виртуальные машины, а также устанавливает на них базы данных. У вас нет прямого доступа к виртуальным машинам и управление ими не требуется. IaaS означает, что вы настроили и настраиваете виртуальные машины, которые выполняются в нашей инфраструктуре центра обработки данных, и управляете ими. Мы предоставляем коллекцию предварительно настроенных образов виртуальных машин для распространенных конфигураций виртуальных машин. Например, можно установить предварительно настроенные образы виртуальных машин для Windows Server 2008, Windows Server 2012, BizTalk Server, Oracle для сервера Oracle Database и т. д.

Решения для данных PaaS, предоставляемые Azure, включают:

  • База данных SQL Azure (прежнее название — SQL Azure). Облачная реляционная база данных на основе SQL Server.
  • хранилище таблиц Azure. База данных NoSQL "ключ-значение".
  • Хранилище BLOB-объектов Azure. Хранилище файлов в облаке.

Для IaaS можно запустить все, что можно загрузить на виртуальную машину, например:

  • Реляционные базы данных, такие как SQL Server, Oracle, MySQL, SQL Compact, SQLite или postgres.
  • Хранилища данных "ключ — значение", такие как memcached, Redis, Cassandra и Риак.
  • Хранилища данных столбцов, например HBase.
  • Базы данных документов, такие как MongoDB, RavenDB и CouchDB.
  • Базы данных графов, такие как Neo4j.

Варианты хранения данных в Azure

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

Обзор виртуальной машины хранилище

Затем вы увидите список сотен предварительно настроенных образов виртуальных машин, и вы можете создать виртуальную машину из образа с предварительно установленной системой управления базами данных, например MongoDB, Neo4J, Redis, Cassandra или CouchDB.

MongoDB в виртуальной машине хранилище

Azure делает возможности хранения данных IaaS простыми в использовании, но предложения PaaS имеют множество преимуществ, которые делают их более экономичными и практичными для многих сценариев:

  • Вам не нужно создавать виртуальные машины, вы просто используете портал или сценарий для настройки хранилища данных. Если требуется хранилище данных 200 терабайта, можно просто щелкнуть кнопку или выполнить команду, а также в течение секунд, пока она готова к использованию.
  • Вам не нужно управлять виртуальными машинами, используемыми службой, или исправлять их. Майкрософт делает это автоматически. — вам не нужно беспокоиться о настройке инфраструктуры для масштабирования или высокой доступности. Корпорация Майкрософт обрабатывает все это за вас.
  • Вам не нужно покупать лицензии; плата за лицензии включается в сервисные платы.
  • Вы платите только за то, что используете.

Варианты хранения данных PaaS в Azure включают предложения от сторонних поставщиков. Например, можно выбрать надстройку MongoLab из магазина Azure для предоставления базы данных MongoDB в качестве службы.

Выбор варианта хранения данных

Ни один подход не подходит для всех сценариев. Если кто-то говорит, что эта технология является ответом, первое, что следует спросить, — «что такое вопрос?», поскольку различные решения оптимизированы для разных целей. Реляционная модель имеет определенные преимущества; Вот почему это было так долго. Но есть и другие стороны SQL, которые могут быть решены с помощью решения NoSQL.

Часто мы видим, что лучше всего это составной подход, где вы используете SQL и NoSQL в одном решении. Даже если люди говорят, что они используют NoSQL, при детализации того, что они делают, часто встречаются несколько различных NoSQL платформ: они используют CouchDB, а Redisи Риак для различных целей. Даже Facebook, в котором широко используется NoSQL, использует разные платформы NoSQL для разных частей службы. Гибкость, связанная с подходами к хранению данных, — это одна из вещей, которые отлично подходят для облака, так как в одном приложении можно легко использовать несколько решений для работы с данными и интегрировать их.

Ниже приведены некоторые вопросы, которые следует учесть при выборе подхода.

Семантика данных — Какова основная семантика хранилища данных и доступа к данным (хранятся ли реляционные или неструктурированные данные)? Неструктурированные данные, такие как файлы мультимедиа, подходят для хранения BLOB-объектов; набор связанных данных, таких как продукты, запасы, поставщики, заказы клиентов и т. д., подходит для реляционной базы данных.
Поддержка запросов Как просто запрашивать данные? — Какие типы вопросов можно эффективно запрашивать? Хранилища данных "ключ — значение" очень хороши при получении одной строки с заданным ключевым значением, но не настолько хорошо для сложных запросов. Для хранилища данных профиля пользователя, в котором вы всегда получаете данные для одного конкретного пользователя, хранилище данных "ключ — значение" может работать правильно. для каталога продуктов, в котором вы хотите получить различные группирования, основанные на различных атрибутах продукта, реляционная база данных может работать лучше. Базы данных NoSQL могут эффективно хранить большие объемы данных, но необходимо структурировать базу данных так, как приложение запрашивает данные, и это затрудняет выполнение нерегламентированных запросов. С помощью реляционной базы данных можно создавать запросы практически любого типа.
Функциональная проекция — Вопросы, агрегаты и т. д. могут выполняться на стороне сервера? Если я выполняю SELECT COUNT (*) из таблицы в SQL, он очень эффективно выполняет всю работу на сервере и возвращает нужное число. Если мне нужно то же вычисление из хранилища данных NoSQL, которое не поддерживает агрегирование, это неэффективный неограниченный запрос и, возможно, истечет время ожидания. Даже если запрос выполнен успешно, мне нужно получить все данные с сервера на клиент и подсчитать строки на клиенте. -Какие языки и типы выражений можно использовать? В реляционной базе данных я могу использовать SQL. В некоторых базах данных NoSQL, таких как хранилище таблиц Azure, я буду использовать OData, и все, что я могу сделать, — это фильтровать по первичному ключу и получать проекции (выберите подмножество доступных полей).
Простота масштабирования — Как часто и сколько необходимо масштабировать данные? — Платформа изначально реализует горизонтальное масштабирование? Как просто добавить или удалить емкость (размер и пропускную способность)? Реляционные базы данных и таблицы не разделяются автоматически, чтобы сделать их масштабируемыми, поэтому их сложно масштабировать, чем некоторые ограничения. NoSQL хранилища данных, такие как хранилище таблиц Azure, по сути секционированы все, и почти нет ограничений на добавление секций. Вы можете легко масштабировать хранилище таблиц размером до 200 терабайт, но максимальный размер базы данных SQL Azure составляет 500 ГБ. Реляционные данные можно масштабировать, разделяя их на несколько баз данных, но Настройка приложения для поддержки этой модели включает в себя множество программных работ.
Инструментирование и управляемость Насколько проста платформа для инструментирования, мониторинга и управления? Вам нужно будет знать о работоспособности и производительности хранилища данных, чтобы вам было известно о том, какие метрики предоставляет платформа бесплатно и что необходимо для самостоятельной разработки.
Операции Насколько проста платформа для развертывания и запуска в Azure? PaaS? IaaS? Linux? Хранилище таблиц и база данных SQL легко настроить в Azure. Платформы, которые не являются встроенными решениями Azure PaaS, нуждаются в дополнительных усилиях.
Поддержка API — Это доступный API, который упрощает работу с платформой? Для службы таблиц Azure существует пакет SDK с API .NET, поддерживающий модель асинхронного программирования .NET 4,5. При написании приложения .NET гораздо проще написать и протестировать код для службы таблиц Azure по сравнению с другой платформой хранилища данных "ключ-значение", не имеющей API или менее исчерпывающим.
Целостность транзакций и согласованность данных — Очень важно, что платформа поддерживает транзакции, чтобы обеспечить согласованность данных? Для отслеживания объемов отправленных сообщений электронной почты производительность и низкая стоимость хранения данных могут быть более важными, чем автоматическая поддержка транзакций или ссылочной целостности в платформе данных, что делает службу таблиц Azure хорошим выбором. Для отслеживания балансов банковского счета или заказов на покупку платформа реляционной базы данных, обеспечивающая надежные гарантии транзакций, будет лучшим выбором.
Непрерывность бизнес-процессов Что такое простота резервного копирования, восстановления и аварийного восстановления? Более ранние или более поздние рабочие данные будут повреждены, и вам потребуется функция отмены. Реляционные базы данных часто имеют более детализированные возможности восстановления, например возможность восстановления на момент времени. Понимание возможностей восстановления, доступных на каждой рассматриваемой платформе, является важным фактором.
Стоимость — Если несколько платформ могут поддерживать рабочую нагрузку данных, как они сравниваются по затратам? Например, при использовании ASP.NET Identity можно хранить данные профиля пользователя в службе таблиц Azure или в базе данных SQL Azure. Если вам не нужны широкие возможности запросов к базе данных SQL, вы можете выбрать таблицы Azure в части, так как затраты на него гораздо меньше для определенного объема хранилища.

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

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

  • Требуются ли приложению возможности аудита?
  • Каковы требования к долговременному объему данных — требуются ли вам возможности автоматической архивации или очистки?
  • Требуются ли вам специализированные требования к безопасности? Например, данные включают персональные данные (личные сведения), но необходимо убедиться, что PII исключены из результатов запроса.
  • Если у вас есть данные, которые не могут храниться в облаке для нормативных или технологических причин, может потребоваться платформа облачного хранилища данных, которая упрощает интеграцию с локальным хранилищем.

Демонстрация: использование базы данных SQL в Azure

Приложение для устранения проблем использует реляционную базу данных для хранения задач. Сценарий Windows PowerShell для создания среды, показанный в главе Автоматизация всех , создает два экземпляра базы данных SQL. Их можно увидеть на портале, щелкнув вкладку базы данных SQL .

Базы данных SQL на портале

Вы также можете легко создавать базы данных с помощью портала.

Щелкните создать--службы данных -- базе данных SQL -- Быстрое создание, введите имя базы данных, выберите сервер, который уже есть в вашей учетной записи, или создайте новый, а затем щелкните создать базу данных SQL.

Новая база данных SQL

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

Создана новая база данных SQL

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

Вот пример нашей модели "платформа как услуга". Управлять серверами не требуется, мы делаем их. Вам не нужно беспокоиться о резервных копиях. Он работает в высокой доступности — данные в базе данных реплицируются на три сервера автоматически. Если компьютер выходит из строя, автоматически выполняется отработка отказа, и данные не теряются. Сервер постоянно обновляется, вам не нужно беспокоиться об этом.

Нажмите кнопку, чтобы получить точную строку подключения и сразу же приступить к использованию новой базы данных.

Строки подключения

На панели мониторинга отображается журнал подключения и объем используемого хранилища.

Панель мониторинга базы данных SQL

Можно управлять базами данных на портале или с помощью SQL Server инструментов, с которыми вы уже знакомы, в том числе SQL Server Management Studio (SSMS) и Visual Studio Tools обозреватель объектов SQL Server (SSOX) и обозреватель сервера.

SSOX

Еще одна удобная вещь — модель ценообразования. Вы можете начать разработку с бесплатной базы данных по 20 МБ, а Рабочая база данных начнется примерно $5 в месяц. Вы платите только за объем данных, которые фактически хранятся в базе данных, а не на максимальной емкости. Вам не нужно покупать лицензию.

Базу данных SQL легко масштабировать. Для приложения, предназначенного для решения проблемы, база данных, созданная в нашем сценарии автоматизации, ограничена 1 ГБ. Если вы хотите масштабировать его до 150 ГБ, можно просто перейти на портал и изменить этот параметр или выполнить REST APIную команду, а в секундах — базу данных 150, в которую можно развернуть данные.

Выпуски и размеры базы данных SQL

Это сила облака, которая позволяет быстро и легко использовать инфраструктуру, и сразу же приступить к ее использованию.

Приложение для устранения проблем использует две базы данных SQL: одну для членства (проверка подлинности и авторизация) и одну для данных, и это все, что нужно сделать для ее предоставления и масштабирования. Вы ранее видели, как подготавливать базы данных с помощью сценариев Windows PowerShell, и теперь вы узнали, как легко сделать это на портале.

Entity Framework и прямой доступ к базе данных с помощью ADO.NET

Приложение для устранения проблем обращается к этим базам данных с помощью Entity Framework, рекомендуемого модуля ORM (объектно-реляционного модуля сопоставления) Майкрософт для приложений .NET. ORM — это отличное средство, которое упрощает работу разработчиков, но производительность в некоторых сценариях обусловлена снижением производительности. В реальных облачных приложениях вы не будете выбирать между использованием EF или ADO.NET напрямую. Вы будете использовать оба этих компонента. В большинстве случаев при написании кода, который работает с базой данных, получение максимальной производительности не является критическим, и вы можете воспользоваться преимуществами упрощенного программирования и тестирования, которые вы получаете с Entity Framework. В ситуациях, когда накладные расходы EF приведут к неприемлемой производительности, вы можете писать и выполнять собственные запросы с помощью ADO.NET, в идеале, путем вызова хранимых процедур.

Независимо от того, какой метод используется для доступа к базе данных, вы хотите максимально увеличить «беседу». Иными словами, если можно получить все необходимые данные в одном крупном наборе результатов запроса, а не десятках или сотнях меньших, это обычно предпочтительно. Например, если вам нужно перечислить учащихся и курсов, в которых они зарегистрированы, обычно лучше получить все данные в одном запросе на соединение, а не получать учащихся в одном запросе и выполнять отдельные запросы для курсов каждого учащегося.

Базы данных SQL и Entity Framework в приложении Fix ИТ

В приложении Fix It класс FixItContext, производный от класса Entity Framework DbContext, определяет базу данных и указывает таблицы в базе данных. Контекст задает набор сущностей (таблицу) для задач, а код передается в контекст в качестве имени строки подключения. Это имя ссылается на строку подключения, определенную в файле Web. config.

public class MyFixItContext : DbContext
{
    public MyFixItContext()
        : base("name=appdb")
    {
    }

    public DbSet<MyFixIt.Persistence.FixItTask> FixItTasks { get; set; }
}

Строка подключения в файле Web. config называется аппдб (здесь указывает на локальную базу данных разработки):

<connectionStrings>
    <add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;Initial Catalog=aspnet-MyFixIt-20130604091232_4;Integrated Security=True" providerName="System.Data.SqlClient" />
    <add name="appdb" connectionString="Data Source=(localdb)\v11.0; Initial Catalog=MyFixItContext-20130604091609_11;Integrated Security=True; MultipleActiveResultSets=True" providerName="System.Data.SqlClient" />
  </connectionStrings>

Entity Framework создает таблицу фикситтаскс на основе свойств, включенных в FixItTask класс сущностей. Это простой класс POCO (простой старый объект CLR), который означает, что он не наследует от Entity Framework и не имеет никаких зависимостей от него. Но Entity Framework известно, как создать таблицу на ее основе и выполнить операции CRUD (Create-Read-Update-Delete).

public class FixItTask
{
    public int FixItTaskId  { get; set; }
    public string CreatedBy { get; set; }
    [Required]
    public string Owner     { get; set; }
    [Required]
    public string Title     { get; set; }
    public string Notes     { get; set; }
    public string PhotoUrl  { get; set; }
    public bool IsDone      { get; set; } 
}

Таблица Фикситтаскс

Приложение для устранения проблем включает в себя интерфейс репозитория, который используется для операций CRUD, работающих с хранилищем данных.

public interface IFixItTaskRepository
{
    Task<List<FixItTask>> FindOpenTasksByOwnerAsync(string userName);
    Task<List<FixItTask>> FindTasksByCreatorAsync(string userName); 

    Task<MyFixIt.Persistence.FixItTask> FindTaskByIdAsync(int id);

    Task CreateAsync(FixItTask taskToAdd);
    Task UpdateAsync(FixItTask taskToSave);
    Task DeleteAsync(int id);
}

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

Реализация репозитория вызывает Entity Framework асинхронные методы для работы с данными, включая запросы LINQ, а также операции вставки, обновления и удаления. Ниже приведен пример кода для поиска решения задачи ИТ.

public async Task<FixItTask> FindTaskByIdAsync(int id)
{
    FixItTask fixItTask = null;
    Stopwatch timespan = Stopwatch.StartNew();

    try
    {
        fixItTask = await db.FixItTasks.FindAsync(id);
        
        timespan.Stop();
        log.TraceApi("SQL Database", "FixItTaskRepository.FindTaskByIdAsync", timespan.Elapsed, "id={0}", id);
    }
    catch(Exception e)
    {
        log.Error(e, "Error in FixItTaskRepository.FindTaskByIdAsynx(id={0})", id);
    }

    return fixItTask;
}

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

Выбор базы данных SQL (PaaS) и SQL Server в виртуальной машине (IaaS) в Azure

Хорошая вещь о SQL Server и базе данных SQL Azure заключается в том, что основная модель программирования для обоих из них идентична. Большинство этих навыков можно использовать в обеих средах. Вы даже можете использовать базу данных SQL Server в разработке и экземпляр базы данных SQL в облаке, что является настройкой приложения для исправления ИТ.

В качестве альтернативы можно запустить ту же SQL Server в облаке, которое выполняется в локальной среде, установив его на виртуальных машинах IaaS. Для некоторых устаревших приложений запуск SQL Server в виртуальной машине может быть лучшим решением. Так как база данных SQL Server работает на выделенной виртуальной машине, ей предоставляется больше ресурсов, чем база данных SQL, которая работает на общем сервере. Это означает, что база данных SQL Server может быть больше и работать хорошо. Как правило, чем меньше размер базы данных, ни размер таблицы, тем лучше вариант использования базы данных SQL (PaaS).

Ниже приведены некоторые рекомендации по выбору между двумя моделями.

База данных SQL Azure (PaaS) SQL Server на виртуальной машине (IaaS)
Профессионалы — вам не нужно создавать виртуальные машины, обновлять или изменять операционные системы или SQL, а также управлять ими. Azure делает это самостоятельно. — Встроенная Высокая доступность с соглашением об уровне обслуживания уровня базы данных. — Низкая совокупная стоимость владения (TCO), так как вы платите только за то, что используете (не требуется лицензия). — Подходит для обработки большого количества небольших баз данных (<= 500 ГБ). — Упрощается динамическое создание новых баз данных для обеспечения горизонтального масштабирования. Возможности, совместимые с локальными SQL Server. — Может реализовать SQL Server высокий уровень доступности с помощью AlwaysOn в 2 и более виртуальных машинах с соглашением об уровне обслуживания на уровне виртуальной машины. — Вы полностью контролируете управление SQL. — Может повторно использовать уже имеющиеся лицензии SQL или платить за один час. — Подходит для обработки меньшего числа баз данных, но более крупных (1 ТБ +).
Недостатки . Некоторые функции пропуска по сравнению с локальными SQL Server (отсутствие интеграции со средой CLR, TDE, Поддержка сжатия, SQL Server Reporting Servicesи т. д.) — ограничение размера базы данных 500 ГБ. Недостатки — обновления и исправления (операционная система и SQL) — это ваша обязанность — создание и управление баз данных — это ваша ответственность за число операций ввода-вывода на диск (в секунду), ограниченный около 8000 (через 16 дисков данных).

Если вы хотите использовать SQL Server на виртуальной машине, можно использовать собственную лицензию SQL Server или оплатить ее за час. Например, на портале или с помощью REST API можно создать новую виртуальную машину с помощью SQL Server образа.

Создание виртуальной машины с SQL Server

Список SQL Server образов виртуальных машин

При создании виртуальной машины с SQL Server образом мы будем оценивать стоимость SQL Server лицензий на час на основе использования виртуальной машины. Если у вас есть проект, который будет работать только в течение нескольких месяцев, это дешевле, чем платить за час. Если вы считаете, что проект будет работать в течение нескольких лет, дешевле приобретать лицензию в обычном порядке.

Сводка

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

Ресурсы

Для получения дополнительных сведений см. следующие ресурсы.

Выбор платформы базы данных:

Выбор между SQL Server и базой данных SQL:

Использование Entity Framework и базы данных SQL в веб-приложении ASP.NET

Использование MongoDB в Azure:

HDInsight (Hadoop в Azure):