Il y a eu beaucoup de discussions concernant Cassandra dernièrement.
Twitter, Digg, Facebook, etc. l'utilisent tous.
Quand cela a-t-il un sens de :
Lorsque vous évaluez des systèmes de données distribués, vous devez tenir compte du théorème CAP - vous pouvez choisir deux des éléments suivants : cohérence, disponibilité et tolérance de partition.
Cassandra est un système disponible, tolérant aux partitions et prenant en charge la cohérence éventuelle. Pour plus d'informations, voir ce billet de blog que j'ai écrit : Guide visuel des systèmes NoSQL .
A quand remonte la dernière fois que vous avez vu une partition où les deux partitions étaient grandes ? Voir ma question stackoverflow.com/questions/7969874/
Cassandra est la réponse à un problème particulier : que faites-vous lorsque vous avez tellement de données qu'elles ne tiennent pas sur un seul serveur ? Comment stocker toutes vos données sur plusieurs serveurs sans crever votre compte en banque et sans rendre vos développeurs fous ? Facebook reçoit 4 téraoctets de nouvelles données compressées CHAQUE JOUR. Et ce chiffre va très probablement doubler en l'espace d'un an.
Si vous ne disposez pas d'autant de données ou si vous avez des millions à payer pour l'installation d'un cluster Oracle/DB2 d'entreprise et les spécialistes nécessaires à sa mise en place et à sa maintenance, alors vous pouvez vous contenter d'une base de données SQL.
Cependant, Facebook n'utilise plus Cassandra et utilise désormais presque exclusivement MySQL, déplaçant le partitionnement vers le haut de la pile d'applications pour des performances plus rapides et un meilleur contrôle.
Savez-vous pourquoi FB a cessé d'utiliser Cassandra ? Que voulez-vous dire par "déplacer le partitionnement vers le haut de la pile d'applications" ? Est-ce que FB utilise plusieurs tables MySQL et décide laquelle utiliser pour un ensemble de données en utilisant une logique d'application ?
L'idée générale de NoSQL est que vous devriez utiliser le magasin de données le mieux adapté à votre application. Si vous avez un tableau de données financières, utilisez SQL. Si vous avez des objets dont la mise en correspondance avec un schéma relationnel nécessiterait des requêtes complexes et lentes, utilisez un magasin d'objets ou de clés/valeurs.
Bien entendu, la plupart des problèmes que vous rencontrez dans le monde réel se situent entre ces deux extrêmes et aucune solution ne sera parfaite. Vous devez prendre en compte les capacités de chaque magasin et les conséquences de l'utilisation de l'un plutôt que de l'autre, qui seront très spécifiques au problème que vous essayez de résoudre.
Il est peu probable que le schéma change, il s'intègre bien dans une structure de table, et des données perdues/inconsistantes pourraient causer de réels problèmes.
Je ne comprends pas pourquoi des données incohérentes peuvent causer de réels problèmes aux banques. Scénario : vous avez un compte bancaire, sur lequel vous avez versé 100 $ au-dessus de la limite fixée, et deux cartes bancaires. Lorsque vous essayez de retirer de l'argent avec les deux cartes en même temps à deux distributeurs automatiques différents, vous recevez deux fois 100 $ et une lettre avec des frais supplémentaires dans votre boîte aux lettres. La banque gagne de l'argent (les frais supplémentaires pour être en dessous de la limite) en utilisant des données incohérentes. Il est trop difficile de connecter tous les distributeurs automatiques de billets du monde les uns aux autres par le biais d'une grande base de données relationnelle. Pouvez-vous donner un exemple où des données financières incohérentes peuvent être un problème ?
Une seule requête lourde contre des milliards de requêtes légères La charge est un autre point à considérer, en plus des autres réponses ici. Il est intrinsèquement plus difficile d'optimiser automatiquement une requête unique dans une base de données de type NoSql. J'ai utilisé MongoDB et j'ai rencontré des problèmes de performance en essayant de calculer une requête complexe. Je n'ai pas utilisé Cassandra mais je m'attends à ce qu'il ait le même problème.
D'un autre côté, si vous prévoyez que votre charge sera constituée d'un grand nombre de petites requêtes, et que vous voulez être en mesure d'évoluer facilement, vous pouvez tirer parti de la cohérence éventuelle offerte par la plupart des bases de données NoSql. Notez que la cohérence éventuelle n'est pas vraiment une caractéristique d'un modèle de données non relationnel, mais elle est beaucoup plus facile à mettre en œuvre et à configurer dans un système basé sur NoSql.
Pour une seule requête très lourde, n'importe quel moteur de SGBDR moderne peut faire un travail décent de parallélisation de certaines parties de la requête et tirer parti d'autant de CPU et de mémoire que vous lui donnez (sur une seule machine). Les bases de données NoSql ne disposent pas de suffisamment d'informations sur la structure des données pour être en mesure de faire des hypothèses qui permettront une parallélisation vraiment intelligente d'une grande requête. Elles vous permettent d'augmenter facilement le nombre de serveurs (ou de cœurs), mais dès que la requête atteint un certain niveau de complexité, vous êtes obligé de la diviser manuellement en parties que le moteur NoSql sait traiter intelligemment.
D'après mon expérience avec MongoDB, en raison de la complexité de la requête, Mongo ne pouvait pas faire grand-chose pour l'optimiser et en exécuter certaines parties sur plusieurs données. Mongo parallélise les requêtes multiples mais n'est pas très doué pour en optimiser un seul.
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.
7 votes
Il devrait probablement être CW ? Il s'agit essentiellement de bases de données NoSQL contre bases de données relationnelles, ce qui est assez subjectif.
3 votes
J'aimerais savoir s'il convient au système de messagerie. Je suppose que si Twitter l'utilise, il n'y a pas de problème, mais il se peut qu'ils ne l'utilisent pas pour l'ensemble de Twitter ?
0 votes
techblog.bozho.net/?p=232