Comprendre les requêtes préparées
en SQL.
en SQL.
Woah, je ne savais pas que SQLite pouvait directement exporter en JSON, ou même faire des DB temporaires dans la RAM. :o
In a client/server database, each SQL statement requires a message round-trip from the application to the database server and back to the application. Doing over 200 round-trip messages, sequentially, can be a serious performance drag.
SQLite is not client/server, however. The SQLite database runs in the same process address space as the application. Queries do not involve message round-trips, only a function call. The latency of a single SQL query is far less in SQLite. Hence, using a large number of queries with SQLite is not the problem.
Père Noël be like :
SELECT * from children WHERE behaviour = 'nice'
Soit c’est un troll, soit c’est une critique de tous les "code of conduct" absurdes qu’on voit désormais.
J’ai du mal à voir quelqu’un capable de pondre SQLite être aussi con que ça :O
Quoi qu’il en soit, tout ça s’applique aux dév de SQLite (ceux qui font SQLite), pas ceux qui l’utilisent (ni en tant que codeurs qui utilisent SQLite dans le code, ni l’utilisateur final), donc à la limite… osef :) .
Je me mets à optimiser un peu mon lecteur RSS. Pas qu’il soit lent (il tri 70k entrées RSS en 0,22 secondes), mais je viens de trouver un truc.
Dans le lecteur, je fais une requête particulière pour compter le nombre d’éléments non lus pour chaque flux :
SELECT bt_feed, SUM(bt_statut) AS nbrun FROM rss GROUP BY bt_feed
Ensuite, en PHP, je fais une liste des flux avec le nombre d’éléments non-lus associés. Jusque là, rien d’alarmant.
Sauf que la liste des flux utilisée en PHP à ce stade est déjà recyclée. J’ai juste besoin d’une autre requête pour obtenir le nombre d’articles non lus.
Je peux optimiser un peu ma seconde requête :
SELECT bt_feed, SUM(bt_statut) AS nbrun FROM rss WHERE bt_statut = 1 GROUP BY bt_feed
Ici, le « WHERE bt_statut = 1 » signifie qu’il ne doit faire la "somme" que sur les éléments dont le statut est 1 (pas ceux où il est à 0).
Étant donnée que la BDD contient ~69 000 éléments lus (0) et seulement ~1 000 éléments non lus (1), ça revient à sommer sur seulement 1k éléments au lieu de 69k.
Ça me fait gagner environ 10~15 % du temps de la requête : je passe de 0,22 s à 0,19 s. C’est loin d’être du grappillage de micro-secondes.
Utiliser SQLite permet de gagner ~35 % de performances (en moyenne) pour stocker des fichiers, par rapport à un système de fichier normal.
Le gain de perfs est le plus impressionnant sur W10.
SQLite a le petit problème qu’ils ne peut pas être écrit par deux processus à la fois.
Pourtant, en bricolant un peu et avec les bons softs et les bons réglages, et sur un (très) gros serveur, ils arrivent ici à faire environ 4 millions de requêtes par seconde sur du SQLite.
Oh bien !
Un client SQL qui gère tout un tas de SGBD.
C'est parfait à l'heure où le petit SQLite Browser est devenu une usine à gaz qui ne gère plus tout correctement.
Si en SQLite il vous arrive d’avoir une erreur disant que la BDD est verouillée (« General error: 5 database is locked »), c’est que vous avez sûrement manqué de fermer un curseur quelque part.
Vérifiez les fetch() et ajoutez un closeCursor() en dessous de votre boucle.
En PHP par exemple :
$req = $handle->query("SELECT * FROM table");
$data = $req->fetch();
Ajoutez ça à la suite :
$req->closeCursor();
Logique, mais quand on le sait pas on peut toujours chercher…
Les forums sont pleins de cette question spécifique, mais la plupart ont des hacks farfelues (relancer Apache, etc.) qui ne sont pas des solutions.