Si vous ne savez ni quand, ni comment ni pourquoi… passez au NoSQL

Catégorie: Données, INSPIRE, Logiciels, Reportages

822 mots

Fondateur de NeoGeo Technologies, Guillaume Sueur supervise et réalise de nombreux développements dans le domaine de la géomatique. Il suit de près l’actualité des nouveaux outils et s’intéresse donc au NoSQL. Il revient sur les questions à se poser avant de se lancer.

Que faut-il savoir sur le NoSQL ?

Rappelons d’abord pourquoi le NoSQL a émergé. Il est né des besoins exponentiels de stockage de données auxquels ont été confrontés les grands acteurs de l’Internet comme Google, Facebook, Amazon à la fin des années 2000. Il leur était alors nécessaire de trouver des solutions pour gérer des volumes croissants de données en production continue sans débrancher la prise pour ajouter un disque. Ils ont inventé des systèmes de bases de données ou de fichiers scalables, redimensionnables à l’envi, organisés en clusters tolérants à la panne. Ce faisant, ils ont privilégié des structures simples (peu ou non relationnelles), des standards ouverts (http pour la communication, JSON pour le format) qui rendent ces applications plutôt agnostiques quant à leur contenu. On a ainsi des implémentations orientées clé-valeur, très utiles pour faire des caches web, d’autres clé-colonnes, avec un nombre de colonnes libre selon les enregistrements, d’autres orientées documents (structures complexes non prédéfinies) voire même orientées graphes. C’est ce dernier type qu’utilise Amazon pour proposer des recommandations.

Ce sont des préoccupations assez éloignées de celles des géomaticiens. Du coup, en quoi peuvent-ils être concernés ?

Le NoSQL adresse effectivement des besoins qui ne sont pas encore au cœur de nos métiers. Mais l’émergence de l’Internet des objets et des capteurs qui alimentent les SIG plus ou moins en continu est en train de changer la donne. Sur les thèmes de la mobilité, des villes intelligentes… le NoSQL est une réponse intéressante au volume désormais croissant de données à ingérer et à conserver. L’enjeu n’est pas tant la taille, car on sait provisionner les téraoctets nécessaires à un besoin, mais bien la souplesse dans la montée en charge, pour ne pas provisionner 50 téraoctets quand un seul est utilisé, tout en se gardant la possibilité de grimper rapidement à 200 si nécessaire.

Quels sont les avantages du NoSQL pour stocker des données géographiques ?

Le NoSQL permet de gérer des données sans prévoir à l’avance l’espace de stockage nécessaire. La métropole de Lyon envisage par exemple de stocker et conserver l’historique de l’ensemble des données sur le trafic routier, issues de nombreux capteurs. Il est impossible d’anticiper la taille des serveurs qui seront nécessaires dans cinq ou dix ans, ni les usages à venir (consultation, modélisation, Machine learning…). Autre gros avantage, la simplicité des schémas d’organisation et leur robustesse au changement. Quiconque gère des bases SQL sait ce que représente l’introduction d’une nouvelle variable, un changement dans la codification d’une colonne, l’ajout d’une nouvelle table, etc. Avec le NoSQL, c’est beaucoup plus simple et il est très facile de reconnecter des jeux de données entre eux, sans avoir besoin de tout restructurer. Cette structuration bien plus légère permet en outre de concevoir ses bases sans vraiment se préoccuper de la façon dont elles vont être interrogées. Quand on ne sait pas « quand », « comment » ou « pourquoi » on doit stocker de gros volumes de données, le NoSQL est bien indiqué.

Et côté inconvénients ?

Les relations géographiques en NoSQL ne sont pas très élaborées, et du coup, les mécanismes d’indexation et d’interrogation sont assez limités. Tout au plus trouve-t-on aujourd’hui des notions de proximité, d’intersection et d’inclusion. Même remarque du côté des objets géographiques décrits, qui restent très simples : points, lignes et polygones. Mais les outils savent ce qu’est une donnée géographique. Mongo DB par exemple, dispose d’une cartouche spatiale. Et Elastic Search, qui comprend un moteur de recherche, intègre différents objets géographiques et quelques opérateurs spatiaux. Pour l’instant, il n’y a aucun traitement topologique et pas de gestion des projections. En NoSQL, vous ne pourrez pas optimiser des relations ou des index complexes entre objets géographiques.

Comment dépasser ces limitations ?

Un SIG peut tout à fait être alimenté à la fois par des données gérées en NoSQL et dans des bases relationnelles classiques. Les traitements peuvent associer les deux univers. Un outil tel que MapReduce est très intéressant pour lancer des traitements parallèles sur de gros volumes de données, mais les résultats peuvent ensuite être analysés et présentés sous une forme plus élaborée dans les SIG. Les formats JSON et GeoJSON, les API… tout est très ouvert dans le monde du NoSQL. Les données, les traitements, sont donc assez facilement intégrables dans des chaînes de traitements plus complexes, dans des surcouches applicatives. FME par exemple permet d’alimenter des bases NoSQL. MapServer ou GeoServer savent lire MongoDB et générer des flux INSPIRE à partir de ces outils. Le NoSQL a donc toute sa place dans la chaîne de traitement et de publication de l’information géographique !