Je suis nouveau dans l'apprentissage des systèmes distribués et j'ai lu sur le théorème CAP, je suis intéressé par un système AP tel que Cassandra.
Ma question est dans quels cas pouvez-vous réellement sacrifier la cohérence? En fait, ce que je veux dire, c'est que sacrifier la cohérence signifie fournir des données inexactes . Dans quels cas utiliseriez-vous alors une banque de données AP comme Cassandra? Je ne peux penser à aucun cas où je ne voudrais pas que mes lectures soient cohérentes.
5 Réponses :
Par système AP, je suppose que vous viserez au moins pour assurer une cohérence éventuelle.
Imaginez que vous développez un réseau social où les utilisateurs ont des amis et leurs propres fils d'actualité. Peu importe si le flux d'un utilisateur particulier a parfois un décalage de cinq minutes (sa liste de flux a une cohérence éventuelle). Les 2/3 des mises à jour très récentes manquantes dans le fil d'actualités sont acceptables dans ce scénario tant que ces fils apparaîtront éventuellement. Et en fait, Facebook a construit son fil d'actualité en utilisant Cassandra.
Imaginez un système de cache de stockage de clés-valeurs distribué où la mise à jour est très rare. S'il n'y a pratiquement pas d'opérations de mise à jour, il n'est pas nécessaire de garantir une cohérence forte, vous pouvez donc vous concentrer sur la disponibilité. Occasionnellement manque de cache (l'entrée clé-valeur n'est pas encore renseignée) et une requête à la base de données en raison d'une éventuelle cohérence devrait être acceptable.
Ma question est de savoir dans quels cas pouvez-vous réellement sacrifier la cohérence?
Un cas serait celui de la création d'un ensemble de données de moteur de recommandation et de sa diffusion avec Cassandra. Ces ensembles de données sont essentiellement l'agrégation de très nombreux utilisateurs pour déterminer les modèles d'achat / d'affichage.
Par exemple: si j'ajoute une figurine articulée de Rey Star Wars à mon panier, le moteur de recommandation sous-jacent exécute une requête pour des modèles d'achat similaires résultants en fonction d'autres personnes qui ont également acheté une figurine articulée de Rey. La requête renvoie les 5 premiers résultats produits et les place au bas de la page.
Ces 5 produits retournés sont le résultat de l'analyse et de l'agrégation de plusieurs milliers d'achats antérieurs. Supposons que certaines de ces données ne soient pas cohérentes, ce qui entraîne une variance dans les 5 produits retournés. Est-ce vraiment un gros problème?
tl; dr; La vraie question à poser; Est-ce qu'il vaut mieux obtenir une liste assez précise de 5 recommandations de produits en moins de 10 ms que d'obtenir une liste précise à 100% de 5 recommandations de produits en 100 ms?
Les deux ensembles de résultats contribueront à stimuler les ventes. Mais celui qui est renvoyé assez rapidement pour ne pas gêner l'expérience utilisateur est beaucoup plus préféré.
«C» dans CAP fait référence à la linéarisation qui est une forme très forte de cohérence dont vous n'avez pas besoin la plupart du temps.
La linéarisation est une garantie de récence qui donne l'impression qu'il n'y a qu'une seule copie des données. Dès que vous modifiez les données, toutes les lectures suivantes renverront les données modifiées. Un tel niveau de cohérence est coûteux et ne s'adapte pas bien. Pourtant, dans certains scénarios, nous avons besoin de linéarisation, à savoir.
Lorsque vous avez ces cas d'utilisation, vous utilisez quelque chose comme ZooKeeper, etc. Cette fonctionnalité peut être utilisée pour résoudre les rares cas d'utilisation où vous devez avoir la linéarisation et la sérialisabilité, mais elle est coûteuse. Et dans la grande majorité des cas, vous êtes très bien avec une cohérence un peu plus faible pour obtenir une meilleure évolutivité et des performances. Vous échangez un peu de cohérence avec l'évolutivité et les performances.
Certains sites Web de commerce électronique envoient une lettre d'excuses aux clients pour ne pas être en mesure de traiter leurs commandes. En effet, la dernière copie du produit a été vendue à plus d'un client en raison du manque et de la linéarisation. Ils préfèrent gérer cela plutôt que de ne pas pouvoir évoluer avec la clientèle et de ne pas pouvoir répondre à leurs demandes dans le cadre de SLA stricts.
On dit que Cassandra a une cohérence accordable. Vous souhaiterez peut-être enregistrer les clics ou les activités des utilisateurs pour analyse. Vous êtes d'accord si certaines données sont perdues, mais vous ne pouvez pas compromettre les performances. Vous utiliseriez probablement un niveau de cohérence d'écriture de ANY avec les conseils activés (quorum bâclé).
Si vous voulez un peu plus de cohérence, vous utiliserez un niveau de cohérence QUORUM pour lire et écrire avec des conseils et lire la réparation. Dans la grande majorité des cas, tous les nœuds sont mis à jour instantanément. Même si un ou deux nœuds tombent en panne, la majorité des nœuds auront les données et les nœuds défaillants seront réparés à leur retour en utilisant des indices, une réparation de lecture, une réparation anti-entropie.
Cassandra est particulièrement utile dans les cas où vous n'avez pas beaucoup de mises à jour simultanées sur les mêmes données. La raison en est que, contrairement à l'architecture dynamo, elle n'utilise pas d'horloges vectorielles pour la résolution des conflits entre les répliques. Au lieu de cela, il utilise Last Write Wins (LWW) basé sur l'horodatage. Si les horodatages sont identiques, il utilise l'ordre lexicographique. Étant donné que l'heure sur les nœuds ne peut pas être précise même en présence de NTPD, il existe une possibilité de perte de données, bien que Cassandra ait pris certaines mesures pour éviter cela - par exemple. horodatage côté client au lieu de l'horodatage côté serveur.
Le théorème CAP dit que, étant donné la tolérance de partition, vous pouvez choisir la disponibilité ou la cohérence dans une base de données distribuée (personne ne voudrait renoncer à la tolérance de partition dans tous les cas). Donc, si vous voulez avoir une disponibilité maximale, vous devrez renoncer à la cohérence. Cela dépend bien sûr de l'importance de l'entreprise.
Vous avez répondu à quelque chose sur SO mais la réponse n'apparaît pas lorsque vous visitez la page? Peut être toléré. SO être en panne? Ça ne peut pas être. Les systèmes financiers critiques préfèrent une forte cohérence plutôt que la disponibilité. De temps en temps, les serveurs de ma banque se déconnectaient lorsque j'essayais d'effectuer un paiement.
Normalement, vous choisissez la disponibilité et la cohérence éventuelle. La réponse que vous avez écrite dans SO finirait par apparaître.
Outre les cas mentionnés ci-dessus où des données incohérentes sont tolérables, il existe également des scénarios dans lesquels nous pouvons nous en remettre à l'utilisateur pour résoudre l'incohérence.
Par exemple, si nous avons trouvé deux versions différentes de l'adresse d'une personne dans la base de données, nous pouvons inviter l'utilisateur à identifier la bonne adresse.
Qu'a montré votre recherche? La question de savoir comment «incohérent» peut être souhaitable est clairement une question en double - vous vous demandez la raison d'être d'une classe de produit / système. Comment l'introduction à une "banque de données AP comme Cassandra" ne répond-elle pas à votre question? Voir Comment demander et les textes de la flèche de vote. PS Engineering fait des compromis. Si «exact» vous coûte constamment du débit, peut-être préféreriez-vous «fermer» - «assez près». PS CAP comme critère de catégorisation du système est obsolète .
@philipxy tandis que le Dr Kleppmann fait quelques bons points sur les défauts et la surutilisation des définitions de CAP, une «diatribe» autoproclamée d'un seul chercheur ne peut guère être qualifiée de «dépréciation». Il reste un outil utile pour décrire les différences de haut niveau de ces types de bases de données aux nouveaux utilisateurs.