MongoDB vs. Cassandra [fermé]

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

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.

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: "[email protected]",
   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.

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.

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.).

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.

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.