Mettre en place un processus d'archivage/anonymisation des tables

[mattgu74]

Cette issue devrait résoudre plusieurs problèmes que nous n'avons pas encore, mais qu'on aura bientôt. Et la solution proposé (est ici qu'une proposition, j'ouvre à la discussion, une solution pour résoudre d'un coup toutes ces problématiques).

Les problèmes à résoudre:

• Anonymisation des données passé un certain temps
• Diminution de la taille des tables de travail (purchase, virement, user, price...) (pour optimiser les requêtes).

(Je vais parler ici que de purchase, mais ça devrait pouvoir s'appliquer aux autres tables):

L'idée et d'avoir une table qui est une quasi copie au niveau de la structure de purchase (les données personnelles en moins (ou pas)) et d'avoir un cron, qui déplace les données antérieur à un certain laps de temps (genre 6mois) dans cette table d'archive.

Sa permet d'avoir une tables de taille à peu près constante qui contient les données des ventes (pas de perte de performance, sur les requetes d'historique de casper, et surtout sur les insertions lors de vente), (parce que la actuellement, dans quelques semestres, ça va prendre de plus en plus de temps de faire une simple vente...)

Et pour tout ce qui est requete qui nécessite tout l'historique, on crée une vue, qui fait une union des deux tables, et genre comme par magie on peut continuer à faire des stats etc...

De la même manière, on peut archiver les comptes des users inactifs, pour conserver uniquement ceux qui sont en activités. Sur le papier les gains pourraient être énorme (je pense par exemple aux requetes de l'autocomplete, ou meme lors d'une vente faire un simple select à partir d'un badge pour vérifier que l'user à assez d'argent, le fait d'alléger la table me semble important)

@apuyou Bien que je sois convaincu de l'intérêt de ces optimisations à une très grande echelle, je doute quand même de l'utilité à notre échelle, est ce que au final on est pas entrain de faire un énorme building pour loger trois campeurs ? ^^

Bref le débat est ouvert, j'arrête de proposer ma solution car plus j'avance, moi je suis convaincu moi même...

Mais ce qui est sur:

• On veut stocker ad-vitam-eternam le maximum d'infos pour pouvoir faire des stats, tirer des historiques, voir l'évolution des prix etc... ça a beaucoup de valeur il faut absolument le garder.
• On veut absolument anonymiser les données utilisateurs, après un certain temps, il est hors de question, que l'on sache dans 10 ans (en l'occurence on serait sur 6mois ou 1an) ce que tel personne à acheter au polar tel jour à tel heure...
• Simplement supprimer les colonnes usr_id, n'est pas acceptable, car ça impliquerait de ne JAMAIS vider la table purchase. Or en seulement 10 mois elle fait déjà plus de 200 000 lignes, dans 10 ans (si payutc tient tout ce temps ^^) on peut facilement imaginer de compter ça en millions et faire les opérations qu'on fait actuellement dans une tel table serait juste du suicide...

[trecouvr]

Et dans 10 ans y'aura peut être un serveur 2^10 fois plus puissant ^^ On peut pas faire un test sur dev, genre on insert 1 million de purchases, 10K users, 5K objets, 100K recharge & paybox, puis regarder ce qu'il se passe ? ^^ Edit: ou alors plus simple on a pas l'évolution de l'utilisation en RAM et DISK de Mysq sur l'année ?

[mattgu74]

Moép enfin, tu peux toujours dire: Ok tant que ça tient je reste comme ça. Et le jour ou ça merde paniquer dans tous les sens et faire un fix à l'arrache parce que tout est en rade...

Ou sinon solution 2, tu fais un truc solide, optimisé et qui se nettoie tout seul, et du coup t'es tranquille quoi qu'il arrive, parce que tu sais que tu es toujours largement en dessous des capacités de la machine...

Ou tu cherches à connaitre les limites de la machine, et tant que tu les atteins pas tu considères que tout va bien... Puis tu mes a jour php ou une autre connerie du genre, qui se met à prendre plus de ram et par effet de bord magique ton mysql qui était borderline n'a plus assez de ram et ton serveur s'écroule....

[trecouvr]

Matthieu c'est bien toi qui parle là ? D'habitude t'es plutôt adepte de la solution 1 ou 3 ^^ Ce qu'il faut faire gaffe c'est les foreignkey, par exemple tu archives les purchases, pas de soucis tu peux copier la table. Par contre si tu commences à vouloir archiver les users, ça veut dire que dans ta table archive_purchase, tes usr_id doivent pouvoir pointer sur un user courant ou un user archivé. Je vois deux solutions :

• dédoubler toutes les foreignkey dans les tables d'archivage, genre usr_id_buyer_cur et usr_id_buyer_arc
• retirer la contrainte de foreignkey pour les tables d'archivage, quand tu cherches l'entité liée, par exemple usr_id_buyer, tu vas chercher dans la table user courante et celle d'archivage

Ils font comment à ton taff ?

J'ai une question subsidiaire : est-ce que déplacer des trucs dans des tables d'archivage va réduire la RAM utilisée par MySQL ?

[mattgu74]

bah si tu pointes sur la vue qui fait l'union des deux tables c'est bon... les tables d'archive si elles ont des foreign key tape sur les vue.

[trecouvr]

Ça marche ça dans les contraintes innodb ? Une view on peut la voir comme une table dans phpmyadmin ?

[mattgu74]

Bah normalement oui...

[apuyou]

Je pense qu'il faudrait faire quelques benchmarks (je sens que @trecouvr va être très bon pour ça), histoire de savoir si ça vaut vraiment le coup. MySQL est conçu pour gérer des tables avec des millions de lignes, le seul souci que je vois c'est effectivement la reconstruction des index à chaque insertion. Les SELECT ce sera toujours pareil à mon avis.

Si on veut archiver les ventes, je pense qu'il faut éviter le cron (parce qu'un truc qui tourne tous les 6 mois va forcément foirer beaucoup plus). Au Polar, on a deux tables aussi, et c'est archivé au moment où la caisse est faite. Pour payutc, je proposerai de gérer ça avec le reversement : quand le montant d'une vente a été reversé à une asso, on le met dans la table d'archives.

Au niveau des foreign keys, est-ce qu'on veut garder les associations entre les achats d'un user dans le temps ? Si non, on met juste les le usr_id à NULL et c'est réglé. Si oui (pour avoir des stats plus évoluées), on garde une ligne vide (juste un ID) dans la table des users. Je pense que la taille de la table users n'est absolument pas un souci, on ne fait jamais d'insertion dedans et c'est max +1000 personnes par an, donc on peut facile tenir 10 ans.