1. Théorème de CAP
1.1. Définition :
1.1.1. Le théorème de CAP stipule qu'il est impossible pour un système de gestion de bases de données distribué de garantir simultanément les trois propriétés suivantes :
1.2. Cohérence (Consistency) :
1.2.1. Tous les nœuds du système voient les mêmes données au même moment.
1.3. Disponibilité (Availability) :
1.3.1. Chaque demande reçoit une réponse, même si certaines données peuvent ne pas être à jour.
1.4. Tolérance au partitionnement (Partition Tolerance) :
1.4.1. Le système continue de fonctionner même en cas de perte de communication entre les nœuds.
1.5. Implication :
1.5.1. Dans un système distribué, on peut garantir au maximum deux des trois propriétés. Par exemple, un système peut être cohérent et disponible, mais pas tolérant aux partitions.
2. ACID
2.1. Définition :
2.1.1. ACID est un ensemble de propriétés garantissant que les transactions dans une base de données relationnelle sont traitées de manière fiable.
2.2. Atomicité (Atomicity) :
2.2.1. Une transaction est traitée comme une unité indivisible ; elle réussit ou échoue complètement.
2.3. Cohérence (Consistency) :
2.3.1. Les transactions amènent la base de données d'un état valide à un autre état valide.
2.4. Isolation (Isolation) :
2.4.1. Les transactions concurrentes ne doivent pas interférer les unes avec les autres.
2.5. Durabilité (Durability) :
2.5.1. Une fois qu'une transaction est validée, ses effets sont permanents, même en cas de panne système.
3. BASE
3.1. Définition :
3.1.1. BASE est un ensemble de propriétés souvent associé aux bases de données NoSQL, qui se concentre sur la disponibilité et la flexibilité plutôt que sur la cohérence stricte. Les propriétés sont :
3.2. Basically Available (Disponibilité) :
3.2.1. Le système garantit que les données sont disponibles, même en cas de défaillance.
3.3. Soft State (État temporaire) :
3.3.1. L'état de la base de données peut changer même sans nouvelles transactions, en raison de la réplication et des mises à jour asynchrones.
3.4. Eventually Consistent (Cohérence éventuelle) :
3.4.1. Les données finiront par être cohérentes, mais pas nécessairement à tout moment.
4. Definition
4.1. Systèmes de gestion de bases de données non relationnels.
4.2. Conçus pour gérer des volumes massifs de données.
4.3. Offrent flexibilité et scalabilité.
4.4. Offrent flexibilité et scalabilité.
4.5. Conçus pour gérer des volumes massifs de données.
4.6. Systèmes de gestion de bases de données non relationnels.
5. Comparer les bases de données traditionnelles et NoSQL
5.1. Bases relationnelles :
5.1.1. Schéma fixe : Les données doivent être organisées selon un schéma prédéfini, ce qui peut rendre les modifications difficiles. Transactions complexes : Idéales pour des applications nécessitant des transactions ACID (Atomicité, Cohérence, Isolation, Durabilité). Scalabilité verticale : Nécessite des serveurs plus puissants pour gérer l'augmentation des données, ce qui peut être coûteux.
5.2. Bases NoSQL :
5.2.1. Schéma flexible : Les données peuvent être ajoutées sans structure rigide, facilitant l'intégration de nouveaux types de données. Données non structurées : Excellentes pour gérer des données variées comme des documents, des images, ou des flux de données. Scalabilité horizontale : Permet d'ajouter facilement des serveurs pour gérer l'augmentation des données, ce qui est souvent plus économique.
6. les caractéristiques des NoSQL
6.1. Scalabilité horizontale :
6.1.1. Capacité à ajouter des serveurs pour gérer des volumes de données croissants sans perte de performance.
6.2. Schéma flexible :
6.2.1. Permet des modifications rapides et faciles des structures de données, adaptées aux besoins changeants.
6.3. Performance élevée :
6.3.1. Optimisées pour des opérations rapides, souvent en utilisant des techniques de mise en cache et d'indexation.
6.4. Types de données variés :
6.4.1. Supportent des données non structurées, semi-structurées et structurées, offrant une grande flexibilité.
7. Recenser les types de bases de données NoSQL
7.1. Documentaires :
7.1.1. Exemples : MongoDB, CouchDB. Stockent des données sous forme de documents (JSON, BSON). Idéales pour des applications nécessitant une structure de données flexible.
7.2. Clé-valeur :
7.2.1. Exemples : Redis, DynamoDB. Organisent les données en paires clé-valeur, permettant un accès rapide. Utilisées pour des applications nécessitant des performances élevées et un accès rapide aux données.
7.3. Colonnes :
7.3.1. Exemples : Cassandra, HBase. Stockent des données en colonnes plutôt qu'en lignes, optimisant les requêtes sur de grandes quantités de données. Excellentes pour les applications analytiques et les données massives.
7.4. Graphes :
7.4.1. Exemples : Neo4j, ArangoDB. Représentent des données sous forme de nœuds (entités) et d'arêtes (relations). Idéales pour des applications nécessitant une gestion complexe des relations, comme les réseaux sociaux.
8. Comparer les différents types de bases de données NoSQL
8.1. Colonnes
8.1.1. Avantages : Efficacité pour le traitement de grandes quantités de données, bonne performance pour les requêtes analytiques.
8.1.2. Inconvénients : Complexité accrue dans la modélisation des données.
8.2. Graphes
8.2.1. Avantages : Excellente gestion des relations, idéal pour les applications nécessitant des analyses de réseaux.
8.2.2. Inconvénients : Moins performant pour des requêtes simples, peut nécessiter une courbe d'apprentissage plus élevée.