Avez-vous déjà essayé de manger des tagliatelles à la cuillère ? Pas facile ! Faute d’être fermement maintenues en place, elles glissent et retombent dans l’assiette. Une fourchette s’avère cent fois plus adaptée, car elle vous permet de piquer et d’enrouler vos pâtes en un tour de main.

Mais quand vous arrivez au fond de l’assiette et que vous voulez attraper les dernières gouttes de sauce… là, votre fourchette ne sert plus à rien. Vous devez reprendre votre cuillère : deux outils sont donc requis pour une opération qui devrait être simple.

Mais un petit futé a inventé la cuichette. Depuis, il existe donc quelque chose qui combine les fonctions d’une cuillère et celles d’une fourchette. Alors, pourquoi n’utilisons-nous pas des cuichettes à chaque repas ? Pourquoi les fourchettes et les cuillères existent-elles encore ?

Quand on y réfléchit, c’est précisément le genre de débat qui fait rage entre les scientifiques des données, opposant les partisans de PostgreSQL aux adeptes de MongoDB pour ce qui est du stockage des données JSON.

Auparavant, la comparaison entre Postgres et MongoDB ressemblait à ceci : d’un côté, vous aviez Postgres, compatible avec les données SQL (puis NoSQL), mais pas avec les données JSON. De l’autre côté, vous aviez des systèmes de gestion de base de données (SGBD) dédiés comme MongoDB, qui était conçu comme une base de données JSON native.

Mais aujourd’hui, cette distinction stricte est brouillée par l’arrivée d’options intermédiaires, les « cuichettes des données » si vous préférez.

PostgreSQL, avec son architecture basée sur SQL, affiche désormais des capacités de stockage JSON améliorées. Alors, pourquoi conserver ces deux outils ?

Préparez correctement vos données grâce à notre guide exclusif « Six étapes clés pour préparer des données à des fins d’analyse »

Irrésistible ascension de JSON et JSONB

Avant d’aller plus loin, rappelons de quoi nous parlons. Qu’est-ce que c’est que ce format de données JSON qui paraît si difficile à stocker ?

JavaScript Object Notation (JSON) est un format non structuré, flexible et lisible par les humains. En gros, il permet de déverser des données dans votre base de données comme elles viennent, sans avoir à les adapter à un langage spécialisé (comme SQL). Il permet aussi d’imbriquer des champs dans un enregistrement de données ou d’ajouter différents champs aux enregistrements de données individuels comme et quand vous le souhaitez.

Tout cela fait de JSON un jalon majeur sur le chemin de l’informatique conviviale. Aujourd’hui, beaucoup le préfèrent à XML, et le format de données JSON se retrouve dans un certain nombre de magasins de données NoSQL.

Toutefois, JSON ne permet pas l’indexation. Le format de données JSONB a justement été créé pour pallier ce problème. JSONB stocke les données au format binaire, plutôt que dans un simple blob JSON. Certes, la saisie des données s’en trouve légèrement ralentie, mais leur traitement est accéléré puisqu’il est inutile de procéder à une nouvelle analyse.

Qu’est-ce que MongoDB ? Qu’est-ce que PostgreSQL ?

Bon, maintenant que nous avons éclairci le sujet, regardons les différences entre ces deux bases de données couramment utilisées.

MongoDB est une base de données open source. Conçue pour être agile et évolutive, elle utilise des schémas dynamiques pour permettre de créer des enregistrements sans définir la structure en premier lieu. Elle prend également en charge la documentation hiérarchique des données.

PostgreSQL est également open source. En revanche, il s’agit d’une base de données relationnelle qui est davantage étudiée pour garantir la conformité aux normes et l’extensibilité que pour vous laisser libre de stocker vos données comme vous l’entendez. Combinant les schémas dynamiques et statiques, elle vous permet de stocker vos données relationnelles ainsi que vos formulaires normalisés. MongoDB, avec son approche non structurée, ne le permet pas.

Alors, quel outil choisir pour stocker vos données JSON/JSONB ?

Contraintes délibérées et limites collatérales

Tout d’abord, soyons clairs, Postgres et MongoDB ont tous deux des fonctions de stockage des données JSON et JSONB (même si MongoDB appelle ce dernier format « BSON »).

Ils présentent toutefois des différences :

  • MongoDB limite son format BSON à 64 bits pour représenter un entier ou un nombre à virgule flottante. Le format JSONB de Postgres n’est pas limité.
  • Postgres intègre des fonctions de contrainte et de validation des données, qui contribuent à rendre les documents JSON plus explicites. Par exemple, il vous empêche de stocker des caractères alphabétiques lorsque seules des valeurs numériques sont logiques.
  • MongoDB intègre le partitionnement automatique de base de données, qui simplifie l’évolution horizontale du stockage des données JSON. Du côté de Postgres, l’évolutivité est généralement verticale. Vous pouvez faire évoluer l’installation horizontalement, mais cela peut s’avérer plus difficile ou nécessiter l’intervention d’un tiers.
  • MongoDB vous permet également d’augmenter votre débit d’écriture en différant l’écriture sur disque. Vous risquez de perdre quelques données de cette façon, mais cela peut être une bonne solution pour les utilisateurs peu soucieux de la persistance de leurs données.

L’essentiel, bien sûr, c’est que Postgres vous laisse le choix. Vous pouvez acheminer les données vers une colonne JSON, ce qui vous permet de les modéliser ultérieurement, ou bien les intégrer à une table de schémas SQL, le tout dans la même base de données Postgres.

Alors, prenons l’option « cuichette » ! Enfin, pas si vite…

Les magasins de données JSON natifs n’affichent pas toujours les meilleures performances

Les systèmes de gestion de base de données NoSQL se distinguent notamment par leurs performances.

Puisqu’ils fonctionnent avec des structures de données plus simples que les bases de données SQL, le stockage et la récupération ont tendance à s’avérer plus rapides dans les systèmes de bases de données NoSQL.

Même s’ils ne possèdent pas les propriétés ACID (atomicité, cohérence, isolation et durabilité) dont vous avez besoin, entre autres, pour vos transactions financières, ils conviennent parfaitement à la gestion rapide de grands volumes de données non structurées.

Cela dit, en 2014, Postgres a surpris tout le monde en battant MongoDB sur le plan des performances sur EnterpriseDB.com.

Oui, vous avez bien lu. Étonnamment, dans les tests fondés sur la sélection, le chargement et l’insertion de données de documents complexes de l’ordre de 50 millions d’enregistrements, Postgres s’est révélé environ deux fois plus rapide pour l’ingestion des données, deux fois et demi plus rapide pour la sélection des données et trois fois plus rapide pour les insertions de données, tout en consommant 25 % d’espace disque en moins.

Soyons justes, MongoDB 3.0 a depuis relevé le défi, en présentant un moteur de base de données WiredTiger qui augmente de sept à dix fois la vitesse d’écriture, tout en économisant l’espace disque en compressant les données de 50 %.

Bref, même si MongoDB n’a pas perdu son avance, l’argument des performances ne porte plus autant qu’avant.

Voyez Sisense en action :

Quality Assurance Project Status - Software Dashboard

Cas d’utilisation et facteurs affectant le choix entre Postgres et MongoDB

« Et maintenant ? », me direz-vous. Devez-vous choisir Postgres ou MongoDB comme base de données JSON ?

La réponse dépend de ce que vous souhaitez réaliser et de ce dont vous disposez actuellement. Pour vous aider à prendre la bonne décision, posez-vous les sept questions suivantes.

  1. Quelle application utilisez-vous ?

    MongoDB limite le nombre de commandes de gestion de base de données nécessaires pour développer une application. Cela peut s’avérer très utile pour accélérer le prototypage ainsi que les requêtes et les commandes à la demande créées par l’application.

    Cela dit, l’application elle-même doit insérer des données significatives et la maintenance du logiciel pourrait nécessiter beaucoup d’efforts.

  2. De quel degré de structure aurez-vous besoin ultérieurement ?

    MongoDB est idéal pour les données non structurées. En revanche, si vous envisagez de mélanger à terme les données structurées et non structurées ou si vous pensez que la conformité ACID peut prendre de l’importance à l’avenir, Postgres s’avère plus adapté.

  3. Utilisez-vous des données JSON statiques ?

    Si vous utilisez des données JSON statiques et des données actives structurées pour le stockage SQL, Postgres est un bon choix : sa représentation JSONB est efficace et permet l’indexation. Néanmoins, vous pouvez aussi exécuter des requêtes SQL sur des rapports MongoDB via ODBC et l’intégration de l’informatique décisionnelle.

  4. Dans quelle mesure devrez-vous modifier vos données JSON ?

    MongoDB intégrant les outils nécessaires pour mettre à jour les champs individuels, il vous conviendra mieux si vous souhaitez modifier vos données JSON au sein du magasin de données.

    En revanche, pour modifier les champs JSON dans Postgres, vous devrez extraire l’intégralité du document, puis le réimporter une fois les modifications apportées.

  5. Avez-vous besoin d’effectuer des requêtes dynamiques ?

    MongoDB est parfait pour les requêtes dynamiques de données qui sont fréquemment écrites ou lues. Il est en effet compatible avec des données de toutes sortes qui changent en permanence, sans nécessiter de transactions complexes entre les objets. Vous bénéficierez ainsi de bonnes performances, même lorsque vous exécuterez des requêtes ad hoc sur de petits sous-ensembles de champs dans des documents comptant de nombreux champs.

  6. Avez-vous besoin du partitionnement automatique ?

    La fonctionnalité de partitionnement automatique de MongoDB convient aux environnements informatiques qui utilisent plusieurs instances de matériel standard (architectures convergentes).

  7. Pouvez-vous recruter le personnel adéquat ?

    Le coût du choix entre Postgres et MongoDB dépend fortement de votre capacité à trouver facilement des développeurs ayant les compétences requises (ainsi que de la disponibilité et du prix des plateformes d’hébergement, etc.) !

    Postgres existe depuis plus longtemps et est inclus gratuitement dans de nombreux systèmes d’exploitation Linux. Il est donc bien implanté. Pour autant, vous n’aurez pas forcément de mal à trouver des experts en MongoDB : c’est maintenant la cinquième technologie de base de données la plus répandue, après tout.

    Pensez simplement aux compétences dont vous disposez en interne et aux talents que vous devrez recruter en fonction de votre choix.

Conclusion

Oui, je sais. Vous espériez que nous vous facilitions la vie en vous disant quel choix faire, n’est-ce pas ? Malheureusement, comme vous l’aurez compris, ce n’est pas si simple.

Pour prendre votre décision, réfléchissez aussi bien à ce que vous attendez de votre système de base de données qu’à ce dont vous aurez probablement besoin dans quelques années. Pas seulement sur le plan du stockage, mais aussi en matière d’exploitation de vos données.

Certes, si vous utilisez déjà MongoDB ou Postgres, changer de voie pourra sembler très pénible. Cependant, croyez bien que vous devrez viser juste, et au plus vite. Plus vos données se multiplient et se complexifient, plus la rectification de la trajectoire est difficile !

6 crucial steps of preparing data for analysis