Par défaut, il est recommandé de n'autoriser que les machines nécessaires à se connecter à la base de données. Ne jamais exposer directement une base de données sur Internet sans protection.
### Cas particulier : SQLite **SQLite** est un SGBD qui se distingue radicalement des bases de données traditionnelles comme MySQL ou PostgreSQL. Contrairement à ces dernières, SQLite **n'utilise pas d'architecture client-serveur**. #### Une base de données embarquée SQLite fonctionne comme une **bibliothèque intégrée** directement dans l'application : - **Pas de serveur** : Aucun processus séparé à démarrer ou gérer - **Pas de port réseau** : Aucune configuration réseau nécessaire - **Pas d'authentification** : L'accès est contrôlé par les permissions du système de fichiers - **Un seul fichier** : Toute la base de données est stockée dans un fichier unique (ex: `ma_base.db`) #### Différences avec un SGBD traditionnel| Caractéristique | MySQL / PostgreSQL | SQLite |
|---|---|---|
| Architecture | Client-serveur | Embarquée (bibliothèque) |
| Processus serveur | Oui | Non |
| Port réseau | 3306 / 5432 | Aucun |
| Stockage | Répertoire dédié | Fichier unique |
| Accès concurrent | Multi-utilisateurs | Limité (verrouillage fichier) |
| Accès réseau | Oui (natif) | Non |
| Configuration | Complexe | Aucune |
SQLite est le moteur de base de données le plus déployé au monde. Il est intégré dans Android, iOS, tous les navigateurs web, et de nombreuses applications.
SQLite n'est **pas adapté** aux applications web à fort trafic ou nécessitant des accès concurrents multiples. Dans ces cas, privilégiez MySQL, MariaDB ou PostgreSQL.
### Déploiement avec Docker Les SGBD peuvent être facilement déployés via Docker, ce qui offre plusieurs avantages : - **Portabilité** : Même environnement en développement et production - **Isolation** : Chaque base de données dans son propre conteneur - **Simplicité** : Déploiement rapide sans installation complexe - **Versioning** : Contrôle précis de la version du SGBD #### Images Docker officielles Les SGBD relationnels majeurs disposent d'images officielles sur Docker Hub : - **MySQL** : [hub.docker.com/\_/mysql](https://hub.docker.com/_/mysql) - **MariaDB** : [hub.docker.com/\_/mariadb](https://hub.docker.com/_/mariadb) - **PostgreSQL** : [hub.docker.com/\_/postgres](https://hub.docker.com/_/postgres) Exemple de lancement d'une base MySQL avec Docker : ```bash docker run -d \ --name ma-base-mysql \ -e MYSQL_ROOT_PASSWORD=motdepasse \ -e MYSQL_DATABASE=ma_base \ -p 3306:3306 \ mysql:latest ``` #### Persistance des données Comme vu dans le cours Docker, les conteneurs sont volatiles. Pour persister les données de la base, il est **indispensable** d'utiliser des **volumes Docker**. Exemple avec un volume : ```bash docker run -d \ --name ma-base-mysql \ -e MYSQL_ROOT_PASSWORD=motdepasse \ -v mysql-data:/var/lib/mysql \ -p 3306:3306 \ mysql:latest ```Le volume `mysql-data` stocke les fichiers de la base de données. Même si le conteneur est supprimé, les données persistent.
### Le théorème de CAP Le **théorème de CAP** est un concept fondamental en architecture distribuée. Il stipule qu'un système de base de données distribuée ne peut garantir simultanément que **deux des trois propriétés** suivantes : - **C**onsistency (Cohérence) : Tous les nœuds voient les mêmes données au même moment - **A**vailability (Disponibilité) : Le système répond toujours, même en cas de panne partielle - **P**artition tolerance (Tolérance au partitionnement) : Le système continue de fonctionner même si des nœuds ne peuvent plus communiquer entre eux En pratique : - **Les SGBD relationnels** privilégient la **cohérence** (C) et la **disponibilité** (A), au détriment de la tolérance au partitionnement. Ils fonctionnent mieux dans un environnement centralisé. - **Les bases NoSQL** privilégient souvent la **disponibilité** (A) et la **tolérance au partitionnement** (P), acceptant une cohérence éventuelle (eventual consistency). ### Réplication : architecture Maître / Esclave L'architecture **maître / esclave** (aussi appelée **primary / replica**) est une technique de réplication permettant d'améliorer les performances et la disponibilité. #### Principe Un **serveur maître** : - Reçoit toutes les requêtes d'**écriture** (INSERT, UPDATE, DELETE) - Peut également traiter les requêtes de **lecture** (SELECT) Un ou plusieurs **serveurs esclaves** : - Répliquent les données du maître en **lecture seule** - Ne traitent que des requêtes de **lecture** (SELECT) - Se synchronisent automatiquement avec le maître #### Avantages - **Performances** : Répartition de la charge de lecture sur plusieurs serveurs (load balancing) - **Disponibilité** : En cas de panne du maître, un esclave est disponible - **Sauvegardes** : Possibilité de faire des backups sur un esclave sans impacter le maître - **Scalabilité en lecture** : Ajout de serveurs esclaves pour absorber plus de requêtes de lecture #### Concepts avancés Quelques concepts liés à la réplication : - **Failover** : Basculement automatique vers un esclave en cas de panne du maître - **Haute disponibilité** : Garantir un service continu même en cas de défaillance - **Load balancing** : Répartition intelligente des requêtes de lecture entre les esclaves - **Réplication asynchrone vs synchrone** : Délai de synchronisation entre maître et esclaves