7 votes

MongoDb vs Cassandra : les mythes de la lecture/écriture ?

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.

3voto

Alex M981 Points 1039

Réponses aux questions : Oui. La dernière version de MongoDB prend en charge les verrous par document. . https://docs.mongodb.com/manual/core/wiredtiger/

voici des repères pour les opérations d'écriture : https://www.datastax.com/nosql-databases/benchmarks-cassandra-vs-mongodb-vs-hbase Selon ces critères de référence cassandra est plus performant à l'échelle (sur un nombre plus élevé de nœuds dans le cluster)

J'espère que cela vous aidera.

Voici quelques détails concernant votre question qui pourraient également vous aider

Au sujet de Cassandra

Cassandra utilise LSM-tree qui est optimisé pour les écritures lourdes. https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/dml_manage_ondisk_c.html

Quelques détails

Lorsqu'on effectue une écriture, les données sont immédiatement écrites dans un journal de livraison. Ce journal est un mécanisme de récupération en cas de panne. Une écriture n'est pas considérée comme réussie tant qu'elle n'a pas été inscrite dans le journal de livraison. Une fois les données écrites dans le commit log, elles sont écrites dans memtable. Dans les versions récentes de Cassandra, les memtables sont principalement stockées dans la mémoire native et non dans le tas de la JVM. Cela améliore donc également les performances.

Lorsque le nombre d'objets stockés dans la table mémo atteint un certain seuil, le contenu de la table mémo est transféré sur le disque dans un fichier appelé SSTable. Un nouveau memtable est alors créé. Une fois qu'une memtable est vidée dans un SSTable, elle est immuable.

Aucune lecture ou recherche d'aucune sorte n'est nécessaire pour écrire une valeur dans Cassandra, car toutes les écritures sont des opérations d'ajout.

Concernant MongoDB

Par défaut, mongo utilise le moteur de stockage MMAPv1 qui utilise des arbres B ( https://docs.mongodb.com/manual/core/mmapv1/ ), mais les versions récentes de MongoDB utilisent le moteur de stockage de WiredTiger ( https://docs.mongodb.com/manual/core/wiredtiger/ ) qui peut également prendre en charge LSM-tree.

En ce qui concerne les serrures : WiredTiger MongoDB prend en charge les verrous au niveau du document mais MMAPv1 prend en charge le contrôle de la concurrence au niveau de la collection.

Quelques articles utiles : https://dba.stackexchange.com/questions/121160/mongodb-mmapv1-vs-wiredtiger-storage-engines https://docs.mongodb.com/manual/faq/concurrency/ https://www.percona.com/blog/2016/01/06/mongodb-revs-you-up-what-storage-engine-is-right-part-1/

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X