Enhance synchronization speed

See PM of jytou about SQLite access.

The PM (hope @jytou won't bother):

---

Salut, après avoir jeté un coup d'œil à la base de données, j'ai rajouté des traces SQL pour voir ce qui prenait le plus de temps au moment d'une synchro. Pas beaucoup d'index vitaux manquants (mais par contre des requêtes qui mettent un peu à genoux SQLite, rien de bien étonnant en fait).

Quelques suggestions d'ajout d'index parce qu'utilisés en select: i_index.hash i_index.kick i_index.wasMember c_index.expired_on c_index.created_on (utilisé en jointure) block.issuer idty.revoked idty.wasMember membership.membership s_index.base s_index.amount s_index.consumed txs.written txs.removed txs.version

Je pense pas en avoir oublié de trop importants.

Par contre j'ai repéré ça:

SELECT * FROM membership WHERE `membership` = ? | ["OUT"] ==> 0 rows in 52 ms

Or le champ membership n'a pas d'index, mais surtout c'est un CHAR(2) donc on ne risque pas de trouver "OUT" dedans. Il y a peut-être un loup, là.

Sinon celles qui prennent le plus de temps (et qui sont vraiment les principales dont l'optim ferait vraiment gagner du temps, il y en a actuellement plus de 1800 lors de l'import de la blockchain gtest, et à 140-230 ms chaque ça pèse son poids dans l'import total, à peu près 10 minutes au total sur les 60 minutes d'import environ sur ma bécanne) sont:

SELECT * FROM s_index s1 WHERE s1.op = ? AND conditions LIKE ? AND NOT EXISTS ( SELECT *  FROM s_index s2  WHERE s2.identifier = s1.identifier  AND s2.pos = s1.pos  AND s2.op = ?) ORDER BY CAST(SUBSTR(written_on, 0, INSTR(written_on, "-")) as number)

Et y en a un paquet à chaque fois, je pense qu'on aurait peut-être intérêt à grouper avec des OR sur les like. Après, je conçois que c'est vite dit…

On envoie aussi des volées de:

SELECT * FROM i_index WHERE pub = ? ORDER BY CAST(written_on as integer) ASC | ["CKTR4tvcciRNvqXjYQe6LqAzpawrnH93LA3TgjTsipAh"]   ==> 1 rows in 68 ms

avec une pour chaque adresse publique, et il rame vraiment là-dessus bien qu'il y ait un index, et je soupçonne plutôt le cast en entier d'être le goulot (on aurait peut-être intérêt à stocker l'entier pour s'affranchir du cast). Alors elles pèsent pas forcément le plus lourd chacune, mais là c'est le nombre qui fait la différence (y en a plus de 3000)…

Et on fait aussi 50.000 requêtes de ce type, elles ne pèsent pas non-plus très lourd chacune au niveau de la base, mais là c'est plus le temps d'appel et de retour à la base qui risque de peser son poids (le simple fait d'envoyer les requêtes):

SELECT * FROM i_index WHERE pub = ?

N'aurait-on pas intérêt à mettre tout ça en mémoire? Je conçois que le jour où on a 1 million d'adresses ça va faire un peu lourd (mais bon c'est juste quelques dizaines de méga en mémoire), mais je pense pas qu'on aura la blockchain entière sur un raspberry a ce moment-là… à voir.