i

Description

Peinture indienne de tailleurs de pierre travaillant au ciseau et au maillet sur leurs blocs.

Source

auteur non indiqué (Wellcome Collection) · page d’origine

Licence

PD Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

La démarche : préparer, puis frapper une fois

Utiliser le moteur ne suffit pas : il faut organiser le traitement pour que le moteur ait tout ce qu'il lui faut quand on lui pose la question.

En bref

• Avant : périmètre, grain, clés, index, fonctions pures et matérialisées, règles en données, dérivées, entrées figées, contrôles.
• Pendant : très peu de très grosses requêtes, aucune itération sur des lignes.
• Partout déterministe : un maillon séquentiel ou non déterministe annule la chaîne ; un bloc excellent dans un curseur ne sert plus à rien.
• Volontaire : les décisions se prennent avant d'écrire.

Sur cette page

1. 1. Deux postures
2. 2. Deux phases : préparer, puis frapper une fois
3. 3. Ce qui se prépare avant
4. 4. Exécuter : très peu de très grosses requêtes
5. 5. Tout le traitement doit être déterministe
   1. 5.1 La chaîne vaut son maillon le plus faible
   2. 5.2 Un bloc déterministe dans un curseur, et tous les gains sont perdus
6. 6. Une démarche volontaire : les questions avant la première requête
7. 7. Tables de travail, variables de table et tables en mémoire
8. 8. Coût et limites de la démarche
9. Sources et vérification

Le moteur ne fait que la moitié du travail. La première moitié de la programmation ensembliste, c'est de bien utiliser ses outils (jointures, fonctions de fenêtre, APPLY…) : c'est l'objet des pages précédentes. La seconde est une démarche : organiser le traitement pour que le moteur dispose, au moment où l'on lui pose enfin la question, de tout ce qu'il lui faut. On prépare le modèle avant ; on pose ensuite très peu de très grosses requêtes.

1. Deux postures#

Un développeur qui connaît le moteur à la perfection peut rester dans la première posture : chaque requête qu'il écrit est excellente. La performance se joue pourtant dans l'assemblage.

2. Deux phases : préparer, puis frapper une fois#

La phase de préparation est longue et volontaire : on y passe du temps, sans y chercher de résultat. La phase d'exécution est courte et banale : si elle est difficile, c'est que la préparation est incomplète.

3. Ce qui se prépare avant#

4. Exécuter : très peu de très grosses requêtes#

1. Aucune itération sur des lignes de données. Une boucle ne se justifie que sur des objets (voir les limites) ou des lots d'ensembles.
2. Chaque requête traite tout le périmètre, pas un élément à la fois : le paramètre d'hier est la colonne d'aujourd'hui.
3. Une écriture par table cible et par étape, avec OUTPUT pour tracer ce qui change, plutôt qu'un déclencheur qui re-parcourt.
4. Un ordre explicite entre étapes (un graphe de dépendances, pas un empilement historique) ; chaque étape déclare ce qu'elle lit et ce qu'elle écrit.
5. Des lots seulement par contrainte physique (journal, verrous, durée), bornés par plages de clés alignées sur l'index, jamais « une ligne à la fois ».
6. Rejouable : relancer le traitement sur les mêmes entrées redonne exactement le même résultat.

5. Tout le traitement doit être déterministe#

« Déterministe » prend ici son sens le plus large : mêmes entrées, mêmes sorties, à tout moment, sans dépendance cachée (heure, aléa, ordre implicite, état d'autres transactions, plan d'exécution). C'est ce qui rend un traitement préparable (ce qu'on matérialise reste valable), rejouable, testable et comparable à sa version précédente.

5.1 La chaîne vaut son maillon le plus faible#

Il suffit d'un seul maillon séquentiel ou non déterministe pour que l'ensemble en pâtisse. La loi d'Amdahl (1967) en donne l'ordre de grandeur : si une part s du travail reste séquentielle, l'accélération est bornée par 1/s, quel que soit le nombre de cœurs. Avec p = 1 − s la part parallélisable et n cœurs : S = 1 / ((1 − p) + p/n).

Et la boucle est pire que la loi : la part « séquentielle » n'est pas constante, elle croît avec le nombre d'itérations, car chaque tour paie un surcoût fixe.

5.2 Un bloc déterministe dans un curseur, et tous les gains sont perdus#

Un bloc parfaitement écrit (une fonction table en ligne, une requête indexée, une fonction pure) reste excellent à l'unité. Invoqué N fois par un curseur, il subit ce que coûte l'itération :

L'optimisation du bloc est locale ; le coût de la boucle est global. Les mesures ci-dessous comparent, pour trois cas, la boucle « optimisée au mieux » (index ajoutés, requêtes propres) avec la démarche ensembliste :

6. Une démarche volontaire : les questions avant la première requête#

1. Quel est le grain du résultat ? Une ligne, c'est quoi ?
2. Quel est le périmètre ? Peut-il se matérialiser en une table de clés ?
3. Quelles entrées doivent être figées ? Quelle date d'exploitation, quel instantané ?
4. Qu'est-ce qui est stable, qu'est-ce qui change souvent ? Le stable se matérialise ; ce qui change à chaque exécution se joint.
5. Quelles dérivées vont être utilisées plus d'une fois ? Hiérarchies, droits, calendriers, correspondances.
6. Où se trouve la boucle cachée ? Un appelant, un orchestrateur, un déclencheur, une fonction scalaire ?
7. Comment saura-t-on que le résultat est juste ? Le plan de contrôle s'écrit avant le traitement.
8. À quoi ressemble la requête finale ? Si l'on ne sait pas l'écrire, la préparation n'est pas terminée.

7. Tables de travail, variables de table et tables en mémoire#

8. Coût et limites de la démarche#

Les erreurs concrètes que cette démarche permet d'éviter sont cataloguées dans Les erreurs de conception d'un expert, et mesurées dans Les cas catastrophiques.

Sources et vérification#

• Amdahl, G. M. (1967), « Validity of the single processor approach to achieving large scale computing capabilities », AFIPS Conference Proceedings, vol. 30, p. 483–485 — loi d'Amdahl
• Microsoft Learn — table (Transact-SQL) : variables de table — statistiques, parallélisme, compilation différée, tempdb
• Microsoft Learn — In-Memory OLTP : vue d'ensemble et scénarios — tables non durables, types table à mémoire optimisée, modules natifs
• Microsoft Learn — Scalar UDF Inlining — exécution itérative et absence de parallélisme des fonctions scalaires