benchANT compares MongoDB and ScyllaDB architectures, with a focus on what the differences mean for performance and scalability Lors du choix d'une base de données NoSQL, les options peuvent être écrasantes. L'une des options les plus populaires est MongoDB, connue pour sa facilité d'utilisation. Le rapport examine de plus près les deux bases de données en comparant leurs architectures sous un angle technique indépendant. Benchante MongoDB et ScyllaDB promettent une architecture hautement disponible, performante et évolutive.Mais la façon dont ils atteignent ces objectifs est beaucoup plus différente que vous ne le pensez à première vue.Par exemple, un rapport d'expérience montre comment ScyllaDB peut facilement être exploité sur des instances spot AWS EC2 grâce à son architecture distribuée, tandis que l'architecture distribuée de MongoDB rendrait cela une tâche très difficile. Pour mettre en évidence ces différences, nous fournissons une discussion approfondie de l'architecture de stockage interne et des architectures distribuées permettant une haute disponibilité et une évolutivité horizontale. Nous venons également de publier un indice de référence qui quantifie l’impact de ces différences. Note: Résumé de la comparaison entre DynamoDB et MongoDB Benchmark Télécharger le rapport de comparaison Read the DynamoDB vs MongoDB Benchmark Summary Résumé de la comparaison entre DynamoDB et MongoDB Benchmark Download this Comparison Report Télécharger le rapport de comparaison Un point de vue de performance sur l'architecture de stockage de MongoDB vs ScyllaDB Les deux bases de données sont mises en œuvre en C++ et recommandent l’utilisation du système de fichiers XFS. De plus, MongoDB et ScyllaDB s’appuient sur la , Commit Log dans la terminologie ScyllaDB et Oplog dans la terminologie MongoDB. Avec l'écriture-avant-journalisation, toutes les opérations sont écrites dans un tableau de journaux avant que l'opération ne soit exécutée. Le journal d'écriture-avant-journalisation sert de source pour répliquer les données à d'autres nœuds, et il est utilisé pour restaurer les données en cas d'échec car il est possible de "reprendre" les opérations pour restaurer les données. Le concept d’écriture-avant-logging MongoDB utilise comme moteur de stockage par défaut un indice B+-Tree (Wired Tiger) pour le stockage et la récupération de données. Les indices B+-Tree sont des structures de données d'arbre équilibré qui stockent les données dans un ordre trié, ce qui facilite l'exécution de requêtes basées sur la plage. MongoDB prend en charge plusieurs indices sur une collection, y compris des indices composés, des indices de texte et des indices géospatiaux. L'indexation d'éléments d'array et de champs niché, permettant des requêtes efficaces sur des structures de données complexes, est également possible. ScyllaDB divise les données en morceaux en attribuant un fragment des données totales dans un nœud à une CPU spécifique, ainsi que sa mémoire associée (RAM) et son stockage persistant (comme NVMe SSD). Le moteur de stockage interne de ScyllaDB suit le concept d’écriture-avant-journalisation en appliquant un journal de communiqué persistant sur disque avec des mémoires basées sur la mémoire qui sont enlevées sur le disque au fil du temps. ScyllaDB prend en charge les indices primaire, secondaire et composite, à la fois local par nœud et global par cluster. L’indice primaire se compose d’un anneau de hachage où sont stockées la clé hachée et la partition correspondante. Et Ces différentes architectures de stockage entraînent une utilisation différente du matériel disponible pour gérer la charge de travail. MongoDB ne pinne pas les fils internes aux cœurs de CPU disponibles mais applique une approche non liée aux fils distribués aux cœurs. Pour les architectures de CPU, cela peut entraîner une dégradation des performances, en particulier pour les grands serveurs, car les fils peuvent être attribués de manière dynamique aux noyaux sur différents sockets avec différents nœuds de mémoire. ce qui lui permet de pinner les fils responsables vers des noyaux spécifiques et évite le changement entre différents noyaux et espaces de mémoire. En conséquence, la clé de fragmentation doit être sélectionnée avec soin pour assurer une répartition égale des données sur les fragmentations et prévenir les fragmentations. qui fournit des classes prioritaires intégrées pour les requêtes sensibles à la latence et insensibles, ainsi que la planification I/O coordonnée à travers les fragments sur un nœud pour maximiser les performances du disque. Enfin, les scripts d'installation de ScyllaDB sont livrés avec une étape d'auto-ajustement des performances en appliquant la configuration de base de données optimale basée sur les ressources disponibles. Nombre basé Shard par approche de base Calendrier I/O ScyllaDB permet à l'utilisateur de contrôler si les données doivent résider dans le cache DB ou de le contourner pour les partitions rarement accessibles. ScyllaDB permet au client d'atteindre le nœud et le noyau cpu (shard) qui possède les données. Cela fournit une latence plus faible, des performances cohérentes et un équilibrage parfait de la charge. ScyllaDB fournit également une «priorisation de la charge de travail» qui fournit à l'utilisateur des SLAs différents pour différentes charges de travail pour garantir une latence plus faible pour certaines charges de travail cruciales. L'architecture distribuée de MongoDB - Deux modes d'exploitation pour une haute disponibilité et une évolutivité L'architecture de base de données MongoDB offre deux modes de cluster qui sont décrits dans les sections suivantes: un cluster d'ensemble de répliques vise une haute disponibilité, tandis qu'un cluster fragmenté vise une évolutivité horizontale et une haute disponibilité. Replica Set Cluster : haute disponibilité avec évolutivité limitée L'architecture MongoDB permet une disponibilité élevée par le concept des ensembles de répliques. Les ensembles de répliques MongoDB suivent le concept des nœuds primaire-secondaire, où seuls les nœuds primaires gèrent les opérations WRITE. Les secondaires détiennent une copie des données et peuvent être activés pour gérer uniquement les opérations READ. Un déploiement commun de ensembles de répliques se compose de deux secondaires, mais des secondaires supplémentaires peuvent être ajoutées pour augmenter la disponibilité ou évoluer les charges de travail lourdes. Le MongoDB prend en charge jusqu'à 50 secondaires au sein d'un ensemble de répliques. En ce qui concerne la géo-distribution, MongoDB prend en charge les déploiements géo-distribués pour les ensembles de réplica pour assurer une haute disponibilité en cas de défaillance du centre de données. Dans ce contexte, les instances secondaires peuvent être distribuées sur plusieurs centres de données, comme indiqué dans la figure suivante.En outre, les instances secondaires avec des ressources limitées ou des contraintes réseau peuvent être configurées avec une priorité pour contrôler leur éligibilité comme primaire en cas de défaillance. Cluster Sharded : évolutivité horizontale et haute disponibilité avec complexité opérationnelle MongoDB prend en charge l'échelle horizontale en divisant les données sur plusieurs instances primaires pour faire face aux charges de travail intensives en écriture et aux tailles de données croissantes. Dans un cluster fragmenté, chaque ensemble de répliques composé d'un primaire et de plusieurs secondaires représente un fragment. Depuis MongoDB 4.4, les secondaires peuvent également être utilisés pour gérer les demandes de lecture en utilisant l'option de lecture sécurisée. Pour activer le sharding, des types de nœuds MongoDB supplémentaires sont nécessaires : Une instance de mongos agit comme un routeur de requête, fournissant une interface entre les applications client et le cluster fragmenté. En conséquence, les clients ne communiquent jamais directement avec les shards, mais toujours via le routeur de requête. Router de requête (mongos) Il est recommandé de déployer plusieurs routeur de requête pour assurer l'accessibilité du cluster car les routeur de requête sont l'interface directe pour les pilotes clients. Il n'y a pas de limite au nombre de routeur de requête, mais comme ils communiquent fréquemment avec les serveurs de configuration, il convient de noter que trop de routeur de requête peuvent surcharger les serveurs de configuration. Les serveurs de configuration stockent les métadonnées d'un cluster fragmenté, y compris l'état et l'organisation de toutes les données et composants. Les métadonnées comprennent la liste des morceaux sur chaque morceau et les rangs qui définissent les morceaux. Le sharding de données dans MongoDB se fait au niveau de la collection, et une collection peut être shardée en fonction d'une clé shard. MongoDB utilise une clé shard pour déterminer quels documents appartiennent à laquelle shard. Les choix de clés shard communs incluent le champ _id et un champ avec une cardinalité élevée, tel qu'un timestamp ou un identifiant d'utilisateur. MongoDB prend en charge trois stratégies de sharding: range-based, hash-based et zone-based. Les partitions de fragmentation rangées assurent une répartition uniforme des documents sur les tranches en fonction de la valeur de la clé de fragmentation. Cela maintient les documents avec les valeurs de la clé de fragmentation proches les uns des autres et fonctionne bien pour les requêtes basées sur la plage, par exemple sur les données de la série temporelle. La fragmentation hachée garantit une répartition uniforme des écrits sur les tranches, ce qui favorise les charges de travail d'écriture. La fragmentation zonée permet aux développeurs de définir des règles de fragmentation personnalisées, par exemple pour s'assurer que les données les plus pertinentes se trouvent sur les tranches les plus proches géographiquement des serveurs d'application. En outre, les clusters fragmentés peuvent être déployés dans une configuration géo-distribuée pour surmonter les pannes du centre de données, comme indiqué dans la figure suivante. L’architecture ScyllaDB – multi-primaire pour une haute disponibilité et une évolutivité horizontale Contrairement à MongoDB, ScyllaDB ne suit pas les architectures RDBMS classiques avec un nœud primaire et plusieurs nœuds secondaires, mais utilise une structure décentralisée, où toutes les données sont systématiquement distribuées et répliquées sur plusieurs nœuds formant un cluster. Un cluster est une collection de nœuds interconnectés organisés en une architecture d'anneau virtuel, à travers laquelle les données sont distribuées. L'anneau est divisé en vNodes, qui représentent une gamme de jetons attribués à un nœud physique, et sont répliqués à travers les nœuds physiques selon le facteur de réplication défini pour l'espace clé. Tous les nœuds sont considérés comme égaux, dans un sens multi-primaire. Sans un leader défini, le cluster n'a pas de point de défaillance unique. Les nœuds peuvent être des serveurs locaux individuels, ou des serveurs virtuels (instances de cloud public) composés d'un sous-ensemble de matériel sur un serveur physique plus grand. Sur chaque nœud, les données sont encore Tous les nœuds communiquent entre eux par le biais de Ce protocole décide dans quelle partition les données sont écrites et recherche les enregistrements de données dans la partition droite en utilisant les indices. Le protocole de Gossip En ce qui concerne l'échelle, l'architecture de ScyllaDB est conçue pour faciliter le sharding horizontal sur plusieurs serveurs et régions. Le sharding dans ScyllaDB se fait au niveau de la table, et une table peut être shardée en fonction d'une clé de partition. La clé de partition peut être une seule colonne ou un composé de plusieurs colonnes. ScyllaDB prend également en charge le sharding basé sur la gamme, où les lignes sont distribuées sur les shards en fonction de la gamme de valeurs de la clé de partition, ainsi que le sharding basé sur le hash pour distribuer les données de manière égale et éviter les points chauds. En outre, ScyllaDB permet de reproduire les données sur plusieurs centres de données pour une disponibilité plus élevée et des latences plus faibles. Dans cette configuration multi-centre de données ou multi-région, les données entre les centres de données sont reproduites de manière asynchrone. Du côté client, les applications peuvent ou ne peuvent pas être conscientes du déploiement de plusieurs datacenters, et il appartient au développeur d'application de décider de la prise de conscience du(s) datacenter(s) de retour. Cela peut être configuré via les options de cohérence de lecture et d'écriture qui définissent si les requêtes sont exécutées contre un seul datacenter ou sur tous les datacenters. Un point de vue comparatif de l'évolutivité sur les architectures distribuées de MongoDB et ScyllaDB En ce qui concerne l'évolutivité, les approches de distribution sensiblement différentes de ScyllaDB et de MongoDB doivent être prises en compte, en particulier pour les clusters autonomes fonctionnant sur site ou sur IaaS. L'architecture de MongoDB permet facilement l'évolutivité des charges de travail lourdes en augmentant le nombre de secondaries dans un ensemble de répliques. Néanmoins, pour évoluer les charges de travail avec une proportion d’écriture notable, les ensembles de répliques doivent être transformés en un ensemble de répliques fragmentées et cela comporte plusieurs défis. Tout d’abord, deux services MongoDB supplémentaires sont nécessaires: n routers de requête (mongos) et un ensemble de répliques de serveurs de configuration pour assurer une disponibilité élevée. Par conséquent, des ressources considérablement plus importantes sont nécessaires pour permettre la fragmentation en premier lieu. De plus, la complexité opérationnelle augmente nettement. Par exemple, un cluster fragmenté avec trois tranches nécessite un ensemble de répliques de trois instances de mongos, un ensemble de répliques de trois serveurs de configuration et trois tranches – chacune Le deuxième défi est la répartition des données dans le cluster fragmenté. Ici, MongoDB applique une tâche en arrière-plan en continu qui déclenche de manière autonome la redistribution des données à travers les fragmentations. La répartition ne se produit pas dès qu'un nouveau fragment est ajouté au cluster, mais lorsque certains seuils internes sont atteints. Par conséquent, l'augmentation du nombre de fragmentations accélérera immédiatement le cluster mais peut avoir un effet d'échelle retardé. Jusqu'à la version 5.0 de MongoDB, les ingénieurs MongoDB recommandent eux-mêmes de ne pas fragmenter, mais plutôt d'écheller verticalement avec des machines plus grandes si possible. L'échelle d'un cluster ScyllaDB est comparablement facile et transparente pour l'utilisateur grâce à l'architecture multi-primaire de ScyllaDB. Ici, chaque nœud est égal et aucun service supplémentaire n'est nécessaire pour élargir le cluster à des centaines de nœuds. De plus, la répartition des données est déclenchée dès qu'un nouveau nœud est ajouté au cluster. Dans ce contexte, ScyllaDB offre des avantages clairs par rapport à MongoDB. Premièrement, grâce à l'approche de hachage cohérente, les données n'ont pas besoin d'être répartis sur l'ensemble du cluster, uniquement sur un sous-ensemble de nœuds. Deuxièmement, la partition commence par l'ajout Les principales différences d’évolutivité sont résumées dans le tableau suivant : Conclusion et Outlook Lorsque vous comparez les deux des bases de données, vous découvrez toujours quelques parallèles, mais aussi de nombreuses différences considérables. . Les deux bases de données traitent de cas d'utilisation similaires et ont une stratégie de produit et de communauté similaire. Mais quand il s'agit du côté technique, vous pouvez voir les approches et les objectifs différents. Les deux bases de données sont construites pour permettre une haute disponibilité grâce à une architecture distribuée. Mais quand il s'agit des charges de travail cibles, MongoDB permet de démarrer facilement avec des déploiements de nœud unique ou de groupe de répliques qui conviennent bien pour les charges de travail petites et moyennes, tandis que la gestion de grosses charges de travail et des ensembles de données devient un défi en raison de l'architecture technique. Noël ScyllaDB contre MongoDB ScyllaDB aborde clairement les charges de travail critiques pour la performance qui exigent une évolutivité facile et élevée, un débit élevé, une latence faible et stable, et tout dans un déploiement multi-datacenter.Cela est également démontré par les cas d'utilisation intensive de données d'entreprises telles que Discord, Numberly ou TRACTIAN qui ont migré de MongoDB à ScyllaDB pour résoudre avec succès les problèmes de performance. Et pour fournir des informations complémentaires sur leurs capacités de performance respectives, nous fournissons une comparaison de performance transparente et reproduisable dans un rapport de référence distinct qui étudie les performances, l'évolutivité et les coûts pour MongoDB Atlas et ScyllaDB Cloud. ScyllaDB vs. MongoDB Comparaison Voir le complet pour une version étendue de cette comparaison technique, y compris des détails de comparaison: Comparaison BenchANT MongoDB vs ScyllaDB Modèle de données Le langage souhaité Cas d'utilisation et exemples de clients Options de cohérence des données Expérience opérationnelle de première main
