Dans les années 1970, Oracle Corporation est devenue la première entreprise à commercialiser la base de données relationnelle. À une époque où les ingénieurs logiciels écrivaient du code sur du papier, Oracle a créé un logiciel qui a permis de gagner énormément en efficacité. Le SGBDR est devenu un standard et Oracle est devenu l’un des éditeurs de logiciels les plus établis et les mieux implantés de l’entreprise. Des alternatives telles que MongoDB sont arrivées dans les années 2000 pour répondre aux nouvelles façons de stocker et de gérer les données.
Aujourd'hui, les entreprises modernes réfléchissent à de meilleures solutions pour stocker et gérer leurs données, qu'il s'agisse d'améliorer la connaissance de leurs clients, de s'adapter aux attentes changeantes de leurs utilisateurs ou de battre leurs concurrents sur le marché en proposant des applications et modèles économiques nouveaux. Par conséquent, bon nombre des hypothèses qui ont motivé l'élaboration des premières bases de données relationnelles ont changé :
- Exigences d'une productivité accrue des développeurs et d'une mise sur le marché plus rapide, avec les traditionnels modèles de données relationnels rigides et le développement en cascade d'applications monolithiques laissant la place aux méthodologies agiles, aux microservices et aux technologies DevOps, qui ramènent à quelques jours et semaines des cycles de publication qui s'étendaient sur plusieurs mois et années.
- Nécessité de gérer l'augmentation massive de nouveaux types de données en évolution rapide - données structurées, semi-structurées et polymorphes générées par de nouvelles classes d'applications Web, mobiles, sociales et d'IoT.
- Le passage en gros aux systèmes distribués et au cloud computing, permettant aux développeurs d'exploiter une infrastructure de calcul et de stockage hautement évolutive et à la demande, avec la possibilité de servir les publics partout où ils travaillent et jouent à travers le monde, tout en satisfaisant à une nouvelle série d'exigences réglementaires en matière de souveraineté des données.
En conséquence, les bases de données NoSQL (non relationnelles), telles que MongoDB, ont émergé afin de répondre aux besoins des nouvelles applications et de moderniser les charges de travail existantes. Grâce à la prise en charge des transactions ACID multi-documents, MongoDB permet plus facilement que jamais de traiter les cas d'usage qui rencontrent actuellement — ou rencontreront à l'avenir — des difficultés avec Oracle.
Cette page compare Oracle et MongoDB, en soulignant les principales différences et les cas d'usage appropriés pour chaque solution. Vous pouvez en apprendre davantage sur les avantages de la modernisation des systèmes existants et des processus de développement en visitant notre page Legacy Modernization.
Qu'est-ce qu'Oracle ?
Oracle est une société technologique mondiale spécialisée dans les systèmes de gestion de bases de données. Son offre de base de données principale est Oracle Database 23ai. Celle-ci est vendue via un modèle de licence par traitement, où le prix augmente en fonction des modules complémentaires requis pour des fonctionnalités spécifiques. Dans Oracle, vous prédéfinissez votre schéma de base de données en fonction de vos besoins. Vous définissez ensuite des règles pour régir les relations entre les champs de vos tables. Des informations connexes peuvent être stockées dans des tables distinctes. Ces informations sont ensuite associées grâce à l'utilisation de clés étrangères et de jointures. Toute modification du schéma nécessite une procédure de migration, ce qui peut mettre la base de données hors ligne ou réduire considérablement les performances de l'application.
Qu'est-ce que MongoDB ?
MongoDB est une base de données non relationnelle développée par MongoDB, Inc. MongoDB stocke les données structurées, semi-structurées et non structurées sous forme de documents dans une représentation binaire appelée BSON (Binary JSON). Les informations connexes sont stockées ensemble pour un accès rapide aux requêtes via le langage de requête MongoDB (MQL). Les champs peuvent varier d’un document à l’autre ; il n’est pas nécessaire de déclarer la structure des documents au système : les documents sont auto-descriptifs. Si un nouveau champ doit être ajouté à un document, il peut être créé sans affecter tous les autres documents de la collection, sans mettre à jour un catalogue de système central et sans mettre le système hors ligne. Au besoin, la validation de schéma peut être utilisée pour appliquer des contrôles de gouvernance des données sur chaque collection.
Le modèle de données documentaire de MongoDB se mappe naturellement aux objets du code de l’application. Cela simplifie l’apprentissage et l’utilisation pour les développeurs. Les documents vous permettent de représenter facilement des relations hiérarchiques afin de stocker des gammes et d’autres structures plus complexes.
Des pilotes idiomatiques natifs sont fournis pour plus de 12 langues— et la communauté MongoDB en a développé des dizaines d'autres — permettant des requêtes ad-hoc, une agrégation en temps réel et une indexation riche pour offrir de puissants moyens de programmation permettant d'accéder aux données de toute structure et de les analyser.
Les documents peuvent réunir des données connexes qui, autrement, seraient modélisées dans un schéma relationnel à travers des tables séparées parent-enfant. En conséquence, les opérations à document atomique unique de MongoDB fournissent déjà une sémantique de transaction répondant aux besoins d'intégrité des données de la majorité des applications. Un ou plusieurs champs peuvent être écrits en une seule opération. Cela inclut les mises à jour de plusieurs sous-documents et éléments d'une gamme. Les garanties fournies par MongoDB assurent une isolation complète lors de la mise à jour d'un document ; toute erreur entraîne un retour en arrière afin que les clients reçoivent une vue cohérente du document.
Contrairement à Oracle et à d'autres bases de données relationnelles, MongoDB repose sur une architecture de systèmes distribués plutôt que sur une conception monolithique à nœud unique. En conséquence, MongoDB offre une mise à l'échelle prête à l'emploi et une localisation des données via le sharding par zone et les replica sets pour maintenir une disponibilité permanente.
Transactions ACID multi-documents
Les transactions multi-documents font de MongoDB la seule base de données à combiner les garanties ACID des bases de données relationnelles traditionnelles avec la vitesse, la flexibilité et la puissance du document model, ainsi qu’une conception de systèmes distribués intelligents pour répartir et placer les données là où vous en avez besoin. Grâce à l’isolation par snapshot, les transactions offrent une vue cohérente des données et appliquent une exécution « tout ou rien » pour maintenir l’intégrité des données. Les transactions dans MongoDB fonctionnent exactement comme les transactions que les développeurs connaissent dans Oracle. Elles sont multi-déclarations, avec une syntaxe similaire (p. ex. start_transaction et commit_transaction), et sont donc faciles à ajouter à toute application par quiconque ayant une expérience préalable des transactions.
Pourquoi utiliser MongoDB au lieu d'Oracle ?
Les organisations de toutes tailles adoptent MongoDB car cela leur permet de créer des applications plus rapidement, de gérer des types de données très divers et de gérer les applications plus efficacement à grande échelle.
Le développement est simplifié car les documents MongoDB correspondent naturellement aux langages de programmation modernes orientés objet. L'utilisation de MongoDB supprime la complexe couche ORM (Object-Relational Mapping) qui traduit les objets du code en cellules dans les tables relationnelles.
Lors de l'évaluation des bases de données, il est essentiel de prendre en compte les coûts relatifs de chaque solution, pas seulement le coût du logiciel, mais également les coûts liés au matériel, au développement et au déploiement. Les organisations peuvent économiser des millions d'euros en passant d'Oracle à MongoDB, en bénéficiant d'une réplication des données améliorée, de gains de productivité pour les développeurs, d'une réduction des licences et de besoins moindres en matériel.
MongoDB peut également être déployé à l’intérieur et à travers plusieurs centres de données distribués. Cela offre de nouveaux niveaux de disponibilité et d’évolutivité jusque-là impossibles avec des bases de données relationnelles comme Oracle. Au fur et à mesure que vos déploiements augmentent en volume et en débit de données, MongoDB évolue facilement, sans interruption de service ni altération de votre application. En revanche, pour évoluer avec Oracle, un important travail d’ingénierie sur mesure ou un investissement en matériel coûteux et personnalisé est souvent nécessaire.
Si MongoDB est la solution adaptée à vos besoins et que vous utilisez actuellement Oracle, consultez notre guide de migration et l’outil Relational Migrator de MongoDB — un outil qui simplifie la migration et la transformation des données depuis une relational database vers MongoDB, en réduisant les risques de votre transition vers MongoDB tout en vous aidant à tirer pleinement parti du document model.
Les utilisateurs préfèrent MongoDB à Oracle
Comme l’illustrent les exemples suivants, la préférence pour MongoDB par rapport à Oracle repose sur des améliorations radicales de la productivité des développeurs, des performances des applications et de l’évolutivité, couplées à une réduction substantielle des coûts et du verrouillage.
Pour répondre aux exigences de l'entreprise, Travelers Insurance a modernisé ses processus de développement au moyen d'une architecture de microservices reposant sur les méthodologies Agile et DevOps. Mais la rigidité de ses bases de données Oracle et SQL Server existantes empêchait l'entreprise d'évoluer à la vitesse souhaitée. La solution fut MongoDB et son modèle de données flexible, particulièrement bien adapté aux applications d'entreprise. L'entreprise a éliminé le délai de trois jours requis pour toute modification de la base de données, créant ainsi un pipeline de développement logiciel prenant en charge la fourniture continue de nouvelles fonctionnalités commerciales.
Le géant des finances RBS a modernisé ses systèmes de banque d'investissement grâce à une nouvelle architecture de données basée sur MongoDB. À la suite de la mise hors service de centaines de serveurs Oracle, il a accéléré la productivité des développeurs pour concevoir de nouvelles applications plus rapidement, créé une infrastructure simplifiée et compatible avec le cloud pour la mise à l'échelle des données, et évité des millions de dollars de coûts.
Telefonica a migré son service de personnalisation client d’Oracle vers MongoDB. Avec Oracle, il a fallu sept développeurs, plusieurs itérations et 14 mois pour créer un système qui ne fonctionnait tout simplement pas. En utilisant MongoDB, une équipe de trois développeurs a mis en place son nouveau service de personnalisation en trois mois, qui alimente désormais les produits existants et les nouveaux produits à travers le monde. MongoDB aide Telefonica à être plus agile, à faire des économies et à générer de nouvelles sources de revenus.
La migration de China Eastern d'Oracle vers MongoDB a permis aux équipes de projet et d'ingénierie de la société de créer une application impossible à réaliser avec Oracle, transformant ainsi l'expérience client et générant davantage de chiffre d'affaires en ligne. La simplicité du modèle de données documentaire, du schéma dynamique, des pilotes idiomatiques et la flexibilité d'indexation permettent aux équipes de développement de lancer de nouvelles applications plus rapidement, tout en réalisant des économies substantielles.
Dans quels cas Oracle serait-il la meilleure option ?
Bien que de nombreuses organisations aient migré avec succès d'un SGBDR vers MongoDB, il est difficile de paramétrer MongoDB comme remplacement des applications héritées qui ont été développées sur le modèle de données relationnel et le langage SQL. Néanmoins, les organisations tirent parti de la modernisation d'applications critiques et génératrices de revenus grâce à MongoDB. Par exemple, Cisco a migré d'une ancienne base de données relationnelle vers MongoDB et a amélioré l'expérience client en divisant la latence par 8, tout en éliminant les interruptions de service lors des mises à niveau du système. Les équipes de développement de Cisco peuvent créer et commercialiser plus rapidement de nouvelles applications, tandis que la plateforme de commerce électronique de l'entreprise peut tirer parti de l'agilité commerciale rendue possible par le cloud computing.
Terminologie et Concepts
De nombreux concepts dans Oracle ont des analogues proches dans MongoDB. Le tableau ci-dessous présente les concepts communs à Oracle et MongoDB.
Comparaisons des fonctionnalités
Comme Oracle, MongoDB offre un riche ensemble de caractéristiques et de fonctionnalités qui vont bien au-delà de celles offertes par les simples magasins de données NoSQL. MongoDB possède un langage de requête riche, des index secondaires hautement fonctionnels (y compris la recherche de texte et géospatiale), un puissant framework d'agrégation pour l'analyse de données, la recherche à facettes, le traitement de graphes, etc. Avec MongoDB, vous pouvez également utiliser ces fonctionnalités pour des types de données plus diversifiés qu'une base de données relationnelle, et ce à grande échelle.
Langage de requête
Oracle et MongoDB possèdent tous deux un langage de requête riche. Vous trouverez ci-dessous quelques exemples d'instructions SQL et leur mappage vers MongoDB. Une liste plus complète d'instructions se trouve dans la documentation MongoDB.
Prêt à migrer d'Oracle vers MongoDB ?
Si vous envisagez de migrer vos données d’Oracle vers MongoDB, le Relational Migrator peut vous aider. Il s’agit d’un outil gratuit de MongoDB qui simplifie et rationalise le processus de migration, réduisant considérablement les efforts et les risques liés à votre projet de migration.
Prêt à migrer ? Commencez dès aujourd’hui avec Relational Migrator gratuit !