Les bases de données orientées document (également appelées: ou) localisent chaque enregistrement, et ses informations associatives, dans des documents uniques. Ce type de base de données est un sous-ensemble du parapluie NoSQL, qui fait référence à la liste croissante des systèmes de gestion de base de données populaires qui utilisent des modèles « non relationnels », c’est-à-dire des bases de données qui ne dépendent pas du langage de questions structurées.
NoSQL a été développé pour remplir les espaces trouvés dans les bases de données SQL, qui sont souvent appelés SGBDR, c’est-à-dire les systèmes de gestion de bases de données relationnelles, car la majorité utilise SQL. Les relations aujourd’hui ont toujours l’avantage sur les non-relationnels, car – alors que le terme « NoSQL » n’a été créé qu’au XXIe siècle, même si l’on considère que la fin des années 1960 – NoSQL n’a prospéré en popularité que dans le les trois dernières années en raison des développements rapides du cloud Big Data, de la forte attractivité du Web et de la demande UGC.
Cela dit, les grandes informations non relationnelles comme MongoDB et Redis sont maintenant dans une ligue comparable à d’anciens géants relationnels reconnus comme Oracle et MySQL, et les tendances.
Pourquoi les bases de données orientées document sont-elles pertinentes pour des informations volumineuses?
Il est lié à l’augmentation générale de la demande de bases de données NoSQL modernes ces dernières années. NoSQL fournit une méthode pour organiser d’énormes volumes d’informations désorganisées, ce qui en fait un partenaire plus évolutif et plus agile pour les développeurs, dans de nombreux cas, que SQL. Cependant, de nombreuses exceptions existent et doivent être notées: les hybrides comme PostgreSQL – et les bases de données graphiques NoSQL (GDB) – ont en fait des capacités variables pour traiter à la fois des données structurées et désorganisées sans perte de stabilité: cela signifie une évolutivité élevée, polyvalence élevée, interrogation extrêmement fiable.
Je pense que cette fusion de 2 mondes continuera. En tout cas, ayez un large éventail d’utilisations aujourd’hui:
- Applications Web – plates-formes de blogs, informations Web détaillées, applications de commerce électronique, choix des utilisateurs, systèmes de gestion de contenu.
- Jeux – réalisations (par exemple, obstacles terminés, statistiques en direct), discussion / messagerie dans le jeu, suivi de la cote de leadership, abonnements.
- Contenu produit par l’utilisateur – journaux de discussion, évaluations des utilisateurs, commentaires des utilisateurs, tweets, sites de blog.
- Stockage / journalisation général – comptes d’utilisateurs, catalogage d’éléments, conservation des journaux, réel- informations sur le temps.
Entre autres utilisations. MongoDB, CouchDB, OrientDB et DocumentDB sont des exemples de systèmes de stockage de documents très utilisés. Voir ici pour une liste complète des bases de données NoSQL modernes.
Faisons une expérience d’idée: vous utilisez une base de données relationnelle pour stocker des informations qui, comme prévu, sont contenues dans de nombreuses tables. L’objectif est de cartographier différents auteurs de livres. Un tableau mappe le nom de l’auteur, la date de sortie et le genre – avec un identifiant d’auteur associatif. Quelques-uns de ces auteurs ont des séries; vous avez donc un tableau différent pour les noms et les identifiants d’album. Un tableau pour les différentes catégories et identifiants de genre.
Vous reliez schématiquement ces 3 tables, produisant des champs essentiels primaires et étrangers; reliant ces tables ensemble dans une conception structurée à des fins d’interrogation. C’est votre structure standard terminée.
En revanche, les bases de données de fichiers ne dépendent pas d’un schéma de table. Chaque entité est positionnée dans un seul fichier, et les données associatives peuvent être trouvées dans ce seul fichier. En vérité, vous pouvez commencer à charger des informations sans avoir de schéma déjà en place: votre base de données n’a pas besoin d’être organisée et structurée – vous n’avez pas nécessairement besoin de colonnes, de tables, de secrets primaires / étrangers, de relations, de traitements conservés , bientôt.
D’une part, cela permet une plus grande variation dans les informations, la combinaison et la modélisation; de l’autre, il y a moins de capacité à mettre en œuvre des relations aiguës entre les entités. Pour cette raison, SQL reste la force significative dans les transactions OLTP telles que les guichets automatiques, où des systèmes rigides et extrêmement sûrs sont nécessaires pour garantir le raisonnement et la crédibilité du service au niveau de la base de données.
Dans l’ensemble, les magasins de documents dépendent des magasins de valeurs-clés, qui ne sont pas également compétents dans la production de ces directives d’application. SQL offre de meilleures performances lorsqu’il cible des zones hautement localisées de votre base de données et fonctionne bien pour des données uniformes; c’est-à-dire pour des choses comme la comptabilité individuelle. Pour obtenir des méta-informations et des connexions rapides sur de vastes étendues de grands magasins d’informations en constante évolution et plutôt imprévisibles – en utilisant ce programme de base de valeurs-clés pour récupérer rapidement des informations non structurées – les bases de données orientées document sont naturellement efficaces.
Jetons un coup d’œil à quelques derniers avantages et compromis cruciaux de ce modèle «sans schéma / gratuit».
Comme c’est généralement le cas pour les bases de données NoSQL, les magasins de documents fonctionnent horizontalement la mise à l’échelle très bien, contrairement aux bases de données SQL – la conservation des données partagées sur des milliers d’appareils – fonctionne bien dans ce modèle. En comparaison, les bases de données relationnelles évoluent mieux verticalement (par exemple, y compris le stockage, la mémoire, etc.). Pour cette raison, NoSQL est considéré comme l’équivalent le plus naturel de l’avancement agile et de l’hybride / multi-cloud.
Enfin, du fait que les magasins de documents n’utilisent pas de clés étrangères – que les bases de données relationnelles utilisent dans afin de relier les tables les unes aux autres – des relations doivent être établies au niveau de la couche application pour les bases de données de fichiers. Les relations doivent être moins importantes pour les personnes qui ont effectivement choisi d’utiliser les magasins de documents.
Quel que soit le secteur en question, il devient de plus en plus difficile de nier que le monde s’oriente vers un développement dans le multi-cloud – et avec cela vient la diffusion d’énormes données horizontalement, faisant des bases de données orientées document, et la formation de la main-d’oeuvre commerciale à l’intelligence de style de données, une exigence croissante.
Dans l’ensemble, les magasins de données ont moins de difficulté à gérer les et-out des données de mise en cache et d’indexation; à suivre et à travailler main dans la main avec la création de nouvelles applications Web; et en mise à l’échelle horizontale. Davantage de documentation est néanmoins nécessaire pour éliminer cela des petites communautés de niche et des forums spécifiques. Et plus de conseils, sur les différents magasins de fichiers facilement disponibles, doivent être diffusés. Pour ceux qui sont capables de garder un intérêt, de garder une trace de la course, c’est un outil réflexif pour inclure facilement des ensembles de données ou évoluer rapidement avec moins de tracas.
Alex Williams, rédacteur / chercheur chez Hosting Data UK, est un développeur full-stack qualifié et un expert sur tout ce qui concerne NoSQL.
.
