Inventaire des modes d'accès

Ce que vous saurez faire

Avant de choisir où stocker les données, listez les usages de chaque type de données. Qui les lit, et comment? À quelle fréquence changent-elles, quel est leur volume et quelle fraîcheur faut-il pour une réponse?

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 50 minutes

Ce que vous devez savoir

• Comment charger les données et utiliser psql, dans De SQLite à PostgreSQL.
• GROUP BY et count(*), dans Agréger correctement du cours de SQL.

Ce qu’il vous faut sur votre ordinateur

• Le projet ~/projects/ticket-api de la dernière leçon, avec PostgreSQL en marche. python -m pytest affiche 34 passed (34 tests réussis).
• Environ 1 Go d’espace disque libre et une connexion Internet, une seule fois, pour les données volumineuses.

Cette leçon n’ajoute aucun fichier au projet. Vous rédigez l’inventaire dans cette leçon et vous interrogez les données volumineuses dans psql. À la fin, vous revenez aux petites données.

Préparer un déménagement

Vous déménagez dans un nouvel appartement. Avant d’acheter des boîtes et des étagères, vous parcourez l’ancien appartement. Vous listez vos objets et leurs usages.

La tasse à café : vous l’utilisez chaque matin, donc elle va sur le comptoir de la cuisine. Les manteaux d’hiver : deux fois par année, donc ils vont au grenier. Votre passeport : vous en avez rarement besoin, mais vous ne devez jamais le perdre. Il va donc dans un tiroir sûr. Deux cents albums photo : lourds, jamais modifiés, consultés une fois par année. Ils vont au sous-sol, avec une liste du contenu de chaque boîte sur l’étagère.

Vous n’avez pas choisi un endroit selon la nature de chaque objet. Vous l’avez choisi selon son usage : fréquence, rapidité d’accès nécessaire, taille et coût d’une perte.

Le problème : choisir le stockage au hasard

Omar, le gestionnaire de produit, pose une question simple à Mei : « Quelle taille aura la base de données du service de soutien, et qu’est-ce qui la rend volumineuse? »

Tomás répond en premier. « Les billets de soutien. Tout est un billet. Mettons toutes les données au même endroit et décidons des détails plus tard. »

Cela semble raisonnable. Mais une supposition ne distingue pas la tasse du passeport. Chargez les données volumineuses et comptez. Ces données servent à tester Larkfield sous forte charge : 300 000 billets fictifs sur un an, soit environ 800 par jour. Larkfield reçoit environ 45 billets par jour aujourd’hui. C’est donc le volume à prévoir, pas le volume actuel.

1. Dans le dossier du projet, avec l’environnement virtuel actif, chargez les données volumineuses :

   python -m scripts.load --size large --reset

   La première fois, le chargeur crée les données volumineuses sur votre ordinateur et télécharge leurs vecteurs, une seule fois :

   Making the large data (once, about 15 seconds) ...
   large: customers 20,000, tickets 300,000, messages 690,300, attachments 61,853, documents 36, ai_runs 449,734, files 0 -> …/ticket-api/data/large
   Downloading the vectors of the large data (15 MB, once) ...
   Database is up to date (4 migrations).
   Loaded the large data in 4.4 s:
     customers             20,000
     tickets              300,000
     messages             690,300
     attachments           61,853
     documents                 36
     ai_runs              449,734
     ticket_embeddings     10,000

   L’option --reset est nécessaire, car les petites données sont chargées : le chargeur ne remplace jamais de données par accident. Les chargements suivants des données volumineuses sautent les trois premières lignes.

   Le chargement lui-même prend de 3 à 5 secondes sur un ordinateur peu occupé. Sur un ordinateur occupé, il peut prendre jusqu’à une minute. Sans connexion Internet, prenez les vecteurs dans votre copie du dépôt des laboratoires. Ajoutez --vectors ../nextia-learning-labs/C20/data/large à la commande. Dans les deux cas, le chargeur vérifie leur SHA-256.

2. Ouvrez psql :

   docker compose exec db psql -U tickets -d tickets

3. Demandez à PostgreSQL combien de lignes contient chaque table et combien d’espace disque elle utilise :

   SELECT relname, n_live_tup, pg_size_pretty(pg_total_relation_size(relid)) FROM pg_stat_user_tables ORDER BY pg_total_relation_size(relid) DESC;
   SELECT pg_size_pretty(pg_database_size(current_database()));

         relname      | n_live_tup | pg_size_pretty
   -------------------+------------+----------------
    messages          |     690300 | 107 MB
    ai_runs           |     449734 | 91 MB
    tickets           |     300000 | 75 MB
    attachments       |      61853 | 17 MB
    ticket_embeddings |      10000 | 16 MB
    customers         |      20000 | 2640 kB
    documents         |         36 | 104 kB
    schema_migrations |          4 | 32 kB
    classifications   |          0 | 16 kB
   (9 rows)
   
    pg_size_pretty
   ----------------
    316 MB
   (1 row)

   Vos tailles peuvent varier de quelques kilooctets ou mégaoctets. Le nombre de lignes est identique.

pg_stat_user_tables est une vue que PostgreSQL maintient sur chaque table. n_live_tup indique son nombre de lignes. pg_total_relation_size compte la table et tout ce qui lui appartient.

Espace disque de chaque table du service de soutien dans PostgreSQL, avec les données volumineuses : 316 Mo au total. msgs = messages, runs = ai_runs, attach = attachments, vecs = ticket_embeddings, cust = customers, docs = documents.

Description textuelle du graphique

Un diagramme à colonnes en mégaoctets. messages 107, ai_runs 91, tickets 75, attachments 17, vecteurs (ticket_embeddings) 16, customers 2,6, documents 0,1. La base de données entière occupe 316 Mo.

Tomás s’est trompé sur deux points. Les billets ne forment que la troisième table en taille : les messages et les exécutions d’IA prennent plus de place. Et les données les plus volumineuses ne sont même pas dans la base de données. La table attachments décrit seulement des fichiers. Demandez-lui quelle taille font ces fichiers :

SELECT count(*) AS files, pg_size_pretty(sum(size_bytes)) AS all_files, pg_size_pretty(max(size_bytes)) AS largest FROM attachments;

 files | all_files | largest
-------+-----------+---------
 61853 | 11 GB     | 9277 kB
(1 row)

Les détails des fichiers occupent 17 Mo. Les fichiers eux-mêmes occuperaient 11 Go : environ 36 fois la base de données entière. Dans les données volumineuses, les fichiers n’existent pas; seuls leurs détails existent. Une supposition aurait ignoré ce qui prend le plus de place dans le stockage de Larkfield.

L’idée : un inventaire des modes d’accès

Un mode d’accès décrit une façon dont un programme utilise les données. Il précise les lignes lues ou écrites, comment le programme les trouve et à quelle fréquence. « Afficher les billets de facturation ouverts, du plus récent au plus ancien, toutes les quelques secondes » est un mode d’accès. « Additionner le coût d’IA du mois dernier, une fois par mois » en est un autre.

Un inventaire des modes d’accès liste les données et leurs modes d’accès. Il répond à cinq questions pour chaque type de données :

1. Qu’est-ce que c’est? L’entité : un billet, un message, un fichier.
2. Comment les lit-on? Les modes de requête : par identifiant, par filtre, par proximité, sous forme de fichier entier.
3. À quelle fréquence changent-elles? Écrites une fois et jamais modifiées, ou modifiées plusieurs fois.
4. Quel est leur volume? Le volume actuel et sa vitesse de croissance.
5. Quelle fraîcheur et quelle exactitude faut-il pour une réponse? C’est la cohérence. Chaque lecteur doit-il voir un changement immédiatement? Ou une réponse datant d’une heure suffit-elle?

C’est la liste de déménagement de l’appartement, mais pour les données. Vous la préparez avant de choisir un stockage, car chaque réponse indique un type de stockage.

Un petit exemple détaillé : les exécutions d’IA

Remplissez d’abord une ligne de l’inventaire avec les petites données, où vous pouvez voir chaque nombre. Quittez psql avec \q, chargez les petites données avec python -m scripts.load --reset, puis rouvrez psql. Exécutez ensuite :

SELECT count(*), min(created_at), max(created_at) FROM ai_runs;
SELECT task, count(*) FROM ai_runs GROUP BY task;
SELECT created_at::date AS day, count(*) FROM ai_runs WHERE created_at >= '2026-10-02' GROUP BY 1 ORDER BY 1;

 count |          min           |          max
-------+------------------------+------------------------
   294 | 2026-09-25 07:26:50+00 | 2026-10-08 19:13:23+00
(1 row)

    task     | count
-------------+-------
 classify    |   200
 draft_reply |    94
(2 rows)

    day     | count
------------+-------
 2026-10-02 |    30
 2026-10-03 |    26
 2026-10-04 |    19
 2026-10-05 |    25
 2026-10-06 |    22
 2026-10-07 |    13
 2026-10-08 |    11
(7 rows)

Chaque billet a été classé une fois (200 exécutions), et 94 ont reçu une réponse rédigée. Au cours des 7 derniers jours, 146 exécutions ont été écrites : environ 21 par jour. La table occupe 80 ko. Répondez maintenant aux cinq questions :

Question	Exécutions d’IA (petites données)
Qu’est-ce que c’est?	Un appel à un modèle pour un billet : modèle, version de la requête, jetons, coût, temps, sortie
Comment les lit-on?	Par billet (« la dernière exécution de T-30002 »), puis par mois et modèle pour le rapport de coûts de Priya
À quelle fréquence changent-elles?	Écrites une fois, environ 21 par jour. Jamais modifiées ensuite
Quel est leur volume?	294 lignes, 80 ko. Le volume augmente avec chaque billet
Quelle fraîcheur et quelle exactitude?	Le rapport peut dater d’un jour. Mais les sommes doivent être exactes : il s’agit d’argent

Une seule ligne révèle déjà beaucoup. Les exécutions d’IA forment un registre où l’on ajoute seulement des données : personne ne modifie le passé. Priya les lit en masse, et un petit délai convient. Mais les montants doivent être justes. Pour cette raison, Migrations, au module 3, change le type de la colonne du coût.

L’inventaire de Larkfield

Faites maintenant l’inventaire du service de soutien entier, avec les données volumineuses. Quittez psql, rechargez les données volumineuses avec python -m scripts.load --size large --reset, puis ouvrez psql. À quelle vitesse chaque type de données augmente-t-il? Les données se terminent le 8 octobre. Comptez donc les lignes des sept derniers jours :

SELECT count(*) FROM tickets WHERE created_at >= '2026-10-02';
SELECT count(*) FROM messages WHERE created_at >= '2026-10-02';
SELECT count(*) FROM ai_runs WHERE created_at >= '2026-10-02';
SELECT count(*) FROM attachments WHERE uploaded_at >= '2026-10-02';

Les réponses sont 5 761, 10 247, 8 724 et 1 161. Aucun client ni document n’a été ajouté cette semaine-là.

Lignes ajoutées à chaque table du 2 au 8 octobre 2026 dans les données volumineuses, avec les noms abrégés du graphique précédent. Les messages et les exécutions d'IA augmentent plus vite que les billets.

Description textuelle du graphique

Un diagramme à colonnes des lignes écrites du 2 au 8 octobre 2026. Messages : 10 247. Exécutions d’IA : 8 724. Billets : 5 761. Pièces jointes : 1 161. Clients et documents : 0.

Ensuite, quelle part des données est « chaude », utilisée chaque jour? Les agents travaillent sur les billets ouverts et en attente :

SELECT status, count(*) FROM tickets GROUP BY status ORDER BY 2 DESC;

  status  | count
----------+--------
 closed   | 254364
 resolved |  33822
 open     |   7216
 pending  |   4598
(4 rows)

Seulement 11 814 des 300 000 billets sont ouverts ou en attente : environ 4 sur 100. La file des agents en affiche quelques-uns à la fois. Par exemple, SELECT count(*) FROM tickets WHERE status = 'open' AND team = 'billing'; donne 1 659. La file affiche les 20 plus récents. Une conception qui lit tous les billets pour en trouver 20 fait 15 000 fois trop de travail. Le module 4 mesure exactement cela.

Mei dessine maintenant les modes d’accès : qui lit et écrit quoi.

Les modes d'accès du service de soutien : chaque flèche représente une façon dont une partie du service lit ou écrit une table.

Description textuelle du diagramme

Sept parties du service de soutien utilisent les données. La file des agents et la page du billet lisent toute la journée. La page du billet lit quatre tables pour un billet. Les réponses des agents écrivent des messages et changent le statut. Chaque nouveau billet reçoit des exécutions d’IA. La recherche de billets semblables lit les vecteurs par proximité. Le rapport de coûts de Priya lit un mois d’exécutions d’IA, une fois par mois. L’effacement de Grace supprime les données d’un client, rarement.

Elle rédige ensuite l’inventaire. Les nombres viennent des données volumineuses. La colonne de fraîcheur reflète la réponse du service de soutien : Grace et Priya ont précisé leurs besoins.

Données	Comment on les lit	Fréquence des changements	Volume (données volumineuses)	Fraîcheur et exactitude
Clients	par identifiant; toutes les données d’un client pour un effacement	rarement : aucun nouveau client la semaine dernière	20 000 lignes, 2,6 Mo	exactes; un effacement doit atteindre chaque stockage
Billets	par identifiant; billets ouverts d’une équipe, du plus récent au plus ancien; par client	statut, équipe et priorité changent plusieurs fois; environ 820 nouveaux par jour	300 000 lignes, 75 Mo; 4 % ouverts ou en attente	immédiatement : deux agents ne doivent pas prendre le même billet
Messages	tous les messages d’un billet, dans l’ordre	écrits une fois, environ 1 460 par jour	690 300 lignes, 107 Mo	immédiatement, et jamais perdus : un client les a écrits
Fichiers (photos, reçus)	un fichier entier à la fois, par son billet	écrits une fois, jamais modifiés; environ 165 par jour	61 853 fichiers, 11 Go; détails 17 Mo	le fichier doit correspondre à sa somme de contrôle
Documents de politique	par identifiant et version en vigueur à une date	une nouvelle version quelques fois par année	36 versions de 35 politiques	version exacte : il faut vérifier une ancienne réponse avec la version en vigueur à ce moment-là
Exécutions d’IA	dernière exécution d’un billet; un mois par modèle pour le rapport	écrites une fois, environ 1 250 par jour	449 734 lignes, 91 Mo	un jour de retard convient au rapport; sommes exactes
Vecteurs des billets	par proximité avec le vecteur d’un autre billet	créés quand un billet est écrit	10 000 vecteurs, 16 Mo	une approximation convient : « semblable », pas « égal »

Lisez le tableau par colonne, et quatre groupes apparaissent :

• Petits enregistrements avec de nombreuses requêtes. Clients, billets, messages, documents et exécutions d’IA. On les trouve par identifiant et par filtre, ils changent et ils exigent des réponses exactes. C’est un travail pour une base de données relationnelle.
• Fichiers volumineux. 11 Go que personne ne modifie ni ne filtre. On les lit en entier, un à la fois.
• Vecteurs. On les recherche par proximité, pas par égalité des valeurs, et une réponse approximative convient.
• Réponses répétées. La page du billet pose les mêmes questions toute la journée. Si une réponse lente revient souvent, une copie de courte durée peut économiser du travail.

La prochaine leçon attribue à chaque groupe son type de stockage.

Quand faire un inventaire, et ce qu’il coûte

Faites-en un avant de choisir un stockage. Refaites-le quand le produit change : nouvelle fonctionnalité, nouveau type de fichier, modèle qui écrit davantage. Ici, l’inventaire a remplacé une supposition (« les billets prennent le plus de place ») par un décompte.

Il coûte peu : une heure, quelques requêtes count(*) et des questions aux personnes qui utilisent les données. Il vient avec deux avertissements :

• Les nombres vieillissent. Notez la date et les données comptées, puis comptez de nouveau avant une décision importante.
• Prévoyez la croissance, pas un scénario imaginaire. Les données volumineuses représentent environ 18 fois le volume actuel de billets de Larkfield. Cela suffit pour rendre les requêtes lentes visibles. Une conception pour un milliard de billets coûterait bien plus cher et n’aiderait personne.

À vous de jouer : les documents

Remplissez vous-même la ligne des documents, avec les données volumineuses. Faites d’abord une prédiction : combien de lignes, à quelle fréquence changent-elles et comment les lit-on? Vérifiez ensuite dans psql avec SELECT doc_id, version, effective_from, effective_to FROM documents ORDER BY doc_id, version;.

Afficher un exemple de réponse

36 lignes décrivent 35 politiques. Seule returns-policy (politique de retour) a deux versions : la version 3 est en vigueur jusqu’au 31 octobre 2026. La version 4 entre en vigueur le 1 novembre 2026. SELECT count(*), count(DISTINCT doc_id) FROM documents; donne 36 et 35.

Données	Comment on les lit	Fréquence des changements	Volume	Fraîcheur et exactitude
Documents de politique	par identifiant, dans la version en vigueur à une date; les assistants les lisent pour répondre	une nouvelle version quelques fois par année; une ancienne version n’est jamais modifiée	36 lignes, environ 100 ko	version exacte : une réponse du 20 octobre doit utiliser la version 3

Les documents sont très petits et changent rarement, mais chaque version doit rester. Un stockage qui conserve seulement la copie la plus récente perdrait la version 3. Personne ne pourrait alors vérifier une ancienne réponse.

Revenir aux petites données

Les prochaines leçons utilisent les petites données. Quittez psql avec \q et rechargez-les :

python -m scripts.load --reset

La commande affiche les nombres des petites données : tickets 200, ticket_embeddings 200. python -m pytest affiche toujours 34 passed. Les données volumineuses restent dans data/large/ pour le module 3. Leur prochain chargement ne prendra donc que quelques secondes.

De bout en boutConcevoir et optimiser le stockage d'un jeu de données public ouvertÉtude de cas

L’étude de cas Boston 311 commence par un inventaire de six modes d’accès. Chacun détermine ensuite le choix d’un index, ou l’absence d’index.

Vérification des connaissances

Vérifiez votre compréhension

Nommez les cinq questions d'un inventaire des modes d'accès et répondez à chacune en une ligne pour les messages.

Afficher la réponse

Qu’est-ce que c’est : un message après le premier, écrit par un agent ou un client, sur un billet. Comment les lit-on : tous les messages d’un billet, dans l’ordre, sur la page du billet. Fréquence des changements : écrits une fois, environ 1 460 par jour dans les données volumineuses, jamais modifiés. Volume : 690 300 lignes, 107 Mo, la plus grande table. Fraîcheur et exactitude : immédiatement, et jamais perdus, car un client les a écrits.

Vérifiez votre compréhension

Prédisez : Larkfield ajoute le téléversement de photos à son application mobile, et deux fois plus de billets reçoivent une photo. Quels nombres de l'inventaire changent le plus, et quel stockage subit cette pression?

Afficher la réponse

Les fichiers : aujourd’hui, environ 165 par jour et 11 Go dans les données volumineuses. Ces nombres doubleraient. La table attachments augmente aussi, mais ses lignes sont petites : 17 Mo aujourd’hui. La pression touche donc l’endroit qui conserve les fichiers, pas la base de données. Si les fichiers étaient dans la base de données, elle passerait de 316 Mo à plusieurs gigaoctets de plus. Chaque sauvegarde et chaque copie grossiraient aussi.

Vérifiez votre compréhension

Vérification pratique : dans les données volumineuses, combien de billets sont ouverts dans l'équipe de facturation? Quelle part de tous les billets est ouverte ou en attente? Montrez les requêtes.

Afficher la réponse

SELECT count(*) FROM tickets WHERE status = 'open' AND team = 'billing'; donne 1 659. SELECT status, count(*) FROM tickets GROUP BY status; donne open (ouverts) 7 216 et pending (en attente) 4 598. Cela fait 11 814 sur 300 000, environ 4 %. La file affiche 20 des 1 659 billets. La requête principale des agents a donc besoin de quelques lignes parmi 300 000.

Récapitulatif

• Un mode d’accès décrit une façon dont un programme lit ou écrit des données. Un inventaire des modes d’accès répond à cinq questions pour chaque type de données. Qu’est-ce que c’est? Comment les lit-on? À quelle fréquence changent-elles? Quel est leur volume? Quelle fraîcheur et quelle exactitude faut-il pour une réponse (cohérence)?
• Compter a été plus utile que deviner. Dans les données volumineuses, les messages (107 Mo) et les exécutions d’IA (91 Mo) dépassent les billets (75 Mo). Les fichiers décrits par la table attachments occuperaient 11 Go : environ 36 fois la base de données de 316 Mo.
• Seulement 4 billets sur 100 sont ouverts ou en attente, et la file en affiche 20 à la fois.
• L’inventaire révèle quatre groupes : petits enregistrements avec de nombreuses requêtes, fichiers volumineux, vecteurs recherchés par proximité et réponses répétées.
• Vous êtes de retour aux petites données, et python -m pytest affiche 34 passed.

Ensuite, chaque groupe reçoit son type de stockage : une base de données relationnelle, du stockage objet, un index vectoriel ou un cache.

Leçon suivante : Catégories de stockage