Vue d’ensemble de la requête élastique Azure SQL Database (préversion)

S’applique à :Azure SQL Database

La fonctionnalité de requête élastique, en préversion, vous permet d’exécuter une requête Transact-SQL (T-SQL) qui s’étend sur plusieurs bases de données dans Azure SQL Database. Il vous permet d’effectuer des requêtes inter-bases de données pour accéder aux tables distantes et de connecter des outils Microsoft et non-Microsoft (Excel, Power BI, Tableau, etc.) à interroger des niveaux de données avec plusieurs bases de données. Cette fonctionnalité permet la répartition des requêtes à des couches de données de grande taille et de visualiser les résultats dans les rapports décisionnels.

Pourquoi utiliser les requêtes élastiques

Azure SQL Database

Interrogez plusieurs bases de données dans Azure SQL Database entièrement en T-SQL. Cela permet d’interroger en lecture seule les bases de données distantes et donne aux clients SQL Server actuels la possibilité de migrer des applications en utilisant des noms en trois et quatre parties ou un serveur lié vers SQL Database.

Disponible sur tous les niveaux de service

La requête élastique est prise en charge dans tous les niveaux de service d’Azure SQL Database. Consultez la section relative aux limitations de la préversion ci-dessous pour connaître les limitations de performances pour les niveaux de service inférieurs.

Pousser les paramètres vers les bases de données distantes

Les requêtes élastiques peuvent désormais envoyer les paramètres SQL aux bases de données distantes pour exécuter des opérations.

Exécution d’une procédure stockée

Exécutez des appels de procédures stockées ou de fonctions distantes avec sp_execute _remote.

Souplesse

Les tables externes avec requête élastique peuvent faire référence à des tables distantes avec un schéma ou un nom de table différent.

Scénarios de requête élastique

L’objectif est de simplifier les scénarios d’interrogation dans lesquels plusieurs bases de données fournissent des lignes, regroupées au sein d’un résultat global unique. Cette requête peut être composée directement par l'utilisateur ou l'application, ou indirectement via des outils connectés à la base de données. Ceci est particulièrement utile pendant la création de rapports, à l’aide des outils commerciaux d’intégration BI ou de données, ou toute application qui ne peut pas être changée. Avec une requête élastique, vous pouvez interroger facilement plusieurs bases de données à l’aide de l’expérience de connectivité SQL Server familière d’outils tels qu’Excel, Power BI, Tableau ou Cognos. Une requête de base de données élastique offre un accès facile à un ensemble complet de bases de données via des requêtes émises par SQL Server Management Studio ou Visual Studio, et permet l’interrogation des diverses bases de données croisées à partir d’Entity Framework ou d’autres environnements ORM. La figure 1 illustre un scénario dans lequel une application cloud existante (qui utilise la bibliothèque cliente de base de données élastique) s’appuie sur une couche Données avec montée en charge et une requête élastique est utilisée pour les rapports entre plusieurs bases de données croisées.

Figure 1 Requête élastique utilisée sur la couche de données mise à l’échelle

Les scénarios clients pour une requête élastique sont caractérisés par les topologies suivantes :

• Partitionnement vertical - Requêtes de base de données croisées (topologie 1) : les données sont réparties verticalement entre plusieurs bases de données dans un niveau de données. En règle générale, les différents ensembles de tables résident sur des bases de données différentes. Cela signifie que le schéma est différent sur des bases de données différentes. Par exemple, toutes les tables d’inventaire se trouvent sur une base de données alors que toutes les tables liées à la comptabilité se trouvent dans une seconde base de données. Les scénarios d’utilisation courants avec cette topologie requièrent une interrogation ou la compilation de rapports englobant des tables de plusieurs bases de données.

• Partitionnement horizontal - Sharding (topologie 2) : les données sont partitionnées horizontalement pour répartir les lignes dans un niveau de données réparti. Avec cette approche, le schéma est identique sur toutes les bases de données participantes. Cette approche est également appelée sharding. Ce partitionnement est effectué et géré à l’aide de (1) la bibliothèque d’outils de base de données élastique ou (2) la fonction d’auto-partitionnement. Une requête élastique est utilisée pour interroger ou compiler des rapports sur plusieurs fragments. Les fragments sont généralement des bases de données au sein d’un pool élastique. Vous pouvez considérer la requête élastique comme un moyen efficace d’interroger toutes les bases de données d’un pool élastique en même temps, à condition que les bases de données partagent le même schéma.

Le partitionnement vertical - requêtes de bases de données croisées

Pour commencer le codage, voir Prise en main des requêtes de bases de données croisées (partitionnement vertical).

Une requête élastique peut être utilisée pour mettre les données situées dans une base de données SQL Database à la disposition d’autres bases de données SQL Database. Ainsi, les requêtes issues d’une base de données peuvent faire référence à des tables dans n’importe quelle autre base de données distante dans SQL Database. La première étape consiste à définir une source de données externe pour chaque base de données distante. La source de données externe est définie dans la base de données locale à partir de laquelle vous souhaitez accéder aux tables situées sur la base de données distante. Aucune modification de la base de données distante n’est nécessaire. Pour les scénarios verticaux dans lesquels les différentes bases de données comportent des schémas différents, les requêtes élastiques peuvent être utilisées pour implémenter des scénarios d’utilisation courants tels que l’accès aux données de référence et l’interrogation de bases de données croisées.

Données de référence : la topologie est utilisée pour la gestion des données de référence. Dans la figure suivante, deux tables (T1 et T2) avec des données de référence sont conservées sur une base de données dédiée. Avec une requête élastique, vous pouvez désormais accéder aux tables T1 et T2 à distance depuis d’autres bases de données, comme indiqué dans la figure. Utilisez la topologie 1 si les tables de référence sont petites ou si les requêtes distantes vers les tables de référence ont des prédicats sélectifs.

Figure 2 Partitionnement vertical -Utilisation d’une requête élastique pour interroger des données de référence

Interrogation de plusieurs bases de données : les requêtes élastiques autorisent les cas d’usage qui nécessitent l’interrogation de plusieurs bases de données dans SQL Database. La figure 3 présente quatre bases de données différentes : CRM, Inventaire, Ressources humaines et Produits. Les requêtes exécutées dans une des bases de données doivent également accéder à une ou à toutes les autres bases de données. Avec une requête élastique, vous pouvez configurer votre base de données pour ce cas en exécutant plusieurs instructions DDL simples sur chacune des quatre bases de données. Après cette configuration à usage unique, l’accès à une table distante se fait simplement en faisant référence à une table locale à partir de vos requêtes T-SQL ou de vos outils d’analyse décisionnelle. Cette approche est recommandée si les requêtes distantes ne renvoient pas de résultats volumineux.

Figure 3 Partitionnement vertical - Utilisation de requête élastique pour l’interrogation de plusieurs bases de données

Les étapes suivantes configurent des requêtes de base de données élastiques pour des scénarios de partitionnement vertical qui requièrent l’accès à une table située sur des bases de données distantes dans SQL Database avec le même schéma :

• CRÉER UNE CLÉ MAÎTREmymasterkey

• CRÉER DES INFORMATIONS D’IDENTIFICATION DÉLIMITÉES À LA BASE DE DONNÉESmycredential

• CRÉER UNE SOURCE DE DONNÉES EXTERNEmydatasource de type RDBMS

• CRÉER UNE TABLE EXTERNEmytable

Après avoir exécuté les instructions DDL, vous pouvez accéder à la table distante mytable comme s’il s’agissait d’une table locale. Azure SQL Database ouvre automatiquement une connexion à la base de données distante, traite votre demande sur la base de données distante et retourne les résultats.

Partitionnement horizontal - sharding

L’utilisation d’une requête élastique destinée à effectuer des tâches de création de rapports sur une couche de données partitionnée exige un mappage de partitionnement de base de données élastique pour représenter les bases de données de la couche de données. En règle générale, une seule table de fragments est utilisée dans ce scénario, et une base de données partitionnée dédiée avec des fonctions d’interrogation élastique (nœud principal) fonctionne comme point d'entrée pour les requêtes de rapport. Seule cette base de données dédiée doit avoir accès à la carte de fragments. La figure 4 illustre cette topologie et sa configuration avec la base de données de requête élastique et du mappage de partition. Pour plus d’informations sur la bibliothèque cliente de base de données élastique, consultez gestion de mappage de partition.

Figure 4 partitionnement horizontal : utilisation d’une requête élastique pour les rapports sur les couches de données partitionnées

Les étapes suivantes configurent des requêtes de base de données élastiques pour des scénarios de partitionnement horizontal qui requièrent l’accès à un ensemble de tables généralement situées sur plusieurs bases de données distantes dans SQL Database :

• CRÉER UNE CLÉ MAÎTREmymasterkey

• CRÉER DES INFORMATIONS D’IDENTIFICATION INCLUSES DANS L’ÉTENDUE DE LA BASE DE DONNÉESmycredential.

• Créer un mappage de partition représentant votre couche de données à l’aide d’une bibliothèque de base de données élastique cliente.

• CREATE EXTERNAL DATA SOURCEmydatasource de type SHARD_MAP_MANAGER.

• CRÉER UNE TABLE EXTERNEmytable

Une fois que vous avez effectué ces opérations, vous pouvez accéder à la table partitionnée horizontalement mytable comme s’il s’agissait d’une table locale. Azure SQL Database ouvre automatiquement plusieurs connexions parallèles aux bases de données distantes dans laquelle dans lesquelles les tables sont stockées physiquement, traite les requêtes sur les bases de données distantes et retourne les résultats. Vous trouverez d’autres informations sur les opérations requises pour le scénario de partitionnement horizontal dans Requête élastique pour le partitionnement horizontal.

Pour commencer à coder, veuillez consulter Premiers pas avec la requête élastique pour le partitionnement horizontal (sharding).

Requêtes T-SQL

Après avoir défini votre source de données externe et vos tables externes, vous pouvez utiliser les chaînes de connexion SQL Server pour vous connecter aux bases de données dans lesquelles vous avez défini vos tables externes. Vous pouvez ensuite exécuter des instructions T-SQL sur vos tables externes sur cette connexion avec les limitations décrites plus loin dans cet article. Vous trouverez plus d’informations et des exemples de requêtes T-SQL dans les articles de la documentation sur le partitionnement horizontal et le partitionnement vertical.

Sources de données externes sécurisées

Une LOCATION source de données externe peut identifier un point de terminaison SQL par un nom de domaine entièrement qualifié (FQDN) ou une adresse IP, y compris un point d'extrémité qui n'est pas un serveur logique Azure SQL Database. Lorsqu’une requête élastique s’exécute, elle envoie les informations d’authentification, le texte de la requête, les paramètres et toutes les données transférées par la requête vers le point de terminaison configuré. Configurez uniquement les sources de données externes pour les terminaux en lesquels votre organisation a confiance.

Seuls les principaux titulaires avec ALTER ANY EXTERNAL DATA SOURCE la permission peuvent créer ou modifier une source de données externe. Limitez cette autorisation aux administrateurs de bases de données qui en ont besoin, et examinez périodiquement les sources de données externes en interrogeant sys.external_data_sources.

En tant que contrôle réseau distinct, un administrateur réseau restreint le réseau sortant et autorise uniquement les FQDN de destination approuvés pour le serveur logique. Utilisez un FQDN au lieu d’une adresse IP dans chaque source de données externe afin que sa destination puisse être explicitement indiquée. Séparer la configuration de la base de données de l’approbation réseau met en place la séparation des tâches et empêche un administrateur de base de données d’établir un chemin de communication non approuvé sans modification indépendante de la politique réseau.

Connectivité des outils

Vous pouvez utiliser des chaînes de connexion SQL Server standard pour connecter vos applications et les outils d’intégration BI ou données aux bases de données qui ont des tables externes. Assurez-vous que SQL Server est pris en charge comme source de données pour votre outil. Une fois connecté, vous pouvez traiter la base de données de requête élastique et les tables externes de cette base de données comme n’importe quelle autre base de données SQL Server à laquelle vous vous connectez avec votre outil.

Coût

La requête élastique est incluse dans le coût d’Azure SQL Database. Topologies où vos bases de données distantes se trouvent dans un centre de données différent du point de terminaison de requête élastique sont prises en charge, mais la sortie des données à partir de bases de données distantes est facturée régulièrement aux tarifs Azure.

Limitations de la version préliminaire

• Lancer votre première requête élastique peut prendre quelques minutes sur les ressources plus petites et les niveaux de service Standard et Général. Ce délai est nécessaire au chargement de la fonctionnalité de requête flexible ; les performances de chargement s’améliorent avec les niveaux de service et les tailles de calcul supérieurs.

• Une requête élastique prend actuellement en charge uniquement les accès en lecture seule à des tables externes. Vous pouvez toutefois utiliser des fonctionnalités Transact-SQL complètes sur la base de données dans laquelle la table externe est définie. Cela peut être utile pour, par exemple, conserver des résultats temporaires à l’aide de SELECT <column_list> INTO <local_table>, ou pour définir des procédures stockées sur la base de données de requête élastique qui font référence à des tables externes.

• À l'exception de nvarchar(max), les types LOB (y compris les types spatiaux) ne sont pas pris en charge dans les définitions de table externe. Pour contourner ce problème, vous pouvez créer une vue sur la base de données distante qui convertit le type LOB en nvarchar(max), définir votre table externe sur la vue au lieu de la table de base, puis le reconvertir en type LOB d’origine dans vos requêtes.

• Les colonnes de type de données nvarchar(max) dans le jeu de résultats désactivent les techniques avancées de traitement par lots utilisées dans l’implémentation de requête élastique et peuvent affecter les performances de la requête pour un ordre de grandeur, voire deux ordres de grandeur dans les cas d’usage non canoniques où une grande quantité de données non agrégées est transférée à la suite de la requête.

• Les statistiques des colonnes des tables externes ne sont actuellement pas prises en charge. Les statistiques des tables sont prises en charge, mais doivent être créées manuellement.

• Les curseurs ne sont pas pris en charge pour les tables externes dans Azure SQL Database.

• Les scénarios de requête élastiques documentés et pris en charge dans cet article utilisent Azure SQL Database comme source de données distante. La syntaxe de la source de données externe ne se limite LOCATION pas à un serveur logique Azure SQL Database. Protégez toute destination configurée comme décrit dans Sources de données externes sécurisées.

• Actuellement, les liaisons privées ne sont pas prises en charge avec la requête élastique pour les bases de données cibles de sources de données externes.

Contenu connexe

• Introduction aux requêtes inter-bases de données (partitionnement vertical) (aperçu)
• Interroger des bases de données cloud de schémas différents (préversion)
• Créer des rapports sur des bases de données cloud avec montée en charge (version préliminaire)
• Création de rapports sur des bases de données cloud mises à l’échelle (version préliminaire)
• sp_execute_remote (Azure SQL Database)