-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TECH] Migrer la colonne knowledge_elements.id de INTEGER en BIG INTEGER (partie 1). #3357
Conversation
I'm deploying this PR to these urls:
Please check it out! |
6d5bd03
to
2b2fb09
Compare
2b2fb09
to
d50d4db
Compare
4be03b8
to
8ac9a42
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pair prog
7e1e3af
to
4962cc1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
En local ça m'a l'air tout bon
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
J'ai testé fonctionnellement le trigger, la colonne ID est bien copiée dans bigintId
…-elements ID column This commit also contains the delete of a useless test. This commit also contains the first (knex) raw SQL statements that create PLSQL function and a trigger.
…mall databases This migration is only executed for small databases (local, dev, integration, recette). It is why we make a test on MAX_ROW_COUNT_FOR_SYNCHRONOUS_MIGRATION. We select 10 millions rows value because in production there are 700M rows. Unfortunately, we did not find a pragmatic way to make tests on this migration.
4962cc1
to
c683b52
Compare
🦄 Problème
Historiquement, les identifiants des tables de données utilisateur (PostgreSQL) sont de type Integer.
Si on ne fait rien, d’ici quelques mois, nous risquons de taper la limite des enregistrements possibles sur la table
knowledge-elements
qui est de loin la table la plus volumineuse de Pix (700M de lignes), avec un fonctionnement qui se rapproche d’un comportement évènementiel (énormément d’insertions par secondes).Pour tenir les échéances à venir, nous devons changer le type de de l’ID (clé primaire) des tables les plus volumineuses risquées :
knowledge-elements
etanswers
en tête.Au vu de la quantité de données, les risques sont :
🤖 Solution
Après étude / POC, nous en sommes venus à la conclusion que la meilleure façon de procéder, avec le minimum de downtime + gestion de projet / com / partenaires et le maximum de contrôle, consiste à développer et exécuter un script / une procédure de changement de type.
Le principe général de ce script est le suivant :
Integer
) vers une nouvelle colonne de typeBigInteger
(nomméebigintId
). Cette phase prend plusieurs heures sur plusieurs centaines de millions de lignes.lock
) à la tableknowledge-elements
(en lecture et écriture) afin de réaliser le renommage des meta-data (faire de la colonnebigintId
la nouvelle colonneid
)Lors de notre étude (menées sur des volumes et types de données se rapprochant de la prod, sur zone SecNum Cloud), nous avons obtenu un passage de plusieurs heures de maintenance avec une approche naïve (un bête
ALTER TABLE xxx
) à une fenêtre de maintenance de moins d'un dixième (< 50ms) d'une seconde (!). En tenant compte d'éventuel passage à l'échelle de la réalité, nous estimons qu'avec cette solution, nous aurons moins de 5 secondes de downtime.🌈 Remarques
Cette PR est la première d'un lot de 3 PR:
Son but est de :
bigint
KE
< 10 millions)Notre méthode pour la rédaction des scripts (migration et traitement des données) a été de copier petit à petit – et en y ajoutant des tests autant que possible – les instructions du POC vers le repository.
Il est conseillé de lire les commits unitairement.
💯 Pour tester
Migration des données si faible volumétrie
Localhost ou RA
1/ Exécuter les migrations (depuis
/api/
) :2/ Rollback les 2 dernières migrations (car c'est tout l'intérêt de cette PR)
3/ Vérifier qu'il y a bien 2 migrations à jouer
4/ Jouer la première migration, qui ajoute la colonne
knowledge-elements.bigintId
ainsi que le trigger5/ Vérifier que la colonne et le trigger sont bien déployés en se connectant à la base en local
6/ Jouer la seconde migration
7/ Vérifier qu'il n'existe plus de KE avec un champ
bigintId
ayant pour valeur-1
(valeur par défaut)Migration des données si forte volumétrie
RA
Simuler que les données n'ont pas été migrées
Paramétrer la variable d'environnement
Exécuter la migration
Vérifier dans les logs que la migration a eu lieu et s'est arrêtée
Note: dû à la structure des seeeds (discontinuité des identifiants), les logs mentionnent
Vérifier en BDD que les données ont été migrées
Vérifier que l'index est créé et valide
Copie de la production
TODO (dump en cours de restauration)