Clear database

[fresnault]

• [x] Enlever tous les FEN non uniques (en cours)
• [x] Ajouter les index foreign key entre Move & FEN

[fresnault]

Les requêtes suivantes pour enlever tous les FEN uniques n'ont pas fonctionnés :

ALTER IGNORE TABLE FEN ADD UNIQUE INDEX idx_fen (id); INSERT INTO FEN (id) SELECT DISTINCT idFEN FROM Move;

Du coup je vais essayé d'enlever les doublons directement via des commandes linux.

sort {file-name} | uniq -u

[fresnault]

J'ai récupéré tous les FEN présents dans la base de données dans des fichiers de 30 millions de FEN chacun. Je les ai compter à l'aide de la commande (wc -l {file-name}) : 365 470 750 FEN. J'ai ensuite virer les doublons à l'aide de la commande

sort {file-name} | uniq -u

Nous sommes arrivés au total à 287 131 182 FEN (78,6% uniques). J'ai ensuite regroupé chacun des fichiers et effectuer à nouveau la commande pour virer les doublons

sort -mu *.txt > result.txt

Au final, il nous reste 270 288 763 FEN uniques (73,96% uniques).

[FAMILIAR-project]

The "lesson learned" here seems that using the database backend was an overkill. Maybe we did not use properly the database stuff (e.g., query was not correctly formulated?); or maybe we need to use Hadoop technology on top of it.

I like the solution, very pragmatic.

[fresnault]

Yeah I don't know if we use wisely the database...

I juste changed FEN table schema. Now, the FEN is a VARCHAR(100) BINARY, I hope we will get better results. If not, I will take a look on Apache Hadoop.

In fast, our database is specially reserve to distributed computed, no ?

[fresnault]

I'm currently adding foreign key between move and fen.