Une base de données est le composant d’une application qui stocke les données afin qu’elles subsistent après un redémarrage de l’application, un plantage du serveur ou une coupure de courant. L’application peut ensuite récupérer ces données sous des formes spécifiques, comme un enregistrement unique identifié par son ID ou une liste filtrée par utilisateur.
Pour rendre la notion de « données » concrète, prenons l’exemple d’une application simple de gestion de liste de tâches. Chaque tâche constitue un enregistrement comportant des champs tels que task_id, user_id, title, completed et created_at. L’application doit prendre en charge deux actions fondamentales : la création d’une tâche et l’affichage de la liste des tâches d’un utilisateur.
Dans une configuration de base à serveur unique, le client envoie des requêtes HTTP à un serveur d’applications, lequel lit et écrit des lignes dans une base de données unique. La base de données garantit l’intégrité des données en appliquant des règles telles que « une ligne de tâche est écrite une seule fois par requête » ; elle génère toutefois de la latence, car les opérations de lecture et d’écriture nécessitent du temps au niveau du disque et de la mémoire. Visualisons les deux chemins de requête sur un schéma fonctionnel.
Lors d’une requête de création de tâche, le serveur d’applications valide les données d’entrée, demande à la base de données d’insérer une nouvelle ligne correspondant à la tâche, puis renvoie le nouvel identifiant (task_id) au client. Le client ne considère l’écriture comme pérenne qu’une fois que la base de données l’a confirmée ; c’est pourquoi la base de données constitue un élément critique pour garantir l’intégrité des données.
Lors d’une requête de liste des tâches, le serveur d’applications demande à la base de données toutes les tâches correspondant à un user_id donné (souvent triées par created_at), puis met en forme la réponse. Si la requête parcourt plus de lignes que nécessaire, la charge de travail de la base de données augmente et le temps d’attente du client s’allonge ; les performances dépendent alors de la manière dont la base de données localise les lignes correspondantes.
À mesure que le nombre d’utilisateurs ajoutant des tâches augmente, le premier dysfonctionnement visible est généralement le ralentissement de la liste des tâches, car la base de données doit lire une quantité excessive de données pour répondre à une seule requête. Ensuite, un utilisateur très actif ou une liste partagée peut engendrer des attentes liées aux verrous (lock waits) : lorsque plusieurs opérations d’écriture tentent de modifier la même ligne ou le même ensemble de lignes, les requêtes s’empilent dans une file d’attente au lieu de s’exécuter en parallèle. Enfin, si le processus ou la machine hébergeant la base de données unique tombe en panne, l’application entière cesse de fonctionner, car toutes les requêtes en dépendent. Le schéma suivant illustre ces trois points de tension sur une même échelle de référence.