Использование клиентской библиотеки эластичной базы данных с Dapper

Применимо к: База данных SQL Azure

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

Пример кода.Elastic DB Tools for Azure SQL - Dapper Integration (Средства эластичной базы данных для Базы данных SQL Azure — интеграция с Dapper).

Интеграция Dapper и DapperExtensions с клиентской библиотекой эластичной базы данных для Базы данных SQL Azure — это просто. Ваши приложения могут использовать маршрутизацию, зависящую от данных, изменив создание и открытие новых объектов SqlConnection с использованием вызова OpenConnectionForKey из клиентской библиотеки. Это ограничивает внесение изменений в приложении местами создания и открытия новых подключений.

Обзор Dapper

Dapper — это объектно-реляционный модуль сопоставления. Оно сопоставляет объекты .NET в приложении с объектами в реляционной базе данных (и наоборот). В первой части примера кода показано, как можно интегрировать клиентскую библиотеку эластичной базы данных с приложениями, созданными с помощью Dapper. Во второй части примера кода показано, как выполнить интеграцию при одновременном использовании Dapper и DapperExtensions.

Средство сопоставления в Dapper предоставляет методы расширения для подключений к базе данных, упрощающие отправку операторов T-SQL для выполнения базы данных или создания адресуемых ей запросов. Например, Dapper упрощает сопоставление ваших объектов .NET с параметрами инструкций SQL для вызовов Execute, или позволяет получать результаты запросов SQL в объекты .NET с помощью вызовов Query из Dapper.

При использовании DapperExtensions больше не требуется предоставлять SQL-запросы. Методы расширений, например GetList или Insert через подключение к базе данных, создают инструкции SQL за кулисами.

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

Сведения о получении сборок Dapper можно найти на сайте Dapper dot net. Сведения о расширениях Dapper см. в статье DapperExtensions 1.5.0.

Краткий обзор клиентской библиотеки эластичной базы данных

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

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

Вместо стандартных способов создания подключений для Dapper необходимо использовать метод OpenConnectionForKey. Это гарантирует, что при перемещении данных между шардами выполняется полная проверка и надлежащее управление соединениями.

Требования к интеграции Dapper

Во время работы одновременно с клиентской библиотекой эластичной базы данных и интерфейсами API Dapper цель заключается в том, чтобы сохранить следующие свойства.

• Горизонтальное увеличение масштаба: Мы хотим по мере необходимости добавлять или удалять базы данных из слоя данных сегментированного приложения в соответствии с потребностями приложения в ресурсе.
• Согласованность. Так как приложение масштабируется путем сегментирования, необходимо выполнять маршрутизацию, зависящую от данных. Для этого мы хотим использовать возможности маршрутизации библиотеки, зависящей от данных. В частности, необходимо сохранить гарантии проверки и согласованности, предоставляемые с помощью подключений, которые проходят через диспетчер сопоставления сегментов, во избежание повреждения или получения неправильных результатов запросов. Это гарантирует, что подключения к заданному шардлету отклоняются или останавливаются, если (например) в настоящее время шардлет перемещается в другой сегмент с помощью API для разделения и объединения.
• Сопоставление объектов.Необходимо сохранить удобство сопоставлений, предоставляемое Dapper, для преобразования между классами в приложении и базовыми структурами базы данных.

В следующем разделе приведены рекомендации по этим требованиям для приложений, созданных с помощью Dapper и DapperExtensions.

Техническое руководство

Маршрутизация, зависящая от данных, с помощью Dapper

При использовании Dapper приложение, как правило, отвечает за создание и открытие подключений к базе данных. Учитывая тип T, предоставленный приложением, Dapper возвращает результаты запроса в виде коллекций .NET типа T. Dapper выполняет сопоставление из строк результатов T-SQL с объектами типа T. Аналогичным образом Dapper сопоставляет объекты .NET со значениями SQL или параметрами для инструкций языка обработки данных (DML). Dapper обеспечивает эти функциональные возможности с помощью методов расширения в регулярном объекте SqlConnection из библиотек ADO.NET для клиента SQL. Подключения SQL, возвращаемые API эластичного масштабирования для DDR, также являются обычными объектами SqlConnection . Это позволяет напрямую использовать расширения Dapper по типу, возвращаемого API DDR клиентской библиотеки, так как это также простое подключение клиента SQL.

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

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

    using (SqlConnection sqlconn = shardingLayer.ShardMap.OpenConnectionForKey(
                     key: tenantId1,
                     connectionString: connStrBldr.ConnectionString,
                     options: ConnectionOptions.Validate))
    {
        var blog = new Blog { Name = name };
        sqlconn.Execute(@"
                      INSERT INTO
                            Blog (Name)
                            VALUES (@name)", new { name = blog.Name }
                        );
    }

Вызов API OpenConnectionForKey заменяет стандартное создание и открытие подключения клиента SQL. Метод OpenConnectionForKey при вызове принимает аргументы, которые требуются для маршрутизации, зависящей от данных.

• Карта шардирования для доступа к интерфейсам маршрутизации в зависимости от данных.
• ключ сегментирования для определения шардлета;
• учетные данные (имя пользователя и пароль) для подключения к сегменту.

Объект сопоставления фрагментов создает подключение к фрагменту, в котором содержится шарлет, соответствующий заданному ключу шардирования. Клиентские API-интерфейсы эластичной базы данных также помечают подключение тегом для реализации гарантий согласованности. Так как вызов OpenConnectionForKey возвращает обычный объект подключения клиента SQL, последующий вызов Execute метода расширения из Dapper следует стандартной практике Dapper.

Запросы формируются в целом одинаково: сначала открывается подключение с помощью OpenConnectionForKey из клиентского API-интерфейса, а затем используются регулярные методы расширения Dapper для сопоставления результатов SQL-запроса в объектах .NET:

    using (SqlConnection sqlconn = shardingLayer.ShardMap.OpenConnectionForKey(
                    key: tenantId1,
                    connectionString: connStrBldr.ConnectionString,
                    options: ConnectionOptions.Validate ))
    {
           // Display all Blogs for tenant 1
           IEnumerable<Blog> result = sqlconn.Query<Blog>(@"
                                SELECT *
                                FROM Blog
                                ORDER BY Name");

           Console.WriteLine("All blogs for tenant id {0}:", tenantId1);
           foreach (var item in result)
           {
                Console.WriteLine(item.Name);
            }
    }

Блок использования с подключением DDR охватывает все операции базы данных, ограничивая их одним шардом, где хранится tenantId1. Запрос возвращает только блоги, хранящиеся в текущем сегменте, а не в любых других сегментах.

Маршрутизация, зависящая от данных, с использованием Dapper и DapperExtensions

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

При использовании DapperExtensions в приложении способ создания подключений к базе данных и управления ими не меняется. Открытие подключений остается в ответственности приложения, и обычные объекты подключения SQL-клиента ожидаются методами расширения. Мы можем использовать OpenConnectionForKey , как описано выше. Единственное изменение заключается в том, что больше не нужно писать операторы T-SQL, как показано в следующих примерах кода.

    using (SqlConnection sqlconn = shardingLayer.ShardMap.OpenConnectionForKey(
                    key: tenantId2,
                    connectionString: connStrBldr.ConnectionString,
                    options: ConnectionOptions.Validate))
    {
           var blog = new Blog { Name = name2 };
           sqlconn.Insert(blog);
    }

А вот пример кода для запроса:

    using (SqlConnection sqlconn = shardingLayer.ShardMap.OpenConnectionForKey(
                    key: tenantId2,
                    connectionString: connStrBldr.ConnectionString,
                    options: ConnectionOptions.Validate))
    {
           // Display all Blogs for tenant 2
           IEnumerable<Blog> result = sqlconn.GetList<Blog>();
           Console.WriteLine("All blogs for tenant id {0}:", tenantId2);
           foreach (var item in result)
           {
               Console.WriteLine(item.Name);
           }
    }

Обработка временных сбоев

Команда Microsoft Patterns & Practices опубликовала блок приложений обработки временных сбоев, чтобы позволить разработчикам приложений устранять распространенные временные сбои при выполнении в облаке. Дополнительные сведения см. в статье Настойчивость — секрет всех побед: Использование блока приложения для обработки временных ошибок.

В примере кода для защиты от временных сбоев используется библиотека временных сбоев.

    SqlDatabaseUtils.SqlRetryPolicy.ExecuteAction(() =>
    {
       using (SqlConnection sqlconn =
          shardingLayer.ShardMap.OpenConnectionForKey(tenantId2, connStrBldr.ConnectionString, ConnectionOptions.Validate))
          {
              var blog = new Blog { Name = name2 };
              sqlconn.Insert(blog);
          }
    });

Политика SqlDatabaseUtils.SqlRetryPolicy в приведенном выше коде определена как SqlDatabaseTransientErrorDetectionStrategy с числом попыток, равным 10, и 5-секундным временем ожидания между повторами попытки. При использовании транзакций убедитесь, что при возникновении временного сбоя повтор начинается с начала транзакции.

Ограничения

Подходы, описанные в данном документе, имеют несколько ограничений:

• В примере кода для этого документа не показано, как управлять схемой для разных сегментов.
• Предполагается, что вся обработка в базе данных для выполнения запроса ведется в пределах одного сегмента, который идентифицируется ключом сегментирования, предоставленном в запросе. Тем не менее, это не всегда так, например, в случае, если невозможно сделать ключ сегментирования доступным. Для решения этой проблемы клиентская библиотека эластичной базы данных включает класс MultiShardQuery. Этот класс реализует абстракцию подключения для выполнения запросов нескольких сегментов. Использование MultiShardQuery вместе с Dapper выходит за рамки данного документа.

Заключение

Приложения, использующие Dapper и DapperExtensions, могут легко использовать преимущества средств эластичной базы данных SQL Azure. С помощью шагов, описанных в этом документе, приложения могут использовать возможности инструмента для маршрутизации, зависящей от данных. Для этого требуется изменить создание и открытие новых объектов SqlConnection, чтобы использовать вызов OpenConnectionForKey клиентской библиотеки эластичной базы данных. Это ограничивает внесение требуемых изменений в приложении местами создания и открытия новых подключений.

Связанный контент

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