Archéo Lex/Repo Git

De Wiki Seb35
Révision datée du 10 août 2021 à 13:17 par Seb35 (discussion | contributions) (Page créée avec « Cette page fait état de l’architecture du/des repos Git créés par Archéo Lex, eu égard des contraintes (performance, stockage) et des usages possibles. == Existant... »)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Aller à la navigation Aller à la recherche

Cette page fait état de l’architecture du/des repos Git créés par Archéo Lex, eu égard des contraintes (performance, stockage) et des usages possibles.

Existant

État des lieux

Actuellement, Archéo Lex crée un repo par texte et a trois variantes de repo (paramètre --organisation) :

  • la principale est de placer tous le texte en Markdown dans un seul fichier texte ;
  • la seconde est de placer le contenu des articles dans des fichiers autonomes, à plat dans le dossier principal ;
  • la troisième est de créer des sous-dossiers par section/sous-section du texte et de placer le contenu des articles dans des fichiers dans cette arborescence.

Il y a 1 ou 2 références par texte :

  • "texte" (ou "sections" ou "articles") : le texte en vigueur
  • "texte-futur" (ou "sections-futur" ou "articles-futur") : le texte en vigueur future (=prévu à une date future, par exemple au 1er janvier de l’année prochaine)

Problèmes

Ordre de grandeur

Cette organisation est adaptée pour les codes étant donné leur faible nombre (≈108 dont ≈74 en vigueur) : il n’y a que 1 ou 2 références par repo, ce qui ne pose pas de problèmes de performances.

Il est possible de créer un repo "codes" comprenant tous les codes (ou tous les codes en vigueur selon ce qu’on veut exposer), ce qui ne fait que ≈200 références. Toutefois, si on cherche (et c’est le cas) à généraliser Archéo Lex aux lois (≈12600[problemes-sur-l-existant 1] dont entre 2,7k et 12k en vigueur[problemes-sur-l-existant 2]), il peut y avoir des problèmes de performances d’autant plus qu’on ajoute les décrets (50k décrets dans LEGI, 200k dans JORF[problemes-sur-l-existant 3]) ou les arrêtés (70k dans LEGI, 600k dans JORF[problemes-sur-l-existant 4]).

Notes

  1. 12595 avec nature='LOI' dans la base JORF au 9 février 2019 via cette PR
  2. Au 9 août 2021 dans la base LEGI : 2746 lois en vigueur, 500 abrogrés, peu avec des statuts autres, total de 3331 lois ; il manque donc au moins ≈7000 lois dans la base LEGI dont on ne connait pas le statut abrogation ou vigueur
  3. Au 9 août 2021 dans la base LEGI : 49129 décrets dont 38287 en vigueur, 8066 abrogés, 1238 périmés, quelques dizaines pour les autres statuts. Au 9 février 2019 dans la base JORF : 204051 décrets.
  4. Au 9 août 2021 dans la base LEGI : 69812 arrêtés dont 53051 en vigueur, 12328 abrogés, 2306 périmés, quelques dizaines ou centaines dans les autres statuts. Au 9 février 2019 dans la base JORF : 606909 arrêtés.

Fichier des références packed-refs

Le problème de performance est en partie sur le fichier des références packed-refs lors de son écriture. Celui-ci est un fichier texte dont la 1ère colonne sont des SHA-1 (40 octets) et la 2e colonne sont les refs correspondantes (longueur variable, probablement autour de 30 octets puisque les références seraient nommées comme refs/lois/loi_2021-689/texte (28 caractères) ou refs/décrets/décret_2021-699/texte (36 caractères)) ; ce fichier est trié, la 2e colonne étant la clé (il y a donc une problématique de tri lors de l’écriture de ce fichier). Sa taille est donc environ 70 octets x (nombre de textes) = 14 Mo pour 200k décrets.

Cela reste gérable si on ne conserve pas les versions passées des références (on a que la base LEGI+JORF du jour), mais n’est plus gérable si on veut garder les références de chaque texte des bases LEGI+JORF pour chaque jour (par ex. refs/codes/code_civil/texte/markdown/20181019-200412/vigueur), ou alors il ne faut stocker que les quelques textes mis à jour (et avoir un mécanisme pour requêter la base LEGI de n’importe quel jour en allant chercher la plus récente référence du texte avant ce jour).

Protocole smart de Git

Lors d’un essai sur un gros repo git avec de nombreuses références, j’ai expérimenté un échange interminable où le client dit qu’il a telle et telle référence (have xxxx [1]) (c’était il y a 1 ou 2 ans, je crois qu’il y a un nouveau mécanisme pour optimiser cette étape).