Comparaison spatiale lente lors de l'utilisation de la jointure croisée

Question

J'utilise U-SQL pour sélectionner tous les objets qui se trouvent dans une ou plusieurs des formes. Le code fonctionne mais est vraiment lent. Y a-t-il un moyen de le rendre plus performant?

@rs1 = 
    SELECT DISTINCT aisdata.imo, 
        portshape.unlocode 
    FROM @lsaisdata AS aisdata 
     CROSS JOIN 
      @portsshape AS portshape 
    WHERE Geometry.STMPolyFromText(new SqlChars(portshape.shape.Replace("Z", "").ToCharArray()), 0).STContains(Geometry.Point(aisdata.lon, aisdata.lat, 0)).IsTrue; 

a ajouté plus d'informations sur ma question:

• Je me suis inscrit Microsoft.SqlServer.Types.dll et SqlServerSpatial130.dll pour pouvoir utiliser les fonctions spatiales en U-SQL
• I J'exécute mon travail dans Data Lake Analytics en utilisant deux AU. Initialement, j'ai utilisé 10 AU, mais l'onglet Diagnostics indiquait que le travail était de 8 UAs alloué en excès et AU maximum était de 2.
• Le travail prend environ 27 minutes pour exécuter avec le code UDT ci-dessous et la jointure croisée prend presque tout de ce temps
• L'entrée est un fichier csv (66 Mo) et un fichier wkt (2.4 Mb)
• J'utilise Visual studio 2015 avec les outils Azure données Lac v2.2.5000.0
• J'ai essayé encapsulant une partie du code spatial dans les UDT et qui a amélioré la performance à 27 minutes:

@rs1 =
SELECT DISTINCT aisdata.imo,
portshape.unlocode
FROM @lsaisdata AS aisdata
CROSS JOIN
@portsshape AS portshape WHERE portshape.geoShape.GeoObject.STContains(SpatialUSQLApp.CustomFunctions.GetGeoPoint(aisdata.lon, aisdata.lat).GeoObject).IsTrue;

Answer 1

D'abord, un CROSS JOIN aura toujours exploser vos données à une matrice NxM. En fonction du nombre de lignes, cela peut soit rendre très coûteux et peut-être difficile d'estimer le degré de parallélisme correct. Deuxièmement, je suppose que la jointure Spatiale que vous faites est une opération coûteuse. Par exemple, si vous utilisez les capacités spatiales de SQL Server 2012 (les implémentations natives du type peuvent être un peu plus rapides en 2016), je suppose que vous obtenez probablement un comportement de performances similaire. La plupart du temps, vous avez besoin d'un index spatial pour obtenir de meilleures performances. Maintenant, U-SQL ne supporte pas les index spatiaux, mais vous pourriez probablement approcher le même comportement en utilisant une abstraction (comme la tessellation des objets et en déterminant s'ils se chevauchent), pour fournir un pré-filtre/joint plus rapide avant de tester la condition pour éliminer les faux positifs.