REMARQUE : La documentation de présentation de la requête de base de données élastique Azure SQL Database (préversion) reprend les dernières informations concernant les requêtes de base de données élastique.

Nous sommes fiers d’annoncer différentes améliorations de la requête de base de données élastique dans Azure SQL Database. Le point le plus important est que la requête de base de données élastique prend désormais en charge les requêtes entre bases de données dans Azure SQL Database. Ceci permet de créer des tâches de requête entre bases de données, comme la sélection dans une table locale à partir d’une table distante.

Il est aussi possible de créer des topologies de requête de base de données distante plus complètes, comme celle illustrée dans la figure qui suit, dans laquelle plusieurs bases de données doivent avoir accès aux tables des autres bases de données.

Cette nouvelle capacité de requête entre bases de données complète la capacité actuelle de la requête de base de données élastique au partitionnement horizontal (sharding), illustré dans la figure suivante.

Par rapport à SQL Server local, la requête de base de données élastique dans Azure SQL Database unifie désormais le partitionnement vertical et horizontal, pour former un concept commun et une surface unique.

Les améliorations de la dernière version de la préversion de la requête de base de données élastique sont les suivantes :

• Meilleure prise en charge des scénarios courants de requête entre plusieurs bases de données qui n’impliquent pas de sharding.
• Fonctionnalité de requête élastique disponible dans les niveaux de performance Standard et Premium.
• DDL flexible qui permet que les alias de nom de schéma et de table puissent représenter les tables de bases de données distantes.
• Performances largement améliorées pour les requêtes impliquant des paramètres T-SQL dans les références aux tables distantes.
• Amélioration des performances pour les requêtes qui récupèrent un grand nombre d’enregistrements dans les bases de données distantes.
• Prise en charge des paramètres dans la procédure sp_execute_fanout.

Consultez le paragraphe suivant pour plus de détails sur ces améliorations.

Requêtes sur des bases de données distantes

La requête de base de données élastique donne accès aux tables dans les bases de données Azure SQL Database via une simple extension dans le DDL pour les sources de données externes et les tables externes. Vous pouvez définir une source de données externe qui par exemple fournit l’accès à une base de données distante qui contient les données de référence partagées dans toutes les bases de données de votre couche Données. Vous pouvez aussi facilement copier le contenu des tables d’une base de données distante dans d’autres tables avec une instruction INSERT INTO... SELECT.

Les sources de données qui font référence à une seule base de données distante sont identifiées par l’option RDBMS dans la clause TYPE de l’instruction DDL suivante :

CREATE EXTERNAL DATA SOURCE RemoteReferenceData
WITH
(
	TYPE=RDBMS,
	LOCATION='myserver.database.windows.net',
	DATABASE_NAME='ReferenceData',
	CREDENTIAL= SqlUser
);

D’après cette source de données externe, vous pouvez maintenant définir une table externe qui offre un accès à distance à une table de codes postaux (zipcode) qui se trouve dans la base de données ReferenceData database.

CREATE EXTERNAL TABLE [dbo].[zipcode](
	[zc_id] int NOT NULL,
	[zc_cityname] nvarchar(256) NULL,
	[zc_zipcode] nvarchar(20) NOT NULL,
	[zc_country] nvarchar(5) NOT NULL
)
WITH
(
	DATA_SOURCE = RemoteReferenceData
);

Après cette opération de configuration, que vous ne devez effectuer qu’une seule fois, vos requêtes ont accès à la table distante des codes postaux de n’importe quelle base de données Azure SQL Database dans laquelle la source de données externe et la table externe ont été définies.

Disponibilité sur plus de niveaux de performance

La requête de base de données élastique est désormais aussi disponible dans le niveau de performance Standard d’Azure SQL Database. Ceci réduit de façon significative le coût d’entrée pour les requêtes entre plusieurs bases de données et les scénarios de partitionnement dans Azure SQL Database. En raison des limites DTU plus basses dans le niveau de service Standard, l’initialisation de la requête de base de données élastique peut prendre jusqu’à une minute lorsque vous exécutez votre première requête de base de données distante. Nous travaillons activement à réduire la latence d’initialisation de la requête de base de données élastique. Cette partie de l’expérience devrait s’améliorer dans les mois à venir.

Attribution de noms plus flexible

Plusieurs scénarios importants doivent pouvoir donner à votre table externe un autre nom que celui qu’elle porte dans la base de données distante. Un bon exemple est un scénario dans lequel une table locale existe déjà avec le même nom que la table distante. Tous ces cas nécessitent de pouvoir utiliser un alias pour le nom de la table distante.

Par exemple, prenons un scénario dans lequel vous voulez qu’une définition de table externe agrège une DMV (Dynamic Management View) dans l’ensemble d’une couche Données partitionnée horizontalement. Auparavant, cette opération nécessitait d’appliquer des solutions complexes, comme le changement de nom de la DMV à l’aide d’une vue sur les bases de données distantes et une référence à cette vue depuis la définition de la table externe. Ces opérations étaient nécessaires, car les noms de DMV ou les noms de catalogues existaient déjà en local et ne pouvaient pas être utilisés directement comme noms de tables.

Vous pouvez désormais utiliser n’importe quel nom comme nom de table externe et identifier la table distante sous-jacente à l’aide des nouvelles clauses OBJECT_SCHEMA et OBJECT_NAME dans la DDL de la table externe. Ceci simplifie les requêtes sur les DMV ou les vues de catalogues de votre couche Données, comme le démontre l’exemple qui suit. Le code DDL (Data Definition Language) suivant effectue une opération de configuration unique de la source de données externe et de la base de données externe. Notez l’utilisation des clauses OBJECT_SCHEMA et OBJECT_NAME dans la définition de la table externe :

CREATE EXTERNAL DATA SOURCE MyExtSrc
WITH
(
	TYPE=SHARD_MAP_MANAGER,
	LOCATION='myserver.database.windows.net',
	DATABASE_NAME='ShardMapDatabase',
	CREDENTIAL= SMMUser,
	SHARD_MAP_NAME='ShardMap'
);

 

CREATE EXTERNAL TABLE [dbo].[all_dm_exec_requests](
	[session_id] smallint NOT NULL,
	[request_id] int NOT NULL,
	[start_time] datetime NOT NULL, 
	[status] nvarchar(30) NOT NULL,
	[command] nvarchar(32) NOT NULL,
	[sql_handle] varbinary(64),
	[statement_start_offset] int,
	[statement_end_offset] int,
	[cpu_time] int NOT NULL
)
WITH
(
	DATA_SOURCE = MyExtSrc,
	SCHEMA_NAME = 'sys',
	OBJECT_NAME = 'dm_exec_requests',
	DISTRIBUTION=ROUND_ROBIN
);

Vous pouvez désormais récupérer les demandes les plus chères de votre couche Données à l’aide d’une simple requête de base de données élastique comme celle-ci :

SELECT TOP 10 
	[request_id],
	[start_time]
	[status],
	[command]
FROM all_dm_exec_requests
ORDER BY [cpu_time] DESC

Nouvelle signature pour sp_execute_fanout

La requête de base de données élastique fournit la procédure stockée sp_execute_fanout pour invoquer les procédures stockées et les fonctions sur les bases de données distantes. Les récentes améliorations apportées à Azure SQL Database alignent désormais la signature de sp_execute_fanout sur la signature de sp_executesql. Ceci permet de transmettre les paramètres SQL normaux dans les invocations de sp_execute_fanout. Ceci sera disponible en début de semaine prochaine.

Améliorations des performances

Auparavant, la requête de base de données élastique ne pouvait pas envoyer les opérations avec paramètres vers les bases de données distantes. De ce fait, les grands jeux d’enregistrement devaient parfois être copiés localement pour évaluer ces opérations. Avec ces récentes améliorations, les opérations avec paramètres peuvent désormais être envoyées vers les bases de données distantes et évaluées à distance. Pour une requête sur une table externe et une table locale comme la suivante, ceci peut éviter de transférer des millions d’enregistrements en évaluant le filtre sélectif de la clause WHERE sur la base de données distante :

DECLARE @low int
DECLARE @high int
SET @low = 100
SET @high = 200

SELECT c.CustomerId, c.Name, count(OrderId) 
FROM remote_customers c
JOIN local_orders o
ON c.CustomerId = o.CustomerId 
WHERE c.CustomerId > @low and c.CustomerId < @high
GROUP BY c.CustomerId, c.Name

Un examen rapide du plan de requête de la requête ci-dessus confirme que le prédicat de plage sur CustomerId dans la clause WHERE est bien arrivé sur l’opérateur de requête distant.

Enfin, nous avons aussi optimisé le transfert de grands nombres d’enregistrements dans les requêtes de base de données élastiques. Nos tests présentent des améliorations pour les requêtes sur les tables externes avec des performances cinq fois supérieures lors du transfert de 100 000 enregistrements ou plus.

Pour en savoir plus sur les améliorations présentées ici, consultez la présentation sur les requêtes de base de données élastiques.