AIR SQLite – Optimisation des performances
On l'a vu tout au long de ces derniers tutoriaux sur SQLite avec AIR, il existe de nombreuses manières d'utiliser une base SQLite. La plupart fonctionne mais toutes ne donnent pas les mêmes performances.
Voici un petit récapitulatif des opérations que vous pouvez mettre en place pour optimiser les traitements de votre base SQL
Mode asynchrone
Comme discuté dans l'article "AIR SQLite – Mode synchrone et asynchrone", une base SQLite peut être ouverte de deux manière. La première (synchrone) est simple à utiliser mais va ralentir votre application lors des gros traitements. La seconde (asynchrone) est plus difficile à mettre en place car il faut jouer avec une mécanique évènementielle mais elle a l'avantage de ne pas stopper le déroulement de votre application:
AIR SQLite – Mode synchrone et asynchrone
Un passage en mode asynchrone peut permettre une meilleure expérience utilisateur (ressentie).
Pré-créer Ré-utilisez les objets de connexion (SQLConnection)
L'ouverture d'une base de données SQLite peut-être coûteuse, mais une fois que votre base est ouverte, vous pouvez ré-utiliser l'objet SQLConnection par la suite, inutile de re-créer des connexions à la base.
Même si vous n'utilisez pas de SQLConnection au démarrage de votre application, lancez l'ouverture de base de données en fond, cela vous évitera un délai quand vous aurez besoin d'accéder à la base pour la première fois.
Utilisation des requêtes SQL paramétrées
L'utilisation de requêtes SQL paramétrées peut grandement améliorer les performances de votre application. Plus d'information sur cet article:
AIR SQLite – Utilisation de requête paramétrée (SQLStatement parameters)
Au lieu de compiler N fois des requêtes successives, la base de va faire cette compilation qu'une seule fois ce qui va représenter un gain de temps énorme par la suite car cette étape de compilation peut être lourde.
Utilisation des transactions
L'utilisation des transactions va se faire le plus souvent en conjonction avec l'utilisation des requêtes SQL paramétrées. Les transactions vont vous permettre de faire des requêtes en masses ("bulk") comme des INSERT ou des UPDATE en un temps record.
Ci-dessous, un petit graphique représentant cette différence de performances (au dessus de 10 000 records, les résultats n'ont pas été enregistrés sans transaction car trop longs):
Voici quelques tutoriaux AIR pour vous aider à mettre en place ces processus de transaction:
AIR SQLite – Utilisation des transactions (begin / commit / rollback) en synchrone
AIR SQLite – Utilisation des transactions (begin / commit / rollback) en asynchrone
Préciser le nom de la base de données dans chaque requête
Dans un fichier contenant une base SQLite, vous pouvez avoir plusieurs bases de données. De base, si vous ne préfixez pas le nom de votre database, la database "main" (database par défaut) sera utilisée. Même si vous n'utilisez qu'une database, ajouter "main" devant le nom de votre table va accélérer le traitement car le moteur d'exécution n'aura pas besoin de déterminer dans quelle database se trouve votre table.
Au lieu d'utiliser
SELECT employeeId FROM employees
utilisez donc
SELECT employeeId FROM main.employees
Toujours préciser le nom des colonnes à récupérer dans un SELECT ou un INSERT
Vous connaissez sûrement le nom de colonnes que vous allez récupérer lorsque vous faîtes un SELECT ou un INSERT. Au lieu d'utiliser "*", il est préférable de spécifier le nom des colonnes à récupérer, encore une fois pour éviter que le runtime doive les déterminer lui-même (coûteux)
Paginer la récupération de résultat (SELECT)
Si vous devez récupérer des centaines / milliers d'enregistrement, il est préférable de découper ce processing grâce à un système de pagination. Ce process est décrit dans l'article suivant:
AIR SQLite – Paginer la récupération d'un SELECT avec le paramètre prefetch (pagination)
De la même manière, si l'utilisateur ne voit au départ que 10 résultats, vous pouvez récupérer les 10 premiers puis récupérer les suivants dans un processus en arrière-plan qui donnera une illusion de rapidité.
Utiliser des index de manière judicieuse
L'utilisation des index est une règle générale en SQL mais celle-ci doit être utilisée avec parcimonie. Il est notamment utile sur des colonnes sur lesquelles vous allez utiliser une clause WHERE. Par exemple sur une colonne sur laquelle vous allez effectuer une recherche à partir d'une entrée utilisateur. Si vous recherchez sur 2 colonnes (first name et last name par exemple), il est préférable d'indexer une colonne qui fait la concaténation des 2 plutôt que d'indexer chaque colonne.
Vous pouvez aussi utiliser la méthode "analyse()" sur une SQLConnection pour aider la database à préparer les futurs traitements:
Éviter les changements de structure
Cette considération peut-être difficile à appliquer mais il faut savoir que les changements de structures de tables (ajout de colonnes, ajout de table, …) peuvent avoir un aspect négatif sur les performances de votre application.
En effet, une base SQLite est conservé sur le disque sous forme de fichier. Lorsque vous modifiez la structure de la base, ces modifications vont être écrites à la fin du fichier. Lorsque la base va essayer de déterminer les colonnes d'une table par exemple, le traitement sera plus long si la donnée est éparpillée dans le fichier. C'est un peu comme le processus de fragmentation sous Windows.
Pour résoudre ce problème et "dé-fragmenter" la base SQL, vous pouvez exécuter un SQLConnection::compact() sur la base de données afin de rassembler les définitions. Attention, plus votre base est grande, plus cette opération sera coûteuse.
Ressources
Voici quelques ressources pour vous aider à optimiser votre base SQLite:
Articles similaires
- AIR SQLite – Exécution de requêtes SQL SQLStatement et syntaxe
- AIR SQLite – Mode synchrone et asynchrone
- AIR SQLite – Insertion de données dans une table avec INSERT (unique et multiples)
- AIR SQLite – Création d'une base de données SQLite
- AIR SQLite – Utilisation des transactions (begin / commit / rollback) en synchrone
Mes projets (Open Source)
Autres
