Grand ensemble de données géospatiales (> 22 billions d'éléments) avec des performances de requête de lecture rapide (<1 s)

Je suis en train de concevoir un nouveau système pour un grand ensemble de données géospatiales qui nécessitera des performances de requête de lecture rapide. Par conséquent, je veux voir si quelqu'un pense que c'est possible ou a de l'expérience / des conseils sur les SGBD appropriés, la structure de données ou d'autres méthodes pour atteindre les performances requises dans la situation suivante:

Les données seront produites en continu à partir des données radar satellitaires traitées, qui auront une couverture mondiale. Sur la base de la résolution des satellites et de la couverture terrestre du globe, j'estime l'ensemble de données complet pour produire des valeurs à 75 milliards d'emplacements discrets sur le globe. Au cours de la durée de vie d'un seul satellite, la sortie produira jusqu'à 300 valeurs à chacun de ces emplacements (donc un ensemble de données total de> 22 billions de valeurs). C'est pour un satellite, et il y en a déjà un deuxième en orbite, avec deux autres prévus dans les nouvelles années. Il y aura donc beaucoup de données! Un seul élément de données est très simple et ne comprendra que (longitude, latitude, valeur), mais en raison du nombre d'éléments, j'estime qu'un seul satellite produira jusqu'à 100 To.

Les données écrites ne devraient jamais avoir besoin d'être mises à jour, car elles ne feront qu'augmenter à mesure que de nouvelles acquisitions de satellites seront traitées. Les performances d'écriture ne sont pas importantes, mais les performances de lecture sont cruciales. L'objectif de ce projet est de pouvoir visualiser les données via une interface simple telle qu'une couche sur google maps, où chaque point a une valeur colorée basée sur sa moyenne, son gradient ou une fonction dans le temps. (démo en fin de post).

À partir de ces exigences, la base de données doit être évolutive et nous sommes susceptibles de nous tourner vers des solutions cloud. Le système doit être capable de traiter des requêtes géospatiales telles que "points proches (lat, lon)" et "points dans (case)", et avoir des performances de lecture <1s pour localiser un seul point, et des polygones qui contiennent jusqu'à 50 000 points (bien que jusqu'à 200 000 points soient préférables).

Jusqu'à présent, j'ai un ensemble de données de test d'environ 750 millions d'éléments de données sur 111 millions d'emplacements. J'ai testé une instance postgres / postGIS, qui a bien fonctionné, mais sans possibilité de partitionnement, je ne le fais pas, cela pourra s'adapter à mesure que les données augmentent.J'ai également testé une instance mongoDB, qui semble à nouveau OK, donc loin, et avec le partage, il pourrait être suffisant de s'adapter au volume de données. J'ai récemment appris un peu sur elasticsearch, donc tout commentaire à ce sujet serait utile car c'est nouveau pour moi.

Voici une animation rapide de ce que nous voulons réaliser avec l'ensemble de données complet:

Ce gif (de mon essai postgres) sert (6x3) des tuiles raster pré-calculées, chacune contenant ~ 200 000 points et prenant ~ 17s pour générer chacune. En cliquant sur un point, le graphique est créé en tirant toutes les valeurs historiques à l'emplacement le plus proche en <1 s.

Toutes mes excuses pour le long post, tous les commentaires / conseils sont les bienvenus.

Vous pouvez tailler par emplacement. Partitionnez le globe en une grille et disposez chaque carré de cette grille sur un serveur. Puisque vous avez mentionné le cloud, ce serait bien adapté au cloud. Bien sûr, vous devrez fusionner manuellement les résultats de plusieurs serveurs.

De cette façon, vous pouvez utiliser n'importe quelle solution de base de données comme vous le souhaitez. Il n'a pas besoin d'être évolutif en soi.

Les carrés individuels auront différentes quantités de données. Vous pouvez utiliser des machines de tailles différentes pour eux (car il s'agit du cloud), ou vous mettez plusieurs petits fragments sur la même machine.

Ce schéma de partage est idéal pour le type de requêtes que vous effectuez, car chaque requête ne devra toucher que très peu de fragments. Le partage temporel est pire car tous les fragments temporels doivent être touchés pour chaque requête. Le partage aléatoire a le même problème.

Dans l'ensemble, c'est un cas de partitionnement facile car le modèle de requête correspond si bien au schéma de partitionnement.

En fait, je me demande si vous avez besoin d'une base de données pour cela. Vous pouvez peut-être partitionner le globe en tuiles de 1 000 x 1 000 ou plus petites et avoir un fichier plat dans le stockage d'objets blob pour chaque tuile. Le stockage d'objets blob ne dérange pas du tout les objets blob 1M.

L'exécution d'une requête est conceptuellement très facile avec ce schéma de stockage. Vous pouvez également stocker les données de manière redondante dans plusieurs résolutions de grille.

Quelle doit être la mise à jour de vos requêtes de lecture?

Vous pouvez partitionner la base de données par le temps si la carte a juste besoin d'afficher la mesure la plus récente. Cela réduirait la charge de votre requête pour la carte.

Pour l'historique d'un point donné, vous pouvez tenir un deuxième magasin par x et y affichant l'historique. Cela pourrait être fait avec une actualisation / mise à jour nocturne car les données historiques ne changeront pas.

Vous pouvez ensuite pré-calculer des moyennes à des résolutions plus grossières pour les intégrer à des cartes à différents niveaux de zoom. Cela réduirait le nombre de points à récupérer pour les grandes zones de la carte (zoom arrière). Des résolutions plus fines seraient utilisées pour des cartes plus zoomées qui interrogeaient des zones plus petites. Si vous avez vraiment besoin d'accélérer cela, vous pouvez calculer les tuiles comme des blobs et les interpréter dans votre application.

Étant donné que cela impliquerait un recalcul des informations agrégées, il y aurait une certaine latence dans les résultats des requêtes. Selon la latence acceptable, vous pouvez utiliser ce type d'approche pour optimiser vos lectures.

OK, vos points doivent donc être calculés en moyenne dans le temps. Avec ce calcul, je suppose que vos requêtes réelles descendent beaucoup de 22 billions d'éléments, car les valeurs raster peuvent être pré-calculées pour les requêtes.

Il semble qu'il existe deux classes de requête - une pour comprendre quels emplacements se trouvent dans la fenêtre de vue actuelle et une seconde pour fournir les statistiques souhaitées pour ces points. Ma suggestion est d'utiliser des outils distincts et spécialisés pour chacun.

Je suppose que toutes les mesures se rapportent au même ensemble de points 75 milliards. Ces lat / longs, une fois établis, sont donc statiques. Ils peuvent être regroupés, agrégés et indexés à un coût unique. Par conséquent, je suggérerais un partage par région et niveau de zoom. La taille de chaque fragment dépendra des performances pouvant être obtenues à partir de chaque instance SIG.

Le SIG renverra un ensemble de points qui seront transmis à une base de données de séries chronologiques. Cela contient les valeurs mesurées et effectue des agrégats. KDB est celui que je connais. Il cible le trading de titres, qui aura moins de clés mais plus de points de données par clé que votre scénario.

Le transfert des valeurs clés du serveur SIG vers la base de données de la série temporelle entraînera un coût. Mon hypothèse est que ce coût sera remboursé par un traitement plus rapide dans la base de données de séries temporelles spécifiques aux tâches. D'après le libellé de la question, il semble qu'une seule instance ne pourra pas conserver toutes les données, de sorte qu'un trafic inter-serveurs semble inévitable. Compte tenu de la vitesse relative des composants, il semble probable que l'envoi d'un jeu de clés à un serveur distant dont les données sont mises en cache sera plus rapide que la lecture des données sur le disque local.

Si les parties de recherche de points et de calcul de valeur peuvent être locales les unes par rapport aux autres, je m'attends bien sûr à ce que la réponse soit plus rapide. Ma compréhension (limitée) est que trouver les N voisins les plus proches d'un point donné est une tâche non triviale. C'est pourquoi j'ai suggéré d'utiliser un logiciel spécifique pour l'exécuter. Si la recherche de points peut être réduite à

where latitude between x1 and x2
and logitude between y1 and y2

alors cette partie pourrait être gérée par le logiciel de stockage de valeur et le SIG éliminé de l'architecture.

Je n'ai pas mis en place un tel système. Je pense vraiment à haute voix ici. À l'échelle du pétaoctet, il n'y a pas de solutions standard. Il existe cependant de nombreux fournisseurs de données par satellite, de sorte que votre problème est traitable. Bonne chance.