MongoDB et Cassandra

Question

Je suis en train d'évaluer ce qui pourrait être la meilleure option de migration.

Actuellement, je suis sur un MySQL sharded (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ées depuis que j'ai partitionné mon db).

Pour l'instant, il semble que MongoDB et Cassandra soient des options probables. Ma situation :

• Beaucoup de lectures dans chaque requête, moins d'écritures régulières
• Pas d'inquiétude quant à l'évolutivité "massive".
• Plus préoccupé par la simplicité de la configuration, de la maintenance et du code
• Minimiser le coût du matériel/serveur

Answer 1

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

Les deux bases de données obtiennent de bons résultats lors des lectures où l'ensemble de données chaudes tient en mémoire. Elles mettent également l'accent sur les modèles de données sans jointure (et encouragent plutôt la dénormalisation) et fournissent toutes deux des index sur les éléments suivants documents o rangées bien que les index de MongoDB soient actuellement plus flexibles.

Le moteur de stockage de Cassandra assure des écritures en 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 les b-trees, mais surtout à cause de l'utilisation de l'outil de gestion des données. verrouillage multi-granularité il le fait.

Pour l'analyse, MongoDB fournit une implémentation map/reduce personnalisée ; Cassandra fournit un support Hadoop natif, notamment pour Ruche (un entrepôt de données SQL construit sur Hadoop map/reduce) et Cochon (un langage d'analyse spécifique à Hadoop, dont beaucoup pensent qu'il est mieux adapté aux charges de travail de type map/reduce que SQL). Cassandra prend également en charge l'utilisation de Étincelle .

Pas d'inquiétude quant à l'évolutivité "massive".

Si vous envisagez un seul serveur, MongoDB est probablement plus adapté. Pour ceux qui sont plus préoccupés par l'évolutivité, l'architecture sans point de défaillance unique de Cassandra sera plus facile à mettre en place et plus fiable. (Cassandra offre également un meilleur contrôle sur le fonctionnement de la réplication, notamment la prise en charge de plusieurs centres de données.

Plus préoccupé par la simplicité de la configuration, de la maintenance et du code

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

Si vous utilisez actuellement des blobs JSON, MongoDB convient parfaitement à votre cas d'utilisation, étant donné qu'il utilise BSON pour stocker les données. Vous pourrez disposer de données plus riches et plus faciles à interroger que dans votre base de données actuelle. Ce serait la victoire la plus importante pour Mongo.

Answer 2

J'ai utilisé MongoDB de manière intensive (au cours des 6 derniers mois), en construisant un système de gestion de données hiérarchiques, et je peux me porter garant à la fois de la facilité de configuration (installez-le, exécutez-le, utilisez-le !) et de la vitesse. Tant que vous pensez aux index avec soin, il peut absolument hurler, en termes de vitesse.

J'en déduis que Cassandra, en raison de son utilisation dans des projets à grande échelle comme Twitter, dispose d'une meilleure fonctionnalité de mise à l'échelle, bien que l'équipe MongoDB travaille sur la parité dans ce domaine. Je dois préciser que je n'ai pas utilisé Cassandra au-delà de la phase d'essai et que je ne peux donc pas me prononcer sur les détails.

Pour moi, lorsque nous avons évalué les bases de données NoSQL, le vrai changement a été l'interrogation - Cassandra est essentiellement un magasin clé/valeur géant, et l'interrogation est un peu compliquée (du moins par rapport à MongoDB), donc pour obtenir des performances, vous devez dupliquer un grand nombre de données comme une sorte d'index manuel. MongoDB, quant à lui, utilise un modèle de "requête par exemple".

Par exemple, disons que vous avez une collection (l'équivalent d'une table RDMS en langage MongoDB) contenant des utilisateurs. MongoDB stocke les enregistrements sous forme de documents, qui sont en fait des objets binaires JSON, par exemple

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

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

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

...et ensuite exécuter la requête. C'est tout. Il existe des opérateurs supplémentaires pour les comparaisons, le filtrage RegEx, etc., mais tout cela est assez simple, et la documentation basée sur le Wiki est assez bonne.

Answer 3

Pourquoi choisir entre une base de données traditionnelle et un magasin de données NoSQL ? Utilisez les deux ! Le problème des solutions NoSQL (au-delà de la courbe d'apprentissage initiale) est l'absence de transactions. Vous effectuez toutes les mises à jour sur MySQL et faites en sorte que MySQL alimente un magasin de données NoSQL pour les lectures ; vous bénéficiez ainsi des points forts de chaque technologie. Cela ajoute de la complexité, mais vous avez déjà le côté MySQL - il suffit d'ajouter MongoDB, Cassandra, etc. au mélange.

Les datastores NoSQL évoluent généralement bien mieux qu'une base de données traditionnelle pour les mêmes spécifications. Ce n'est pas pour rien que Facebook, Twitter, Google et la plupart des start-ups utilisent des solutions NoSQL. Il n'y a pas que les geeks qui se défoulent sur les nouvelles technologies.

Answer 4

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

Une astuce courante chez les ingénieurs Web consiste à essayer d'utiliser davantage de NoSQL dès que l'on se rend compte que toutes les fonctionnalités d'un SGBDR ne sont pas utilisées. Ce n'est pas une bonne raison en soi, car la plupart des bases de données NoSQL ont des moteurs de données (ce que MySQL appelle un moteur de stockage) plutôt médiocres.

Maintenant, si vous n'êtes pas de ce genre, alors s'il vous plaît spécifiez ce qui est manquant dans MySQL et que vous recherchez dans une autre base de données (comme l'auto-sharding, le basculement automatique, la réplication multi-maître, une garantie de cohérence des données plus faible dans le cluster se traduisant par un débit d'écriture plus élevé, etc.)

Answer 5

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

Si vous recherchez une installation simple, c'est ce qu'il vous faut : Il vous suffit de dérégler MongoDB et de lancer le démon mongod et c'est tout... c'est en marche.

Bien sûr, ce n'est qu'un début, mais pour commencer, c'est facile.