Gérer MongoDB vous-même implique de prendre en charge l'intégralité de la pile opérationnelle : achat du matériel, configuration des jeux de réplicas, mise en place du RAID, application des correctifs de sécurité, planification de la capacité et réponse aux incidents 24h/24 et 7j/7. ApsaraDB for MongoDB gère cette infrastructure pour permettre à votre équipe de se concentrer sur le développement des applications. Le tableau ci-dessous compare ces deux approches selon huit dimensions.
| Dimension | ApsaraDB for MongoDB | Base de données autogérée |
|---|---|---|
| Disponibilité du service | Haute disponibilité intégrée avec basculement automatique. Prend en charge la reprise après sinistre (DR) sur une ou trois zones au sein d'une même région. Des instances de reprise après sinistre géographique sont disponibles pour une protection inter-régions. | Vous devez mettre en place et maintenir la réplication primaire/secondaire ainsi que le RAID. La reprise après sinistre au niveau de la zone nécessite un déploiement manuel ; les configurations bi-zones sont difficiles à implémenter et la disponibilité au niveau de la base de données n'est pas garantie. La reprise après sinistre inter-régions requiert un outil tiers. |
| Fiabilité des données | Fiabilité élevée. L'objectif de point de récupération (RPO) des instances de jeu de réplicas mono-zone et tri-zone est de 0. | Vous devez configurer la réplication primaire/secondaire et le RAID, et assurer la durabilité des données. |
| Sécurité du système | Protection préventive : protection DDoS, correction automatique des vulnérabilités de sécurité de la base de données, contrôle d'accès basé sur une liste d'autorisation et isolation VPC. Protection en cours d'exécution : chiffrement SSL et chiffrement transparent des données (TDE). La fonctionnalité SQL Audit est fournie. Pour plus de détails, consultez Afficher les journaux d'audit. | Protection préventive : nécessite du matériel ou des logiciels de sécurité supplémentaires, ce qui engendre des coûts élevés. Protection en cours d'exécution : vous devez mettre en place les systèmes de chiffrement SSL et TDE. Audit : nécessite l'achat d'un système d'audit distinct. |
| Sauvegarde et restauration | Un noyau complet prend en charge à la fois la sauvegarde physique et la sauvegarde logique lors de la sauvegarde manuelle, avec une efficacité trois fois supérieure à celle de l'open source. La restauration d'une seule base de données est prise en charge. | La version open source ne prend en charge que la sauvegarde logique et est plus lente. La restauration d'une seule base de données n'est pas disponible. Dans les architectures distribuées, vous devez vérifier manuellement l'exactitude de la récupération des données. |
| Hébergement du système | Aucun frais d'hébergement. | Des frais d'hébergement de serveur s'appliquent. Plus votre architecture est complexe, plus vous hébergez de serveurs et plus les coûts sont élevés. |
| Coût des opérations et de la maintenance (O&M) | Aucun personnel dédié aux opérations n'est requis. CloudDBA propose un diagnostic intelligent : tendances de performance, performance en temps réel, sessions d'instance, journaux de requêtes lentes et analyse du stockage. | Nécessite des administrateurs de base de données dédiés et entraîne des coûts d'O&M récurrents élevés. Aucun diagnostic de performance intégré ; le dépannage des requêtes lentes est complexe et chronophage. |
| Déploiement et mise à l'échelle | Les instances s'activent instantanément. La mise à l'échelle automatique est prise en charge. | Nécessite l'achat de matériel, l'hébergement en centre de données et le déploiement des machines. L'ajout de nœuds requiert la maintenance manuelle des relations entre les nœuds. |
| Optimisation du noyau |
| La version open source ne dispose d'aucune optimisation au niveau du noyau et ne peut pas être utilisée dans certains scénarios. |