Apache Cassandra et MongoDB

Apache Cassandra et MongoDB sont des bases de données NoSQL largement utilisées, conçues pour stocker et gérer de grandes quantités de données.

La popularité de ces deux systèmes de base de données s’explique en partie par leur haut niveau d’évolutivité et de disponibilité. Les deux sont utilisés depuis plus de dix ans : Cassandra a vu le jour en tant que projet open source en 2008, et MongoDB est sorti l’année suivante.

Malgré leurs similitudes, Apache Cassandra et MongoDB diffèrent considérablement en ce qui concerne leurs modèles de données, leur architecture et autres composants. Ces différences fondamentales déterminent la performance de leurs caractéristiques principales, ainsi que leurs cas d’utilisation dans la gestion des données.

Avant de comparer Apache Cassandra et MongoDB, il convient d’apporter quelques précisions au sujet des bases de données NoSQL.

Les bases de données NoSQL sont des bases de données distribuées. Cela signifie que les informations qu’elles contiennent font l’objet d’une réplication vers divers nœuds (serveurs qui stockent les données). Cette architecture distribuée assure une disponibilité et une durabilité élevées : si un ou plusieurs nœuds sont mis hors ligne, le reste de la base de données continue de fonctionner.

Mais surtout, les bases de données NoSQL sont conçues pour stocker et interroger des données en dehors des structures traditionnelles des systèmes de gestion de bases de données relationnelles (SGBDR). Au lieu d’adopter la structure tabulaire stricte inhérente aux bases de données relationnelles traditionnelles, les bases de données non relationnelles sont conçues sans suivre un schéma rigide. Cela permet une évolutivité rapide pour gérer les jeux de données volumineux, qu’ils soient structurés, semi-structurés ou non structurés.

(Il est important de noter que l’évolutivité prisée dans les bases de données NoSQL, comme Cassandra et MongoDB, est horizontale (ou « scale-out »). Dans le cas de l’évolutivité horizontale, les workloads peuvent être réparties entre les serveurs, tandis que l’évolutivité verticale, ou « scale-up », associée aux bases de données SQL, exige un ajout de mémoire au matériel existant).

En raison de leur performance, de leur évolutivité et de leur flexibilité, les bases de données NoSQL se sont imposées comme incontournables pour prendre en charge les applications de big data et les workloads en temps réel. Outre Apache Cassandra et MongoDB, parmi les bases de données NoSQL les plus utilisées, citons DynamoDB (fournie par AWS), Redis et CouchDB.

Si les deux ont été créés quelques années seulement après le tournant du millénaire, Apache Cassandra et MongoDB ont des histoires bien distinctes.

Apache Cassandra remonte aux débuts de Facebook vers 2007, lorsque les ingénieurs recherchaient un système capable de stocker les données de la plateforme de messagerie en plein essor de l’entreprise. En combinant des modèles de base de données NoSQL bien établis, ils ont créé un système alliant structures de données efficaces et cohérence à terme, dont les mises à jour se propagent jusqu’à ce que toutes les copies correspondent. Les ingénieurs ont publié Cassandra comme projet open source en 2008. Un an plus tard, l’Apache Software Foundation l’a pris sous son aile. 

MongoDB a vu le jour en 2007, dans le cadre d’un projet de plateforme à la demande de la société 10Gen. L’entreprise a choisi de se concentrer sur MongoDB (nom inspiré du mot anglais « humongous », que l’on peut traduire par « gigantesque »), qu’elle a développé comme base de données orientée document, rapide et facile à utiliser. ¹

10Gen, qui a fini par s’appeler MongoDB Inc., a lancé MongoDB comme projet open source en 2009. Ses versions les plus récentes sont toutefois publiées sous licence (Server Side Public License v1).

Les principales différences entre Apache Cassandra et MongoDB déterminent leur performance et leurs cas d’utilisation. Les éléments clés sont les suivants :

• Modèles de données
• Architecture et stockage
• Langages de requête et autres

Les bases de données NoSQL s’appuient sur l’un de ces quatre types de modèles de données :

• Modèle de document : les données sont stockées sous forme de documents structurés, généralement en JSON (JavaScript Object Notation) ou en BSON (Binary JSON).
• Modèle à colonnes larges : les données sont stockées dans des tables dont les colonnes sont dynamiques, ce qui veut dire que chaque ligne de la table peut avoir un nombre différent de colonnes.
• Modèle clé-valeur : les données sont stockées sous forme de paires clé-valeur (identifiants ou étiquettes associés à certaines valeurs).
• Modèle graphique : les données sont stockées sous forme de nœuds et d’arêtes représentant des entités et des relations.

Le modèle de données de Cassandra est un modèle à colonnes larges, également connu sous le nom de « magasin à colonnes larges ». Chaque ligne des tables Cassandra comporte un jeu de colonnes et une clé de partition unique, qui permet de répartir les données entre les nœuds et les centres de données. Les lignes sont identifiées à l’aide de clés primaires, qui peuvent être composées de clés de partition et, éventuellement, de clés de cluster (colonnes permettant d’identifier les lignes au sein d’une partition ou d’un groupe associé).

Cette approche est plus flexible que celle des bases de données relationnelles, au sein desquelles un espace est alloué à un nombre défini de colonnes. Avec le modèle de données de Cassandra, où les colonnes sont utilisées uniquement en cas de besoin, le stockage est plus efficace et les requêtes plus rapides. ²

MongoDB, quant à lui, utilise un modèle de document. Les données sont principalement stockées au format BSON, une représentation binaire de JSON développée par MongoDB.

Le format BSON résout les défis que le standard JSON présentait en matière de bases de données : prise en charge limitée des types de données, absence de longueur fixée pour les objets (ce qui ralentit la traversée) et absence de métadonnées (ce qui ralentit la récupération des documents). Le format BSON a été pensé pour améliorer la vitesse et l’efficacité en encodant les informations de format et de longueur. Il prend également en charge certains types de données JSON non natifs, tels que les dates et les données binaires. ³

Les bases de données NoSQL Apache Cassandra et MongoDB prennent en charge les systèmes distribués, au sein desquels les données sont stockées sur plusieurs ressources informatiques pour limiter les temps d’arrêt. Cependant, tout comme leurs modèles de données respectifs, l’architecture sous-jacente à cette distribution est fondamentalement différente.

Apache Cassandra s’appuie sur une architecture peer-to-peer. Tous les nœuds d’un cluster Cassandra sont égaux, sans dépendre d’un nœud maître. Lorsque l’on place des données dans le cluster, on applique une fonction de hachage à la clé de partition de la ligne, et la sortie est utilisée pour attribuer des données à certains nœuds. Les données sont également copiées vers d’autres nœuds.

Le facteur de réplication des bases de données Cassandra indique le nombre de copies des données qui y sont stockées. Le moteur de stockage de Cassandra suit un flux (ou chemin d’écriture) étape par étape, composé d’un journal de validation, d’une table en mémoire (memtable) et de fichiers de table de chaînes triées (SSTable).

Contrairement à Cassandra, MongoDB repose sur un modèle primaire/secondaire pour son architecture distribuée. Dans MongoDB, chaque jeu de copies (un groupe d’instances) se compose d’un nœud primaire, qui gère toutes les opérations d’écriture (ajout ou modification des données), et de nœuds secondaires, qui reflètent les données du nœud primaire.

Les grands jeux de données MongoDB peuvent également être distribués sur plusieurs machines, grâce à un processus connu sous le nom de « sharding ». Les informations sont divisées en clusters, c’est-à-dire plusieurs jeux de copies et un routeur qui transmet les requêtes des applications vers ses derniers, afin d’améliorer la capacité du système à traiter les requêtes.

Les bases de données utilisent également différentes méthodes d’indexation. Dans Apache Cassandra, l’index primaire est la clé de partition, bien que la documentation Cassandra cite l’indexation par stockage (qui comporte des index pour les colonnes sans partition) comme adaptée à la plupart des cas d’utilisation. ⁴ Cassandra dispose également d’index secondaires, à savoir des index locaux situés dans des tables distinctes des valeurs en cours d’indexation. MongoDB prend en charge plusieurs types d’index pour différents cas d’utilisation, notamment les index géospatiaux, les index à clés multiples et les index textuels.

Par définition, les bases de données NoSQL n’utilisent pas SQL (Structured Query Language), le langage de programmation standardisé pour les bases de données relationnelles. Apache Cassandra et MongoDB ont chacun son propre langage de requête.

Cassandra utilise une version personnalisée de SQL, appelée Cassandra Query Language (CQL). Si CQL ressemble dans une large mesure à SQL, il existe des différences essentielles entre les deux. Par exemple, SQL fonctionne sur des tables normalisées, tandis que CQL est conçu pour les données Cassandra dénormalisées, alignées sur les clés de partition. En outre, SQL est optimisé pour les transactions, tandis que CQL est conçu pour les requêtes en temps réel et les opérations d’écriture à haut volume.

MongoDB utilise le langage MQL (MongoDB Query Language). Conçu pour l’interrogation des modèles de documents, MQL comporte la même syntaxe que ces derniers, s’éloignant davantage de SQL que le langage de requête Cassandra. MQL est apprécié pour sa capacité à traiter un large éventail de requêtes et à manipuler les données (par exemple, requêtes complexes, pipelines d’agrégation et requêtes de données géospatiales). ⁵

Outre leurs langages de requête respectifs, ces bases de données diffèrent par leur prise en charge de la programmation. MongoDB fournit des pilotes officiels pour une douzaine de langages de programmation dont Java, Python, Ruby et Node.js. Ces langages, parmi d’autres, sont également compatibles avec Cassandra, mais les pilotes sont en grande partie proposés par des fournisseurs tiers.

Les différences fondamentales entre Apache Cassandra et MongoDB donnent lieu à certaines variations dans les caractéristiques associées à leur performance. Ces variations peuvent également être expliquées par le théorème CAP.

CAP (Consistency, Availability, Partition Tolerance) désigne les trois caractéristiques souhaitées pour les systèmes distribués : cohérence (tous les clients voient les mêmes données en même temps), disponibilité (tout client interrogeant les données reçoit une réponse, même si un ou plusieurs nœuds sont en panne) et tolérance au partitionnement (le cluster de nœuds continue de fonctionner même si la communication entre deux ou plusieurs nœuds est interrompue).

Selon le théorème CAP, un système distribué ne peut fournir que deux des trois caractéristiques souhaitées. Apache Cassandra est généralement classé comme base de données « AP », offrant un niveau élevé de disponibilité et de tolérance au partitionnement.

MongoDB, connu comme base de données « CP », excelle en matière de tolérance au partitionnement et de cohérence. Sachez toutefois que pour les deux bases de données, il existe également des mesures permettant d’améliorer la performance des caractéristiques présumées compromises, à savoir la cohérence pour Cassandra, et la disponibilité pour MongoDB.

Examinons de plus près les trois caractéristiques souhaitées.

Cassandra garantit une haute disponibilité car, en tant que système décentralisé avec des données répliquées sur plusieurs nœuds, il présente une fonctionnalité de haute tolérance aux pannes et n’a pas de point de défaillance unique. Si un nœud est en panne, les nœuds possédant des copies des mêmes données peuvent répondre aux requêtes. En outre, la réplication des données vers des centres de données répartis dans le monde entier garantit une faible latence aux utilisateurs locaux.

Comme l’architecture de MongoDB repose sur un modèle primaire/secondaire, un point de défaillance unique peut survenir lorsqu’un nœud primaire tombe en panne. Cependant, le basculement assuré par MongoDB est considéré comme robuste : lors de ce que l’on appelle les « élections de jeu de copies », les nœuds appartenant à un jeu sélectionnent un nouveau nœud primaire pour remplacer celui devenu indisponible. Ce processus permet à MongoDB d’offrir une haute disponibilité, bien qu’avec un bref délai, car la performance ne reprend qu’une fois le nouveau nœud primaire choisi.

MongoDB offre un niveau de cohérence élevé, puisque tous les clients écrivent vers une source d’information unique, et chaque jeu de copies comporte un seul nœud principal recevant toutes les opérations d’écriture. Apache Cassandra, quant à lui, assure cette cohérence à terme. En effet, les clients peuvent écrire à tout moment sur le nœud de leur choix, et les incohérences sont corrigées dans les meilleurs délais.

Cassandra permet également aux utilisateurs d’améliorer la cohérence (au détriment de la disponibilité) grâce à ce que l’on appelle la « cohérence personnalisable ». Les utilisateurs sélectionnent un niveau de cohérence, qui définit le nombre de copies devant accuser réception d’une lecture ou d’une écriture avant de la confirmer à l’application cliente. Plus le niveau de cohérence est élevé, plus le nombre de copies devant répondre par accusé de réception est important. Par ailleurs, cela augmente la latence et diminue la disponibilité.

Apache Cassandra et MongoDB offrent tous deux une tolérance au partitionnement, puisqu’ils sont conçus pour continuer de fonctionner même lorsqu’une panne de communication survient dans une partie du système.

Dans Apache Cassandra, les nœuds restent disponibles en cas de problème de communication, mais certains d’entre eux peuvent ne pas fournir les versions les plus récentes des données (en réponse aux requêtes) tant que la partition n’a pas été résolue. Dans MongoDB, la disponibilité est limitée pour garantir la cohérence des données pendant que la partition est traitée.

Apache Cassandra est souvent recommandé pour les workloads à haut débit et à forte intensité d’écriture, qui sont distribuées à l’échelle mondiale et qui exigent disponibilité et évolutivité, comme le streaming et le divertissement. Par exemple, les services de streaming de Netflix utilisent Cassandra pour gérer l’activité des utilisateurs.

MongoDB est parfaitement adapté aux cas d’utilisation orientés documents et à schéma flexible, qui exigent un développement agile et une cohérence renforcée. Bon nombre d’entreprises se tournent vers MongoDB pour alimenter leur système de gestion de contenu, car MongoDB stocke et prend en charge un large éventail de ressources.

Malgré leurs différences, Apache Cassandra et MongoDB ont quelques cas d’utilisation en commun. Les études de cas démontrent que les deux bases de données sont adaptées aux applications IdO (Internet des objets), au commerce électronique et plus encore.