Introduction

Il existe un théorème bien connu en informatique proposé par Eric Brewer qui dit que pour une base de données avec des données distribuées, vous ne pouvez promettre que deux des trois qualités suivantes:

• Cohérence
• Disponibilité
• Tolérance de partition

C’est très abstrait et la terminologie n’est pas exactement intuitive, donc dans cet article, nous ferons de notre mieux pour décomposer cette théorie de l’abstrait à des discussions et des exemples plus réels. Ce théorème peut vous faire réfléchir à votre architecture de base de données en fonction de ce dont votre application a vraiment besoin et des sacrifices qu’elle pourrait devoir faire pour y parvenir.

Définition de la terminologie de la PAC

Dégageons quelques définitions de base afin que nous puissions être sur la même longueur d’onde que nous avançons en parlant de ce théorème.

CAP – Cohérence, Disponibilité, Tolérance de partition

• Cohérence – Tous vos serveurs de données ont les mêmes données, vous pouvez donc interroger n’importe quel serveur du système et obtenir exactement les mêmes données.
• Disponibilité – Chaque requête adressée aux serveurs de données reçoit une réponse. Si un serveur est occupé, il est routé vers un autre qui est capable de répondre.
• Tolérance de partition – La possibilité pour le système de continuer à fonctionner même s’il y a des pannes de réseau et que certains serveurs ne peuvent pas communiquer.

L’hypothèse sous–jacente -P est impossible

Dans un système de base de données distribuée, vos données sont réparties sur différents serveurs et ces serveurs se parlent sur un réseau afin qu’ils puissent maintenir le même ensemble de données. Le problème est que les réseaux se cassent et nous supposons donc qu’il communiquera toujours, c’est-à-dire que nous ne pouvons pas avoir un réseau parfait. En termes de cette théorie, cela signifie que dans le monde réel, vous devez sacrifier la tolérance de partition. Si le réseau parfait et sans faille existait, nous n’aurions aucun problème à atteindre la cohérence et la disponibilité, mais c’est le monde réel construit sur des fils physiques qui échouent et nous supposons donc qu’il échouera.

Si P est Impossible, Quels sont nos Choix ?

Puisque nous avons renoncé à la tolérance de partition, le théorème dit que nous devons maintenant choisir entre la Cohérence et la disponibilité.

Vous pouvez choisir d’avoir une disponibilité où votre application peut satisfaire toutes les demandes entrantes mais elle NE PEUT PAS garantir que les données sont les plus récentes.

De quoi votre application a-t-elle besoin ?

Si votre application est un site de médias sociaux et n’a pas besoin d’avoir les données les plus récentes à tout moment, vous pouvez choisir la disponibilité. Est-ce important que vos utilisateurs voient un message après un délai de 30 secondes? Sinon, vous préférerez peut-être la disponibilité, car vous priorisez que vos utilisateurs puissent accéder aux données même s’il ne s’agit pas des données les plus à jour.

Si, d’un autre côté, votre application exige que chaque lecture de la base de données soit la donnée la plus récente absolue, vous devrez sacrifier la disponibilité et choisir la cohérence. Certaines demandes devront se tromper en raison de l’impossibilité de garantir que l’information est la plus récente absolue.

Les choix effectués par la technologie de base de données Relationnelle et NoSQL

comme SQL et d’autres systèmes de base de données relationnelles conçus avec ACID priorisent la cohérence. D’autre part, la plupart des bases de données NoSQL donnent la priorité à la disponibilité.

Conclusion

Nous pensons que l’examen de ce théorème en termes d’application est un excellent exercice et vous aide à évaluer les priorités de votre application. Si vous avez un système de données distribué, examinez votre architecture et comprenez quel sacrifice vous faites.

MongoDB, CockroachDB et Postgres sont aujourd’hui d’excellentes technologies de base de données qui rendent nos architectures de base de données extrêmement robustes, mais comme nous en avons discuté, elles ne sont pas parfaites. Nous n’avons pas de réseau parfait et il y a toujours une « erreur utilisateur ». Si vous vous déplacez vers un environnement de production et que vous souhaitez discuter des meilleures options pour votre application, n’hésitez pas à nous contacter chez Object Rocket.