MongoDB vs. Cassandra [fermé]


739

J'évalue quelle pourrait être la meilleure option de migration.

Actuellement, je suis sur un MySQL fragmenté (partition horizontale), avec la plupart de mes données stockées dans des blobs JSON. Je n'ai pas de requêtes SQL complexes (déjà migré depuis que j'ai partitionné ma base de données).

À l'heure actuelle, il semble que MongoDB et Cassandra soient des options probables. Ma situation:

  • Beaucoup de lectures dans chaque requête, écritures moins régulières
  • Pas inquiet de l'évolutivité "massive"
  • Plus préoccupé par la configuration, la maintenance et le code simples
  • Minimisez le coût matériel / serveur

4
Une statistique officielle de référence de performance est disponible. Cassandra vs MongoDB vs HBase
Ravi

1
> Beaucoup de lectures dans chaque requête, écritures moins régulières => Recherchez CQRS (séparez vos lectures de vos écritures probablement sans source d'événements mais vérifiez si vous pouvez mettre à jour votre modèle de lecture asynchrone .. la synchronisation peut également fonctionner .. cela dépend de votre utilisation -cases)
bodrin

2
C'est une excellente question en fait. Je me demande s'il existe une version mise à jour? Celui-ci est très vieux maintenant
slashdottir

Réponses:


584

Beaucoup de lectures dans chaque requête, moins d'écritures régulières

Les deux bases de données fonctionnent bien sur les lectures où l'ensemble de données à chaud tient en mémoire. Les deux mettent également l'accent sur les modèles de données sans jointure (et encouragent plutôt la dénormalisation), et fournissent tous deux des index sur les documents ou les lignes , bien que les index de MongoDB soient actuellement plus flexibles.

Le moteur de stockage de Cassandra fournit des écritures à temps constant, quelle que soit la taille de votre ensemble de données. Les écritures sont plus problématiques dans MongoDB, en partie à cause du moteur de stockage basé sur b-tree, mais plus à cause du verrouillage multi-granularité qu'il fait.

Pour l'analyse, MongoDB fournit une implémentation de carte / réduction personnalisée; Cassandra fournit une prise en charge native de Hadoop, y compris pour Hive (un entrepôt de données SQL basé sur Hadoop map / Reduce) et Pig (un langage d'analyse spécifique à Hadoop que beaucoup pensent être mieux adapté pour cartographier / réduire les charges de travail que SQL). Cassandra prend également en charge l'utilisation de Spark .

Pas inquiet de l'évolutivité "massive"

Si vous cherchez un seul serveur, MongoDB est probablement un meilleur choix. Pour ceux qui sont plus préoccupés par la mise à l'échelle, l'architecture sans point de défaillance unique de Cassandra sera plus facile à configurer et plus fiable. (Le verrouillage d'écriture global de MongoDB a également tendance à devenir plus pénible.) Cassandra donne également beaucoup plus de contrôle sur le fonctionnement de votre réplication, y compris la prise en charge de plusieurs centres de données.

Plus préoccupé par la configuration, la maintenance et le code simples

Les deux sont simples à configurer, avec des valeurs par défaut raisonnables pour un seul serveur. Cassandra est plus simple à installer dans une configuration multi-serveurs car il n'y a pas de nœuds de rôle spécial à craindre.

Si vous utilisez actuellement des blobs JSON, MongoDB est incroyablement bon pour votre cas d'utilisation, étant donné qu'il utilise BSON pour stocker les données. Vous pourrez avoir des données plus riches et plus interrogeables que vous ne le feriez dans votre base de données actuelle. Ce serait la victoire la plus importante pour Mongo.


86
Totalement différent, un commentaire n'est pas assez grand, mais ... Cassandra est un hybride dynamo / google bigtable à évolution linéaire (temps constant amorti) qui propose des écritures rapides quelle que soit la taille des données. Son ensemble de fonctionnalités est minimaliste, un peu au-delà de celui d'un magasin de valeurs clés commandé. MongoDB est un magasin de documents très complet (et rapide) au prix de la durabilité et garantit la persistance des écritures (car elles ne sont pas immédiatement écrites sur le disque). Ce sont des bêtes différentes avec des philosophies différentes, MongoDB est plus proche d'un remplacement RDMS ...
Michael

28
tandis que Cassandra est de niveau inférieur mais permet une mise à l'échelle supérieure (voir Twitter / Digg / Facebook), mais vous devrez être délibéré dans la façon dont vous disposez vos données, créez des index secondaires, etc., car aucune interrogation flexible n'est autorisée.
Michael

11
Parce que tout le monde a mentionné Twitter ici à propos de Cassandra: ils n'utilisent pas Cassandra pour les tweets persistants, ils utilisent toujours MySQL ici ( engineering.twitter.com/2010/07/cassandra-at-twitter-today.html ). D'accord, mais je peux imaginer qu'ils stockent encore beaucoup de données à d'autres fins dans Cassandra.
H6.

7
Il semble que le verrou d'écriture global ait été supprimé dans Mongo 2.2 ...
Matt Farmer

16
Même avant la mise en ligne de mon projet, je ressens les points faibles de Mongodb. La sauvegarde à chaud est une exigence de base. Pour effectuer une sauvegarde à chaud sur un serveur Linux, vous devez d'abord configurer une partition LVM (pas si courante) et prendre un instantané avant chaque session de sauvegarde. Un autre moyen simple est d'utiliser le service de sauvegarde payant Mongodb. Mais, ce service coûte cher (2,3 $ / Go / mois). Bientôt, vous aurez besoin d'un jeu de réplicas pour la tolérance aux pannes. Avec la version open source, les nœuds ne peuvent échanger des données qu'en texte clair. Pour SSL, vous devez aller avec l'édition Entprise. Et c'est 10 000 $. Au revoir Mongodb. Refactorisation de mon code à Cassandra.
Karthik Sankar

146

J'ai beaucoup utilisé MongoDB (au cours des 6 derniers mois), créant un système de gestion de données hiérarchique, et je peux garantir à la fois la facilité de configuration (l'installer, l'exécuter, l'utiliser!) Et la vitesse. Tant que vous réfléchissez soigneusement aux index, il peut absolument crier le long de la vitesse.

Je suppose que Cassandra, en raison de son utilisation avec des projets à grande échelle comme Twitter, a une meilleure fonctionnalité de mise à l'échelle, bien que l'équipe MongoDB y travaille sur la parité. Je dois souligner que je n'ai pas utilisé Cassandra au-delà de la phase d'essai, donc je ne peux pas parler des détails.

Le vrai swinger pour moi, lorsque nous évaluions les bases de données NoSQL, était l'interrogation - Cassandra est fondamentalement juste un magasin de valeurs / clés géant, et l'interrogation est un peu fastidieuse (au moins par rapport à MongoDB), donc pour les performances, vous devrez dupliquer pas mal de données comme une sorte d'index manuel. MongoDB, quant à lui, utilise un modèle "requête par exemple".

Par exemple, supposons que vous ayez une collection (langage MongoDB pour l'équivalent d'une table RDMS) contenant des utilisateurs. MongoDB stocke les enregistrements sous forme de documents, qui sont essentiellement des objets JSON binaires. par exemple:

{
   FirstName: "John",
   LastName: "Smith",
   Email: "john@smith.com",
   Groups: ["Admin", "User", "SuperUser"]
}

Si vous vouliez trouver tous les utilisateurs appelés Smith qui ont des droits d'administrateur, il vous suffit de créer un nouveau document (dans la console d'administration en utilisant Javascript, ou en production en utilisant la langue de votre choix):

{
   LastName: "Smith",
   Groups: "Admin"
}

... puis exécutez la requête. C'est ça. Il y a des opérateurs ajoutés pour les comparaisons, le filtrage RegEx, etc., mais tout est assez simple, et la documentation basée sur Wiki est assez bonne.


54
Mise à jour (8 août 2011): le centre de données d'Amazon Ireland EC2 a eu un incident lié à la foudre la nuit dernière, et en triant la récupération de notre serveur, j'ai découvert un point assez crucial: si vous avez un ensemble de réplication de deux serveurs (et ils sont faciles à configurer), assurez-vous d'avoir un nœud Arbiter, donc si l'un tombe en panne, l'autre ne panique pas et ne bloque pas en mode secondaire! Croyez-moi, c'est difficile de trier avec une grande base de données.
Richard K.

8
pour ajouter ce que @Richard K a dit, vous devriez avoir un nœud arbitre lorsque vous avez un nombre pair de nœuds (primaire + secondaire) dans un jeu de répliques.
Amareswar

Ajouté à cela, considérez mongodb lorsque davantage d'agrégation doit être effectuée sur l'analyse des données.
user1503117

As long as you think about indexes carefully, it can absolutely scream along, speed-wise.Attendez que votre mémoire physique soit pleine et que le système d'exploitation commence la page en
défaut

117

Pourquoi choisir entre une base de données traditionnelle et un magasin de données NoSQL? Utilise les deux! Le problème avec les solutions NoSQL (au-delà de la courbe d'apprentissage initiale) est le manque de transactions - vous effectuez toutes les mises à jour de MySQL et demandez à MySQL de remplir un magasin de données NoSQL pour les lectures - vous bénéficiez alors des points forts de chaque technologie. Cela ajoute plus de complexité, mais vous avez déjà le côté MySQL - ajoutez simplement MongoDB, Cassandra, etc. au mix.

Les banques de données NoSQL évoluent généralement bien mieux qu'une base de données traditionnelle pour les mêmes spécifications sinon - il y a une raison pour laquelle Facebook, Twitter, Google et la plupart des start-ups utilisent des solutions NoSQL. Ce ne sont pas seulement les geeks qui se lancent dans les nouvelles technologies.


8
Je suis entièrement d'accord. J'utilise mongodb + mysql dans l'un des produits à venir que j'architecte. Il s'agit d'un cloud de produits financiers à venir. mysql est utilisé là où nous avons absolument besoin de capacités transactionnelles. mongodb est utilisé pour stocker des structures de données complexes non informatiques qui doivent simplement être remontées en cas de besoin. fonctionne bien jusqu'à présent. :)
Ram on Rails-n-React

J'ai également utilisé une telle approche double dans la plupart de mes projets, et dans certains autres, le système de fichiers monté NFS a été utilisé avec PostgreSQL pour les blobs sismiques proches de 1 Go dans certains cas. Un chemin est une sorte de requête vers la base de données de valeurs clés.
Audrius Meskauskas

1
Voici un lien vers une question que j'ai posée sur la façon d'architecturer les bases de données sql et nosql: dba.stackexchange.com/questions/102053/… Je pourrais utiliser certaines informations que vous pourriez avoir
je

Il a déjà échappé aux transactions pour de bon => maintenant une évolutivité infinie pourrait être possible .. sinon -> pas :)
bodrin

1
Ce n'est pas une bonne solution si vos données sont distribuées
Esteban Verbel

60

Je vais probablement être un homme étrange, mais je pense que vous devez rester avec MySQL. Vous n'avez pas décrit un vrai problème que vous devez résoudre, et MySQL / InnoDB est un excellent back-end de stockage même pour les données blob / json.

Il existe une astuce courante parmi les ingénieurs Web pour essayer d'utiliser plus de NoSQL dès que la réalisation arrive que toutes les fonctionnalités d'un SGBDR ne sont pas utilisées. Cela seul n'est pas une bonne raison, car le plus souvent les bases de données NoSQL ont des moteurs de données plutôt médiocres (ce que MySQL appelle un moteur de stockage).

Maintenant, si vous n'êtes pas de ce type, veuillez spécifier ce qui manque dans MySQL et vous recherchez dans une base de données différente (comme le partage automatique, le basculement automatique, la réplication multimaître, une garantie de cohérence des données plus faible dans cluster payant avec un débit d'écriture plus élevé, etc.).


13
Il utilise le sharding, ce qui signifie que ses données sont partitionnées manuellement sur les serveurs. Mongodb peut automatiser le partage, ce qui peut être un avantage.
fabspro

18
Il stocke également principalement des objets blob JSON dans le SGBDR, ce qui rend la conception relationnelle (fonctionnalités) inutile.
Damir Sudarevic

4
Le modèle de données et sharding automatique sont en effet différents, mais au moment de choisir une base de données, vous avez besoin de regarder le moteur de stockage premier , et le reste des cloches et de sifflets seconde. Comment le moteur de stockage va-t-il fonctionner sous un pic de charge? Comment la fonctionnalité de partage automatique va-t-elle fonctionner sous un pic de flux de données? Avant de céder le contrôle à la base de données pour ces aspects importants, vous feriez mieux de vous assurer qu'elle sera capable de la tâche.
Kostja

7
Le modèle relationnel est l'un des modèles de données les plus réfléchis, efficaces à mettre en œuvre et frugaux. «Rendre des fonctionnalités de conception relationnelle inutiles» peut être lié à des contraintes, des déclencheurs ou l'intégrité référentielle - mais tout cela est payant à l'utilisation.
Kostja

20

Je n'ai pas utilisé Cassandra, mais j'ai utilisé MongoDB et je pense que c'est génial.

Si vous recherchez une configuration simple, c'est la suivante: il vous suffit de décompresser MongoDB et d'exécuter le démon mongod et c'est tout ... il fonctionne.

Évidemment, ce n'est qu'un débutant, mais pour commencer, c'est facile.


22
AFAIK, il en va de même pour Cassandra. Décochez, exécutez le démon. Le cluster de test est configuré et prêt pour la production!
asgs

13

J'ai vu une présentation sur mongodb hier. Je peux certainement dire que la configuration était "simple", aussi simple que de la déballer et de l'allumer. Terminé.

Je crois que mongodb et cassandra fonctionneront sur pratiquement n'importe quel matériel Linux régulier, vous ne devriez donc pas trouver trop de barrière dans ce domaine.

Je pense que dans ce cas, en fin de compte, il s'agira de savoir avec qui vous vous sentez le plus à l'aise et qui a un ensemble d'outils que vous préférez. En ce qui concerne la présentation sur mongodb, le présentateur a indiqué que le jeu d'outils pour mongodb était assez léger et qu'il y avait beaucoup (ils en ont vraiment dit) des outils similaires à ceux disponibles pour MySQL. C'était bien sûr leur expérience donc YMMV. Une chose que j'aimais à propos de mongodb était qu'il semblait y avoir beaucoup de support de langage pour cela (Python et .NET étant les deux que j'utilise principalement).

La liste des sites utilisant mongodb est assez impressionnante , et je sais que Twitter vient de passer à l'utilisation de cassandra.


4
À la fin de la journée, c'est la comparaison pommes vs oranges. Les deux bases de données ont leurs propres forces. Voici quelques éléments à considérer - Le modèle d'objet, les index secondaires, l'évolutivité de l'écriture, la haute disponibilité, etc. ont un article de blog qui explique les différences stratégiques de haut niveau entre mongodb et cassandra ici - scalegrid.io/blog/cassandra-vs-mongodb
Dharshan
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.