Trop de colonnes indexées sur les tables Sqlite ? (duniter v1.8)

Nodes Duniter-v1
1

En regardant de plus près les index qui existent sur les tables, je m’aperçois que toutes les colonnes sont indexées. Par exemple dans le cas de la table des TX, cela fait beaucoup de monde ! :slight_smile:

Voici le code responsable à mon avis :

  generateCreateIndexes() {
    return this.keys()
      .map((fieldName) => {
        return `CREATE INDEX IF NOT EXISTS idx_${this.name}_${fieldName} ON ${this.name} (${fieldName});\n`;
      })
      .join("");
  }

  keys(): (keyof T)[] {
    return Underscore.keys(this.fields);
  }

Il s’agit d’un vieux code. Mais cela doit ralentir de beaucoup l’écriture dans la table, non ? D’autant que tout indexés semble inutile.

Par ailleurs je vois dans le constructeur que l’on a pour chaque colonne un SqlFieldDefinition avec un boolean indexed. Le but initial était sans doute d’utiliser cette valeur pour savoir quelle colonne indexées ou pas.

Je me trompes @cgeek ? Redis moi stp, si tu te penses que ca peut-être utile que j’optimise des choses de ce côté là aussi.

La correction semble toute simple, mais globalement il faudra retester une synchro pour voir si ca change quelque chose.

EDIT: j’ai fait une MR !1430 sur la branche release/1.8

2 Likes
2

@cgeek, j’ai une question qui est liée :

  • dans SqliteMIndex, je vois que tu créée une table c_mindex(pub,created_on,expires_on,expired_on,revokes_on,writtenOn)
  • il y a bien des insert/update
  • mais je ne trouve aucune lecture (aucun select).

Du coup, te rappelles tu à quoi sert cette table ? Peut on la supprimer ?

EDIT: je penses que de toute façons cette classe est maintenant implémentée en LevelDB, non ?

3

Je viens de finir une synchro avec cette version. On gagne un peu de temps, mais ça semble être dans l’épaisseur du trait comme ont dit.

Sur mes trois derniers tests le temps de synchro donné était environ 8800s, 9000s, 8500s.
Ce test ci a mis 8300s.

4

Que veux tu dire par synchro ? après un reset data ou pas ?
En effet, Il faut forcément supprimer les tables (.config/duniter/ ... *.db) sinon les ancien index existent toujours :slight_smile:

As tu vu que j’ai pousser d’autres modifs sur la MR ? Notamment pour ajouter des colonnes indexées (celles qu’on requête quelque part). Ca peut améliorer encore.

et puis il ya la question de la place, que prennent ces index.

5

En partant d’une installation toute fraîche. Donc aucune donnée pré-existante.

J’ai buildé l’image docker puis lancé mon test vers 14h. J’ai pas vérifié ensuite si des choses avaient été ajoutées.

EDIT : apparemment tes dernières modifs sont postérieures à mon build. Je rebuild puis relance une synchro. Résultat demain car pas plus de dispo ce soir.

1 Like
6

Eh bien je n’ai pas vu d’amélioration côté synchro. On est toujours autour des 8300s.

7

Merci @Pini ! Ce noeud 1.8 est-il accessible quelque part ? Je voudrais bien tester Cesium 1.7 dessus
L’idéal serait de cherry-picker toutes mes dernières MR (fans les branche fix//1.8/

Du coup, pour les perf, même si on ne gagne pas, je suis rassuré. Car cela aurait aussi pu être l’inverse : un oubli d’index de ma part qui ralenti :slight_smile:

Et au niveau du volumes des fichier, vois tu une différence ? (fichiers *.db)

8

Pas accessible, non. C’est un docker jetable que j’active uniquement pour les tests de synchro. Mes deux noeuds sont en 1.9 sinon.

1 Like
9

Oui je pense, l’idée était que LevelDB remplace totalement SQLite pour le protocole et que SQLite ne reste que pour les piscines.