Question MongoDB vs. Cassandra [fermé]


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

Actuellement, je suis sur une partition MySQL (partition horizontale), avec la plupart de mes données stockées dans des blobs JSON. Je n'ai aucune requête SQL complexe (déjà migrée après que j'ai partitionné ma base de données).

En ce moment, il semble que MongoDB et Cassandra seraient des options possibles. Ma situation:

  • Beaucoup de lectures dans chaque requête, écrit moins régulièrement
  • Pas inquiet de l'évolutivité "massive"
  • Plus préoccupé par la configuration simple, la maintenance et le code
  • Réduire le coût du matériel / serveur

673
2018-05-23 17:39


origine


Réponses:


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 correspond à la mémoire. Tous deux mettent également l'accent sur des modèles de données sans jointure (et encouragent la dénormalisation à la place), et tous deux fournissent des index sur des documents ou rangées, 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 jeu 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 par verrouillage d'écriture de base de données.

Pour l'analyse, MongoDB fournit une carte personnalisée / réduit la mise en œuvre; Cassandra fournit un support natif Hadoop, y compris pour Ruche (un entrepôt de données SQL construit sur Hadoop map / reduce) et Porc (un langage d'analyse spécifique à Hadoop que beaucoup pensent être un meilleur ajustement pour les charges de travail map / reduce que SQL).

Pas inquiet de l'évolutivité "massive"

Si vous regardez un seul serveur, MongoDB est probablement un meilleur ajustement. Pour ceux qui sont plus préoccupés par la mise à l'échelle, l'architecture de Cassandra sans point unique de défaillance sera plus facile à configurer et plus fiable. (Le verrouillage d'écriture global de MongoDB a tendance à devenir plus douloureux, aussi.) 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 simple, la maintenance et le code

Les deux sont triviaux à configurer, avec des valeurs par défaut raisonnables pour un seul serveur. Cassandra est plus simple à configurer dans une configuration multi-serveur car il n'y a pas de nœuds à rôle particulier à craindre; voici un screencast démontrant la mise en place d'un cluster Cassandra à 4 nœuds en deux minutes.

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 serez en mesure d'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 significative pour Mongo.


525
2018-05-24 03:58



J'ai beaucoup utilisé MongoDB (depuis 6 mois), en construisant un système de gestion de données hiérarchique, et je peux garantir à la fois la facilité d'installation (l'installer, l'exécuter, l'utiliser!) Et la vitesse. Tant que vous pensez aux index avec soin, il peut tout à fait hurler, en vitesse.

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

Le vrai swinger pour moi, quand nous évaluions les bases de données NoSQL, était l'interrogation - Cassandra est simplement un magasin de clé / valeur géant, et l'interrogation est un peu fastidieuse (au moins par rapport à MongoDB), donc pour la performance, dupliquer beaucoup de données comme une sorte d'index manuel. MongoDB, d'un autre côté, utilise un modèle de "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 en tant que 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 Admin, vous créeriez simplement un nouveau document (à 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 tout. Il y a des opérateurs ajoutés pour les comparaisons, le filtrage RegEx, etc., mais tout est plutôt simple, et la documentation basée sur Wiki est plutôt bonne.


137
2017-07-01 22:29



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 l'absence de transactions - vous faites toutes les mises à jour de MySQL et que MySQL alimente un magasin de données NoSQL pour les lectures - vous bénéficiez ainsi des atouts de chaque technologie. Cela ajoute plus de complexité, mais vous avez déjà le côté MySQL - il suffit d'ajouter MongoDB, Cassandra, etc pour le mélange.

Les datastores NoSQL sont généralement plus performants que les DB traditionnels pour les mêmes spécifications - 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 mettent à la fine pointe de la technologie.


97
2018-04-17 00:45



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 backend de stockage, même pour les données blob / json.

Il y a un truc commun parmi les ingénieurs Web pour essayer d'utiliser plus de NoSQL dès que la réalisation vient que toutes les fonctionnalités d'un SGBDR ne sont pas utilisées. Ce 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 genre, alors s'il vous plaît spécifier ce qui est disparu dans MySQL et que vous cherchez dans une base de données différente (comme, auto-partitionnement, basculement automatique, réplication multi-maître, une garantie de cohérence des données plus faible dans le cluster de payer en débit d'écriture plus élevé, etc).


55
2018-02-23 20:50



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

Si votre installation après simple, c'est tout. Vous démontez simplement MongoDB et lancez le démon mongod et c'est tout. C'est en cours d'exécution.

Évidemment, ce n'est qu'une entrée, mais pour commencer, c'est facile.


18
2018-05-23 17:57



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

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

Je pense que dans ce cas, à la fin de la journée, il apparaîtra à qui vous vous sentez plus à l'aise et qui a un jeu 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 n'y avait pas beaucoup (ils ont dit vraiment) d'outils similaires à ce qui est disponible pour MySQL. C'était bien sûr leur expérience donc YMMV. Une chose que j'ai aimée à 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 impressionnant, et je sais que Twitter est passé à l'utilisation de cassandra.


12
2018-05-23 17:57