Voici comment je discute de la PAC, en ce qui concerne P en particulier.
CA n'est possible que si vous êtes d'accord avec une base de données monolithique, à un seul serveur (peut-être avec une réplication, mais toutes les données sont sur un seul "bloc de défaillance" - les serveurs ne sont pas considérés comme pouvant tomber partiellement en panne).
Si votre problème nécessite une mise à l'échelle, une distribution et des serveurs multiples --- des partitions de réseau peuvent se produire. Vous avez déjà besoin de P. Peu de problèmes que j'aborde se prêtent à des paradigmes à serveur unique et permanent (ou, comme l'a dit Stonebraker, "distribué est un enjeu de table"). Si vous pouvez trouver un problème de CA, des solutions comme un SGBDR traditionnel sans échelle offrent beaucoup d'avantages.
Pour moi, c'est rare : nous passons donc à la discussion sur l'AP et le CP.
Vous ne pouvez choisir entre le fonctionnement AP et CP que lorsque vous avez une partition. Si le réseau et le matériel fonctionnent correctement, vous avez le beurre et l'argent du beurre.
Discutons de la distinction AP / CP.
AP - lorsqu'il y a une partition du réseau, laissez les parties indépendantes fonctionner librement.
CP - lorsqu'il y a une partition du réseau, arrêter les nœuds ou interdire les lectures et les écritures afin d'obtenir des défaillances déterministes.
J'aime les architectures qui peuvent faire les deux, car certains problèmes sont AP et d'autres CP - et certaines bases de données peuvent faire les deux. Parmi les solutions CP et AP, il y a aussi des subtilités.
Par exemple, dans un ensemble de données AP, vous avez la possibilité d'effectuer des lectures incohérentes et de générer des conflits d'écriture - ce sont deux modes AP différents. Votre système peut-il être configuré pour le mode AP avec une haute disponibilité en lecture, mais en interdisant les conflits d'écriture ? Ou votre système AP peut-il accepter les conflits d'écriture, avec un système de résolution fort et flexible ? Aurez-vous éventuellement besoin des deux, ou pouvez-vous choisir un système qui n'en fait qu'un ?
Dans un système de PC, quel degré d'indisponibilité obtenez-vous avec de petites partitions (un seul serveur), le cas échéant ? Une réplication plus importante peut augmenter l'indisponibilité dans un système CP, comment le système gère-t-il ces compromis ?
Ce sont toutes des questions à se poser avec CP vs AP.
L'article de Brewer intitulé "12 ans plus tard" est une excellente lecture dans ce domaine. Je pense qu'il fait avancer le débat sur la PAC avec clarté, et je le recommande vivement.
http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
1 votes
Voici un article qui explique la PAC en termes simples. ksat.me/a-plain-english-introduction-à-cap-theorem
3 votes
Ne vous laissez pas tenter par les réponses toutes faites. Lisez, visualisez et comprenez chaque C, A, P séparément. Concevez une architecture de cluster distribué (peut-être 3 DB) et appliquez maintenant votre compréhension. Voyez ce qui arrive à C, A, P quand les pannes des DB distribués se produisent. Une fois que vous avez compris, vérifiez les réponses et appliquez-les avec votre logique. Rappelez-vous - Même si vous comprenez, cela peut ne pas être clair. Donc, réfléchissez et appliquez votre compréhension. Merci
4 votes
D'une manière ou d'une autre, le lien ksat.me ci-dessus renvoie à une url 404 car il se termine par '/'. ksat.me/a-plain-english-introduction-à-cap-theorem Cela fonctionne bien et c'est une explication très détaillée de chacun des éléments 'C', 'A' et 'P'.