Nous utilisons Google AppEngine pour exécuter des requêtes spatiales / d'attributs et le principal problème (dès le premier jour) est de savoir comment indexer de grands ensembles de lignes / polygones de taille arbitraire. Les données ponctuelles ne sont pas trop difficiles (voir geohash, geomodel, etc.) mais les ensembles de petits / grands polygones regroupés de manière aléatoire ont toujours été un problème (et dans certains cas, le sont toujours)
J'ai essayé plusieurs versions différentes de l'indexation spatiale sur GAE, mais la plupart ne sont que des variantes de deux ci-dessous. Aucun n'était aussi rapide que les bases de données SQL et tous ont des avantages / inconvénients. Cependant, les compromis semblent raisonnables pour la plupart des applications de cartographie basées sur Internet. En outre, les deux ci-dessous doivent être couplés à une élimination de la géométrie en mémoire (via JTS, etc.) pour supprimer toutes les fonctionnalités qui ne correspondent pas aux paramètres de recherche finaux. et enfin, ils s'appuient sur des fonctionnalités spécifiques à GAE mais je suis sûr qu'il pourrait être appliqué à d'autres architectures (ou utiliser TyphoonAE pour fonctionner sur un cluster Linux, ec2, etc.)
Grilles - Emballez toutes les fonctionnalités d'une certaine zone dans un index de grille connu. Placez un petit index spatial sur la grille afin de parcourir rapidement l'ensemble des entités qu'il contient. Pour la plupart des requêtes, vous n'aurez besoin que de tirer une poignée de grilles, ce qui est rapide, car vous connaissez la convention de dénomination exacte de la grille et sa relation avec les entités K / V (obtient, pas les requêtes)
Avantages - assez rapide, facile à mettre en œuvre, pas d'empreinte mémoire.
Inconvénients - un prétraitement est nécessaire, l'utilisateur doit décider de la taille de la grille, les grandes géométries sont partagées sur plusieurs grilles, le clustering peut entraîner une surcharge des grilles, les coûts de sérialisation / désérialisation peuvent être un problème (même lorsqu'ils sont compressés via des tampons de protocole)
QuadKeys - Il s'agit de l'implémentation actuelle. Fondamentalement, c'est la même chose que Grids, sauf qu'il n'y a pas de niveau de grille défini. au fur et à mesure que des fonctionnalités sont ajoutées, elles sont indexées par la grille à quatre clés qui contient complètement leurs limites (ou, dans certains cas, divisées en deux lorsqu'une seule quadruple clé ne peut pas être utilisée, pensez à la ligne de données). Une fois le qk trouvé, il est ensuite divisé en un nombre maximum de qk plus petits qui fournissent des représentations de grain plus fines de l'entité. un pointeur / bbox vers cette fonctionnalité est ensuite compressé dans un gridindex léger (groupe de fonctionnalités) qui peut être interrogé (une conception originale a interrogé directement les fonctionnalités mais cela s'est avéré trop lent / intensif en CPU dans les cas où l'ensemble de résultats était grand)
Quadline de polyligne http://www.arc2earth.com/images/help/GAE_QKS_1.png
Quadkeys de polygone http://www.arc2earth.com/images/help/GAE_QKS_2.png
La convention de dénomination quadruple utilisée ci-dessus est bien connue et, plus important encore, tend à préserver la localité (décrite plus ici )
Le polygone ci-dessus ressemble à ceci: 0320101013123 03201010131212 03201010131213 0320101013132 0320101013133 03201010131302 032010101313303 032010101313002 032010101313003 032010101313012 032010101313013 032010101313101313131313131313131313101013131013131010
si les limites de la requête sont suffisamment petites, vous pouvez directement récupérer via le qk. ceci est optimal car il ne s'agit que d'un seul appel rpc par lots à la banque de données GAE. si les limites sont suffisamment grandes pour inclure trop de qks possibles (> 1000), vous pouvez également interroger en utilisant un filtre (ex: qk> = 0320101013 et qk <= 0320101013 + \ ufffd). La convention de dénomination à quatre clés ainsi que la façon dont GAE indexe les chaînes permet à la requête ci-dessus d'extraire uniquement les grilles existantes qui sont inférieures à cette valeur qk.
il y a d'autres mises en garde et problèmes de perf mais en général, sa capacité à interroger sur les quadkeys qui le rend possible
exemples - requête sur les comtés américains: geojson
Avantages - assez rapide, pas de configuration de taille de grille, pas d'empreinte mémoire, pas de grilles surchargées
Inconvénients - prétraitement nécessaire, sur-extraction possible dans certains scénarios, pas de données polaires
Courbes de remplissage d'espace - Jetez un coup d'œil à la présentation des requêtes NextGen d'Alfred à Google I / O cette année. L'inclusion de courbes génériques de remplissage espace / temps ainsi que les nouveaux opérateurs MultiQuery (exécutés en parallèle) permettront des requêtes spatiales vraiment cool. Va-t-il battre les performances SQL traditionnelles? Difficile à dire mais ça devrait très bien évoluer. Et nous approchons rapidement d'un avenir où des appareils mobiles toujours connectés de toutes formes / tailles augmenteront considérablement le trafic vers votre site / service.
enfin, je conviens également que vous devriez examiner de très près votre domaine problématique avant de choisir NoSQL plutôt que SQL. Dans notre cas, j'ai vraiment aimé le modèle de tarification de GAE, donc il n'y avait vraiment pas de choix mais si vous n'avez pas besoin de faire évoluer, gagnez du temps et utilisez simplement un db sql standard