Cassandre contre MongoDB

Envisagez-vous Cassandra ou MongoDB comme magasin de données pour votre prochain projet ? Souhaitez-vous comparer les deux bases de données ? Cassandra et MongoDB sont toutes deux des bases de données "NoSQL", mais la réalité est qu'elles sont très différentes. Ils ont des atouts et des propositions de valeur très différents. Toute comparaison doit donc être nuancée. Commençons par les exigences initiales… Aucune de ces bases de données ne remplace le SGBDR, et ce ne sont pas non plus des bases de données "ACID". Donc, si vous avez une charge de travail transactionnelle où la normalisation et la cohérence sont les principales exigences, aucune de ces bases de données ne fonctionnera pour vous. Vous feriez mieux de vous en tenir aux bases de données relationnelles traditionnelles telles que MySQL, PostgreSQL, Oracle, etc. Maintenant que nous avons éliminé les bases de données relationnelles, examinons les principales différences entre Cassandra et MongoDB qui vous aideront à prendre la décision. Dans cet article, je ne vais pas discuter de fonctionnalités spécifiques, mais souligner quelques différences stratégiques de haut niveau pour vous aider à faire votre choix.

1. Modèle d'objet expressif

MongoDB prend en charge un modèle d'objet riche et expressif. Les objets peuvent avoir des propriétés et les objets peuvent être imbriqués les uns dans les autres (pour plusieurs niveaux). Ce modèle est très "orienté objet" et peut facilement représenter n'importe quelle structure d'objet dans votre domaine. Vous pouvez également indexer la propriété de n'importe quel objet à n'importe quel niveau de la hiérarchie - c'est étonnamment puissant ! Cassandra, quant à elle, propose une structure de table assez traditionnelle avec des lignes et des colonnes. Les données sont plus structurées et chaque colonne a un type spécifique qui peut être spécifié lors de la création.

Verdict :si votre domaine problématique a besoin d'un modèle de données riche, l'hébergement MongoDB vous convient mieux.

2. Index secondaires

Les index secondaires sont une construction de première classe dans MongoDB. Cela facilite l'indexation de toute propriété d'un objet stocké dans MongoDB même s'il est imbriqué. Cela facilite grandement les requêtes basées sur ces index secondaires. Cassandra n'a qu'un support superficiel pour les index secondaires. Les index secondaires sont également limités aux colonnes uniques et aux comparaisons d'égalité. Si vous allez principalement interroger par la clé primaire, alors Cassandra fonctionnera bien pour vous.

Verdict :  Si votre application a besoin d'index secondaires et de flexibilité dans le modèle de requête, alors MongoDB vous convient mieux.

3. Haute disponibilité

MongoDB prend en charge un modèle « maître unique ». Cela signifie que vous avez un nœud maître et un certain nombre de nœuds esclaves. En cas de panne du maître, l'un des esclaves est élu maître. Ce processus se produit automatiquement mais cela prend du temps, généralement 10 à 40 secondes. Pendant cette période d'élection d'un nouveau leader, votre jeu de répliques est arrêté et ne peut pas accepter les écritures. Cela fonctionne pour la plupart des applications, mais dépend en fin de compte de vos besoins. Cassandra prend en charge un modèle « maître multiple ». La perte d'un seul nœud n'affecte pas la capacité du cluster à accepter les écritures. Vous pouvez donc atteindre une disponibilité de 100 % pour les écritures.

Verdict :Si vous avez besoin d'une disponibilité à 100 %, Cassandra est la meilleure solution pour vous.

4. Évolutivité en écriture

MongoDB avec son modèle "maître unique" ne peut accepter les écritures que sur le primaire. Les serveurs secondaires ne peuvent être utilisés que pour les lectures. Donc, essentiellement, si vous avez un ensemble de réplicas à trois nœuds, seul le maître prend des écritures et les deux autres nœuds ne sont utilisés que pour les lectures. Cela limite considérablement l'évolutivité en écriture. Vous pouvez déployer plusieurs partitions, mais essentiellement seulement 1/3 de vos nœuds de données peuvent accepter des écritures. Cassandra avec son modèle "maître multiple" peut accepter des écritures sur n'importe quel serveur. Essentiellement, votre évolutivité en écriture est limitée par le nombre de serveurs que vous avez dans le cluster. Plus vous avez de serveurs dans le cluster, mieux il évoluera.

Verdict :si l'évolutivité en écriture est votre truc, Cassandra est la meilleure solution pour vous.

5. Prise en charge du langage de requête

Cassandra prend en charge le langage de requête CQL qui est très similaire à SQL. Si vous avez déjà une équipe d'analystes de données, ils pourront transférer la majorité de leurs compétences SQL, ce qui est très important pour les grandes organisations. Cependant, CQL n'est pas un SQL ANSI complet - Il a plusieurs limitations (pas de support de jointure, pas de clauses OR), etc. MongoDB à ce stade ne prend pas en charge un langage de requête. Les requêtes sont structurées en fragments JSON.

Verdict :Si vous avez besoin d'une prise en charge du langage de requête, Cassandra est la meilleure solution pour vous.

6. Benchmarks de performances

Parlons performances. À ce stade, vous vous attendez probablement à une comparaison des performances des bases de données. Je n'ai délibérément pas inclus de critères de performance dans la comparaison. Dans toute comparaison, nous devons nous assurer que nous faisons une comparaison de pommes à pommes.

1.  Modèle de base de données  - Le modèle/schéma de base de données de l'application testée fait une grande différence. Certains schémas sont bien adaptés à MongoDB et d'autres à Cassandra. Ainsi, lors de la comparaison de bases de données, il est important d'utiliser un modèle qui fonctionne raisonnablement bien pour les deux bases de données.
2.  Caractéristiques de charge – Les caractéristiques de la charge de référence sont très importantes. Par exemple. Dans les benchmarks lourds en écriture, je m'attendrais à ce que Cassandra fume MongoDB. Cependant, dans les benchmarks à lecture intensive, MongoDB et Cassandra devraient avoir des performances similaires.
3. Exigences de cohérence - C'est délicat. Vous devez vous assurer que les exigences de cohérence en lecture/écriture spécifiées sont identiques dans les deux bases de données et ne favorisent pas un participant. Très souvent, dans un certain nombre de benchmarks "Marketing", les boutons sont réglés pour désavantager l'autre côté. Faites donc très attention aux paramètres de cohérence.

Une dernière chose à garder à l'esprit est que la charge de référence peut ou non refléter les performances de votre application. Ainsi, pour que les benchmarks soient utiles, il est très important de trouver une charge de référence qui reflète les caractéristiques de performance de votre application. Voici quelques points de repère que vous voudrez peut-être consulter :
- Benchmarks de performance NoSQL
- Cassandra contre MongoDB contre Couchbase contre HBase

7. Facilité d'utilisation

Si vous aviez posé cette question il y a quelques années, MongoDB serait le grand gagnant. C'est une tâche assez simple pour que MongoDB soit opérationnel. Au cours des deux dernières années, cependant, Cassandra a fait de grands progrès dans cet aspect du produit. Avec l'adoption de CQL comme interface principale pour Cassandra, il est allé encore plus loin :ils ont permis à des légions de programmeurs SQL de simplifier l'utilisation de Cassandra très facilement.

Verdict :Les deux sont assez faciles à utiliser et à monter en puissance.

8. Agrégation native

MongoDB dispose d'un framework d'agrégation intégré pour exécuter un pipeline ETL afin de transformer les données stockées dans la base de données. C'est idéal pour les petites et moyennes tâches, mais à mesure que vos besoins en traitement de données deviennent plus compliqués, le cadre d'agrégation devient difficile à déboguer. Cassandra n'a pas de cadre d'agrégation intégré. Des outils externes comme Hadoop, Spark sont utilisés pour cela.

9. Modèles sans schéma

Dans MongoDB, vous pouvez choisir de n'appliquer aucun schéma à vos documents. Alors qu'il s'agissait de la valeur par défaut dans les versions précédentes, dans la nouvelle version, vous avez la possibilité d'appliquer un schéma pour vos documents. Chaque document dans MongoDB peut avoir une structure différente et c'est à votre application d'interpréter les données. Bien que cela ne soit pas pertinent pour la plupart des applications, dans certains cas, la flexibilité supplémentaire est importante. Cassandra dans les versions les plus récentes (avec CQL comme langue par défaut) fournit un typage statique. Vous devez définir le type de colonne à l'avance.

Pour résumer, voici les différences importantes sous forme de tableau :
Si vous souhaitez voir l'infographie complète, vous pouvez visiter notre page de comparaison Cassandra vs MongoDB.