Pourquoi vous ne devez pas faire des SELECT en PRODUCTION : JAFWINDATA

Une base de donnée de production est la base de donnée utilisée par les utilisateurs d’un système en temps réel. Toute mauvaise manipulation ou erreur grave sur cette base de donnée a des conséquences directes sur le système de l’entreprise. Ceci dit, une grave erreur sur cette base de donnée peut mettre down toutes les activités d’une entreprise. Ainsi, il n’est pas conseillé de faire des manipulations directement sur la base de donnée de production car cela peut coûter très cher à l’entreprise.

Dans cet article, je vous explique pourquoi vous ne devez pas faire un select en production.

👉 Dépendamment du niveau d’isolation des transactions ( READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ etc. ) que vous avez choisi pour ton moteur de stockage ( InnoDB etc.), vous ne pouvez pas faire un select sur une donnée si les opérations de Updates et delete sont en cours dans le système pour cette même donnée (verrou). Ce qui peut fausser vos statistiques donc engendrera une mauvaise décision.

👉 Des fois, on met un verrou dans notre requête de sélect dans le but d’empêcher des updates et delete dans les tables concernées. On le fait pour ne pas avoir des statistiques erronées. En Production, cela peut bloquer tout le système car elle va empêcher toutes opérations de updates et delete dans les tables concernées (un verrou). Ces dernières sont peut-être plus importantes.

👉 En pensant faire un sélect, vous pouvez faire un updates ou delete qui peut mettre tout le système down. Tout est possible.

👉 Il est déconseillé de toucher la base de donnée de production pendant le ‘Live hours’, c’est-à-dire le moment de la journée où le DB est plus sollicité. Vous pouvez savoir cette métrique en analysant les données de visites de votre système avec Google analytics.

👉 En Data analytics, les requêtes d’explorations de données sont plus complexes. Elles demandent plus de temps de calcul et d’espace mémoire. Cela peut impacter négativement le système de production en rendant lents certains processus qui ont plus besoins d’espaces mémoire et de rapidités surtout pendant le ‘Live hours’ où la base de donnée de production est plus sollicitée.

👉En conclusion, il est vraiment déconseillé de faire des manipulations directement dans la base de donnée de production. Pour les opérations de updates et delete, il est conseillé de les faire dans l’environnement de Staging ou pré- Prod et ensuite les synchroniser avec la Prod une fois tout validé.