Big Data et données non structurées: PostgreSQL n’a pas dit son dernier mot !

Un sujet revient toujours sur la table dès que l'on parle de bases de données: le « mouvement NoSQL » incarné par MongoDB, Cassandra ou encore Couchdb semble voler la vedette aux SGBD relationnels qui semblent tout à coup un peu dépassés… Qu’en est-il vraiment ?

Le NoSQL (pour «Not Only SQL  »), acronyme qui a fait son apparition a la fin des années 1990, s’est retrouvé ces dernières années propulsé sur le devant de la scène pour avoir su conquérir quelques entreprises de renom du Web 2.0, parmi lesquelles Facebook, Twitter, Google, Digg, Amazon ou encore LinkedIn. Des entreprises aussi florissantes que gourmandes en données informationnelles ou utilisateurs. C’est justement la masse de ces données qui les a poussées à se tourner vers le NoSQL en raison de sa capacité de traiter d’énormes quantités de données de manière très rapide et fiable. Cette capacité, NoSQL la doit au fait qu’il s’exécute sur des clusters de serveurs, bénéficiant ainsi d’une répartition des charges exceptionnelle. L’autre raison du succès des bases NoSQL est qu’elles sont développées sur le modèle open source, ce qui permet de contrôler l’investissement financier.
Pourquoi les bases NoSQL affichent-elles des performances supérieures à PostgreSQL  ?

Sur le plan opérationnel, il existe en effet des cas de figures où les bases NoSQL s'avèrent plus adaptées que les bases traditionnelles. Certaines limitations inhérentes, héritées de la théorie relationnelle, font qu'il est très difficile de concurrencer les bases documentaires sans schéma sur le plan des performances. L'insertion d'un couple clef-valeur (par exemple un numéro identifiant une nom, une date et une adresse) est beaucoup plus rapide dans MongoDB que dans PostgreSQL.
Ceci s'explique par le fait que PostgreSQL doit découper cette information en colonnes et vérifier les éventuelles contraintes d'intégrités et mettre à jour les index de la table. Pour MongoDB au contraire, l'opération d'insertion se résume à écrire un document BSON unique contenant toutes les informations. Lorsqu'une application a pour objectif principal de supporter un volume d'insertions élevé et constant, il est difficile de tenir la comparaison…

Du traitement des données à leur exploitation
Pour autant, beaucoup d'utilisateurs de base NoSQL n'ont pas ce type de besoins extrêmes. 
Ils utilisent ces bases comme un simple moyen de stockage d'informations et se débarrassent par la même occasion du langage SQL. Pourtant, la plupart des applications stockent leurs informations dans des tables et c'est là que PostgreSQL s'avère supérieur aux bases NoSQL. 
Prenons le cas d'un logiciel CRM qui doit afficher les dix meilleurs points de vente de Paris du mois précédent pour une chaine de magasins. Avec une base NoSQL comme MongoDB, il faudra tout d'abord faire la liste des points de vente de Paris puis utiliser cette liste pour calculer le chiffre d'affaires de chaque point. Avec PostgreSQL, une simple jointure entre les tables « ventes » et « points de vente » suffit pour obtenir ce résultat. PostgreSQL est alors capable d'optimiser cette requête en fonction des statistiques qu'il a accumulées. Par exemple, s'il y a 100 points de ventes et plusieurs milliers de ventes au total, le tri sur les magasins devra être fait en priorité. Avec MongoDB, c'est au développeur de faire ce choix une fois pour toute, ce qui augmente le risque d'erreur.
Par ailleurs, les systèmes relationnels,  avec leurs propriétés  strictement définies,  garantissent l’intégrité des données de bout en bout lors d’une transaction comportant de multiples étapes.

L’avenir est au rapprochement du SQL et du NoSQL
Il est clair que les SGBD relationnels ne sont plus l'alpha et l'omega du stockage de données.
Michael Stonebraker, créateur, entre autres d’Ingres, Vertica ou PostgreSQL, vient par exemple de poser les bases de nouvelles technologies de bases de données relationnelles (VoltDB) pouvant rivaliser avec les bases NoSQL en termes de performances sans sacrifier la qualité des données. 
Mais des bases comme PostgreSQL n'ont pas dit leur dernier mot ! Avec l'arrivée de la version 9.1 et les tables non journalisées (« unlogged tables »), PostgreSQL propose une méthode simple et très efficace de supporter les vagues d'écritures massives. En réduisant le niveau de sécurité de certaines tables, on peut ainsi diviser par 10 les temps d'écriture. Un compromis qui s'avère judicieux pour les tables temporaires et les données volatiles comme par exemple les sessions d'une application web
Les innovations de PostgreSQL 9.1 ne s'arrêtent pas là : le support du standard SQL/MED est une première étape qui va permettre à PostgreSQL de se connecter à des sources de données externes : un annuaire LDAP, une base Oracle ou… une base NoSQL ! Des connecteurs sont d'ores et déjà disponibles pour couchdb et redis. Les données NoSQL apparaissent alors comme une table virtuelle classique et peuvent être interrogées avec des requêtes SQL classiques.
En résumé, PostgreSQL ne tourne pas le dos au mouvement NoSQL, bien au contraire : les idées innovantes du mouvement NoSQL sont intégrées dans le moteur relationnel de Postgres (commit asynchrone, tables non journalisées, etc.). Mieux encore, PostgreSQL avec SQL/MED jette des ponts vers les différentes bases NoSQL et est en passe de devenir l'infocentre qui pourra relier et unir les bases traditionnelles et NoSQL.

En ligne de mire : le Big Data
On peut s’attendre à ce que concilier les avantages du NoSQL et ceux du SQL devienne bientôt indispensable.
Le volume des données accumulées explose : il devrait en effet être multiplié par 40 d'ici 2020. 80 % de ces informations seront non structurées, donc difficiles à analyser. 
En 2011,  les entreprises les plus chanceuses sont capables d'analyser 7  % de leurs données tout au plus.*
Le décisionnel (Business Intelligence), jusque là réservé aux plus gros budgets, est amené à se populariser pour atteindre des entreprises d’envergure plus modeste.
Les sociétés vont enfin pouvoir extraire l’essence de leurs données pour en retirer, en temps réel, les enseignements qui s’imposent et améliorer leur profitabilité.
Aujourd’hui, on accumule les données. Demain il faudra les traiter, les analyser, qu’elles soient ou non structurées.
C’est à ce moment que le rapprochement des technologies relationnelles et des technologies de type NoSQL fera la différence.


*Source : Jeff Jonas, directeur scientifique du département Entity & Analytics chez IBM lors d'une déclaration sur le salon Information on Demand (IOD) qui se tenait fin octobre 2011 à Las Vegas.