MongoDB contre Cassandra
J'évalue quelle pourrait être la meilleure option de migration.
Actuellement, je suis sur une partition MySQL fragmentée, 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é après avoir partitionné ma base de données).
À l'heure actuelle, il semble que MongoDB et Cassandra seraient des options probables. Ma situation:
- Beaucoup de lectures dans chaque requête, écrit moins régulier
- Pas inquiet de l'évolutivité "massive"
- Plus soucieux de la simplicité d'installation, de maintenance et de code
- Minimiser 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ù le jeu de données actif est stocké 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 documents ou 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 le b-tree, mais davantage à cause du verrouillage multi-granularité c'est le cas.
Pour les analyses, MongoDB fournit une implémentation personnalisée de la carte/réduction; Cassandra fournit une prise en charge native de Hadoop, y compris pour Hive (un entrepôt de données SQL construit sur Hadoop map/reduction) et Pig (un langage d'analyse spécifique à Hadoop que beaucoup considèrent comme une meilleure solution. adapter pour mapper/réduire les charges de travail que SQL). Cassandra prend également en charge l'utilisation de Spark .
Pas de souci d'évolutivité "massive"
Si vous envisagez un seul serveur, MongoDB est probablement un meilleur choix. Pour ceux qui sont plus préoccupés par la mise à l'échelle, l'architecture de Cassandra sans point unique est plus facile à configurer et plus fiable. (Le verrouillage en écriture global de MongoDB tend également à devenir plus douloureux.) 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 soucieux de la simplicité d'installation, de maintenance et de code
Les deux sont simples à configurer, avec des valeurs par défaut raisonnables et prêtes à l'emploi pour un seul serveur. Cassandra est plus simple à configurer dans une configuration à plusieurs serveurs car il n'y a pas de nœuds à rôles spéciaux à prendre en compte.
Si vous utilisez actuellement des blobs JSON, MongoDB convient parfaitement à votre cas d'utilisation, car il utilise BSON pour stocker les données. Vous pourrez disposer de données plus riches et interrogeables que dans votre base de données actuelle. Ce serait la victoire la plus importante pour Mongo.
J'ai beaucoup utilisé MongoDB (au cours des six derniers mois) pour créer 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 sa rapidité. Tant que vous réfléchissez bien aux index, il peut absolument crier, vitesse.
Je suppose que Cassandra, en raison de son utilisation avec des projets à grande échelle tels que Twitter, a une meilleure fonctionnalité de dimensionnement, bien que l’équipe de MongoDB travaille sur la parité. Je dois signaler que je n'ai pas utilisé Cassandra au-delà de la phase d'essai, je ne peux donc pas parler pour le détail.
L’interrogation a été mon problème principal lorsque nous évaluions des bases de données NoSQL: Cassandra n’est en fait qu’un magasin de clés/valeurs géant, et l’interrogation est un peu fastidieuse dupliquer pas mal de données sous forme d’index manuel. MongoDB, quant à lui, utilise un modèle "requête par exemple".
Par exemple, supposons que vous ayez une collection (jargon MongoDB correspondant à 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 souhaitez rechercher tous les utilisateurs nommés Smith disposant de droits d'administrateur, vous devez simplement créer un nouveau document (sur la console d'administration à l'aide de JavaScript ou en production avec le langage de votre choix):
{
LastName: "Smith",
Groups: "Admin"
}
... puis lancez la requête. C'est tout. Il y a des opérateurs ajoutés pour les comparaisons, le filtrage RegEx, etc., mais c'est assez simple, et la documentation basée sur Wiki est très bonne.
Pourquoi choisir entre une base de données traditionnelle et un magasin de données NoSQL? Utilise les deux! Le problème des solutions NoSQL (au-delà de la courbe d'apprentissage initiale) est le manque de transactions - vous effectuez toutes les mises à jour de MySQL et laissez MySQL remplir un magasin de données NoSQL pour les lectures - vous bénéficiez des avantages de chaque technologie. Cela ajoute encore à la complexité, mais vous avez déjà le côté MySQL - ajoutez simplement MongoDB, Cassandra, etc. au mélange.
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 nouvelles entreprises utilisent les solutions NoSQL. Il n’ya pas que les geeks qui s’attachent aux nouvelles technologies.
Je vais probablement être un homme étrange, mais je pense que vous devez rester avec MySQL. Vous n'avez pas décrit de problème réel à résoudre, et MySQL/InnoDB est un excellent back-end de stockage, même pour les données blob/json.
Il est courant que les ingénieurs Web essaient d’utiliser plus de NoSQL dès que l’on se rend compte que toutes les fonctionnalités d’un SGBDR ne sont pas utilisées. Cela n'est pas une bonne raison, car les bases de données NoSQL ont le plus souvent 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 est manquant dans MySQL et que vous recherchez dans une base de données différente (comme le partage automatique, le basculement automatique, la réplication multi-maîtres). , une garantie de cohérence des données plus faible dans les clusters payant en débit d’écriture supérieur, 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, voici ce que vous voudrez: Déconnectez simplement MongoDB et exécutez le démon mongod et le tour est joué.
Évidemment, ce n'est qu'une entrée, 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écompresser et de la mettre à feu. Terminé.
Je pense que mongodb et cassandra fonctionneront sur pratiquement tout le matériel Linux classique, vous ne devriez donc pas trouver trop d'obstacles dans ce domaine.
Je pense que dans ce cas, à la fin de la journée, il faudra déterminer avec quoi vous sentez-vous 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 n’existait pas beaucoup d’outils similaires à ceux disponibles pour MySQL. C'était bien sûr leur expérience si YMMV. Une des choses que j’ai aimées chez mongodb, c’est qu’il semblait supporter de nombreux langages (python et .NET étant les deux que j’utilise principalement).
La liste des sites utilisant mongodb est jolie impressionnante , et je sais que Twitter vient de passer à l'utilisation de cassandra.