Lisez quelques articles sur le net concernant les performances en lecture/écriture de MongoDB et Cassandra,
Écrire à
On dit généralement que les performances en écriture de Cassandra sont meilleures que celles de Mongo lorsque les données sont volumineuses. Voir la déclaration ci-dessous.
Le moteur de stockage de Cassandra fournit des écritures en temps constant, quelle que soit la vitesse à laquelle les données sont écrites. 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 surtout à cause de le verrouillage d'écriture par base de données.
Voici ma question :- Cette affirmation est-elle toujours correcte ? D'après ce que j'ai compris, Mongo prend en charge le verrouillage par document et non par base de données. N'est-ce pas ? Donc, à l'heure actuelle, Cassandra est-il toujours meilleur que Mongo en termes de performances d'écriture ? Si oui, pourquoi ?
Lire
On dit généralement que les performances de lecture de Mongo sont meilleures que celles de Cassandra, mais je n'ai pas trouvé de raisonnement expliquant pourquoi la lecture de Mongo est meilleure que celle de Cassandra ?
Mise à jour :-
De la réponse de Jared à ce forum
Les lectures sont plus efficaces dans le moteur de stockage de MongoDB qu'elles ne le sont dans le moteur de stockage de l'entreprise. Cassandra. Le moteur de stockage de Cassandra est très performant en écriture car il stocke les données dans un format d'ajout uniquement. Cela permet d'utiliser des lecteurs de disques rotatifs qui ont des temps de recherche médiocres, mais peuvent effectuer des très rapidement. Mais l'inconvénient est que lorsque vous faites une lecture, vous vous devez souvent parcourir plusieurs versions d'un objet pour obtenir la pour obtenir la version la plus récente à renvoyer à l'appelant. MongoDB met à jour les données en place. Cela signifie qu'il fait plus d'entrées-sorties aléatoires lorsque les écritures sont traitées, mais il a l'avantage d'être plus rapide lors du traitement des lectures, car puisque vous pouvez trouver l'emplacement exact de l'objet sur le disque en une seule recherche.
Cela m'a permis de comprendre que Cassandra est plus rapide pour la suppression/modification d'un enregistrement existant, car il lui suffit de l'ajouter en dernier lieu au lieu de le modifier sur place comme Mongo, qui doit d'abord effectuer une recherche avant de modifier l'enregistrement. Cela rend Cassandra meilleur en écriture que Mongo.
Mais la même chose rend Mongo plus lent que Cassandra, car Cassandra doit parcourir plusieurs versions d'un même enregistrement pour obtenir la version la plus récente à renvoyer à l'appelant.
Une autre raison de ce blog pourquoi cassandra est meilleur en écriture
MongoDB, avec son modèle "single master", ne peut prendre en charge les écritures que sur le primaire. Les serveurs secondaires ne peuvent être utilisés que pour les lectures. Donc donc essentiellement si vous avez un ensemble de répliques à trois nœuds, seul le maître prend les écritures et les deux autres nœuds ne sont utilisés que pour les lectures. Ce site limite grandement l'extensibilité en écriture. Vous pouvez déployer plusieurs shards mais mais essentiellement seulement 1/3 de vos nœuds de données peuvent prendre des écritures. Cassandra avec son modèle à " maîtres multiples " peut accepter des écritures sur n'importe quel serveur. Essentiellement, l'extensibilité en écriture est limitée par le nombre de serveurs que vous avez dans le cluster. Plus il y a de serveurs dans le cluster, plus l'évolutivité sera grande. plus il sera évolutif.
De la même blog pourquoi Mongo est meilleur en lecture que cassandra
Les index secondaires sont une construction de première classe dans MongoDB. Cela permet d'indexer facilement n'importe quelle propriété d'un objet stocké dans MongoDB même si même s'il est imbriqué. Il est alors très facile d'effectuer des requêtes basées sur ces index secondaires. Cassandra n'offre qu'une prise en charge superficielle des secondaires. Les index secondaires sont également limités à des colonnes uniques et à des comparaisons d'égalité. Si vous effectuez principalement des requêtes sur la clé primaire clé primaire, Cassandra vous conviendra parfaitement.