Image

Le DbTools­Bundle est une librai­rie PHP qui permet notam­ment de mettre en place un proces­sus d’ano­ny­mi­sa­tion de données. S’agis­sant à l’heure actuelle d’un bundle Symfony, elle est par consé­quent assez couplée au frame­work. Nous envi­sa­geons cepen­dant qu’elle puisse être utili­sée indé­pen­dam­ment à plus ou moins court terme.

Lorsque nous avons déve­loppé cet outil, l’un de nos objec­tifs était de mettre à dispo­si­tion de l’éco­sys­tème Symfony une solu­tion simple d’ano­ny­mi­sa­tion pour favo­ri­ser les bonnes pratiques liées au RGPD. Pour que l’ou­til soit adopté, nous avons tenté de répondre aux trois problé­­ma­­tiques suivantes :

1. Confi­­gu­­rer faci­­le­­ment une anony­­mi­­sa­­tion de données
2. Mettre en place un work­flow simple pour récu­pé­rer des données de produc­tion anony­mi­sées de manière sécu­ri­sée
3. Rendre cette anony­mi­sa­tion rapide

Les deux premières problé­ma­tiques ont déjà été évoquées sur ce blog dans l’ar­ticle Décou­vrez le DbTools­Bundle. Vous trou­ve­rez égale­ment des infor­ma­tions plus complètes direc­te­ment dans la docu­men­ta­tion du bundle (ici pour la confi­gu­ra­tion et ici pour le work­flow).

Évoquons ensemble la troi­sième problé­ma­tique.

Une appli­ca­tion bench­mark

Pour évaluer les capa­ci­tés du DbTools­Bundle à anony­mi­ser rapi­de­ment des données, nous avons créé une petite appli­ca­tion Symfony que vous pouvez retrou­ver sur GitHub.

Cette appli­ca­tion défi­nit 4 connexions pour 4 bases de données gérées par des SGBD diffé­rents : Post­greSQL, SQLite, MariaDB et MySQL.

Pour chacune de ces 4 bases de données, nous avons défini les 3 mêmes enti­tés Doctrine :

Ces 3 enti­tés essayent de mimer au mieux une vraie appli­ca­tion : chacune d’entre elles défi­nit plusieurs champs à anony­mi­ser.

Ensuite, nous avons lancé la commande db-tools:anony­mize avec des jeux de données plus ou moins consé­quents.

Le tableau suivant présente les résul­tats :

Note1 : Les valeurs données sont indi­ca­tives et varient légè­re­ment à chaque lance­ment de la commande, on peut consi­dé­rer une marge d’er­reur de 10%.

Note2 : Ces tests ont été lancés sur une stack Docker qui utilise les images Docker offi­cielles des diffé­rentes plate­formes de base de données. Aucune confi­gu­ra­tion n’a été mise en place, c’est ce qui peut expliquer les mauvais résul­tats pour MySQL : l’image Docker de MySQL n’a pas de confi­gu­ra­tion parti­cu­lière mise en place de base, contrai­re­ment à celle de MariaDB.

La dernière ligne est sans doute celle la plus repré­sen­ta­tive d’un cas que l’on pour­rait rencon­tré. Les résul­tats sont très satis­fai­sants, on anony­mise 3 tables dont une avec 1 million de lignes en 24 secondes avec Post­greSQL !

En regar­dant les 3 premières lignes, on voit qu’en multi­pliant le nombre de données à anony­mi­ser par 10, on ne multi­plie le temps d’ano­ny­mi­sa­tion que par 3 (au moins pour Post­greSQL et SQLite). Ce résul­tat est en grande partie dû à la manière dont le DbTools­Bundle anony­mise les données.

SQL for the win

Avant de propo­ser le DbTools­Bundle à la commu­nauté, nous avons regardé quels étaient les outils PHP exis­tants pour faire de l’ano­ny­mi­sa­tion de données. Ceux que nous avons trouvé mettent tous en place la même approche par batch :

1. Char­ger les données depuis la base
2. Anony­mi­ser les données à l’aide d’un script PHP
3. Mettre à jour les données dans la base

Cette approche a un avan­tage, elle permet d’uti­li­ser des librai­ries exis­tantes comme Faker pour géné­rer de fausses données. Mais elle a un gros incon­vé­nient : elle est très, très, lente.

Avec le DbTools­Bundle, nous avons choisi une autre approche : nous anony­mi­sons direc­te­ment à l’aide de requêtes SQL. Nous utili­sons le moteur de base de données pour ce qu’il fait le mieux : trai­ter de grosses quan­ti­tés de données.

Pour chaque table de base de données à anony­mi­ser, la librai­rie génère une unique requête d’update. C’est ce qui explique que lors des tests évoqués dans la section précé­dente, nous n’ob­ser­vions pas de corré­la­tion linéaire entre le nombre de lignes à anony­mi­ser et le temps d’ano­ny­mi­sa­tion. Pour un moteur de base de données, l’ef­fort à four­nir pour mettre à jour des données n’est pas direc­te­ment propor­tion­nel au nombre de données à modi­fier.

Ce n’est pas le cas lorsque l’on effec­tue ces actions par batch. Avec cette métho­do­lo­gie, le temps d’ano­ny­mi­sa­tion est direc­te­ment propor­tion­nel au nombre de lignes en base de données. Il n’y a rien à faire, c’est dû à la nature même de l’al­go­rithme.

Il faut noter qu’un gros travail a égale­ment été fait pour opti­mi­ser ces requêtes d’update. Le DbTools­Bundle supporte aujour­d’hui 4 moteurs de base de données diffé­rents (Post­greSQL, SQLite, MySQL/MariaDB et SQL Server), les requêtes d’update géné­rées par la librai­rie ont été travaillées de manière à être les plus effi­caces possibles en fonc­tion de la plate­forme sur lesquelles elles vont être exécu­tées. Nous avons ainsi, entre la version bêta du DbTools­Bundle et sa sortie, divisé par 50 les temps d’ano­ny­mi­sa­tion.

Un article est en cours de rédac­tion pour vous présen­tez ces diffé­rentes opti­mi­sa­tions pour chacun de ces 4 types de moteur de base de données.