Sqlite sur un partage réseau
Quelqu'un a-t-il une expérience du monde réel dans l'exécution d'une base de données Sqlite sur un partage SMB) sur un réseau local (Windows ou Linux)?
Il ressort clairement de la documentation que ce n'est pas vraiment le moyen le plus rapide de partager une base de données Sqlite.
Les mises en garde évidentes sont que cela peut être lent, et Sqlite ne prend en charge qu'un seul thread écrivant dans la base de données à la fois. Ainsi, vous devenez beaucoup moins simultané car vos mises à jour de base de données bloquent maintenant la base de données plus longtemps (la base de données sera verrouillée pendant que les données sont en transit sur le réseau).
Pour mon application, la quantité de données que je souhaite partager est assez petite et les écritures ne sont pas trop fréquentes (quelques écritures toutes les quelques secondes au plus).
À quoi dois-je faire attention? Cela peut-il fonctionner?
Je sais que ce n'est pas pour cela que Sqlite a été conçu, je suis moins intéressé par une solution basée sur Postgres/MySql/Sql Server car j'essaie de garder mon application aussi légère que possible avec un minimum de dépendances.
Liens connexes:
De la liste de diffusion sqlite , donc je suppose qu'une grande question est de savoir dans quelle mesure les apis filelock sont peu fiables sur SMB (windows ou linux)
Mon expérience des bases de données basées sur des fichiers (c'est-à-dire celles sans processus de serveur de base de données), qui remonte à plus de vingt ans, est que si vous essayez de les partager, elles inévitablement finit par être corrompu. Je vous suggère fortement de revoir MySQL.
Et veuillez noter que je ne choisis pas SQLite - je l'utilise moi-même, mais pas comme base de données partagée.
Eh bien, je ne suis pas un grand expert de sqlite mais je pense que le verrouillage des enregistrements/tables peut ne pas fonctionner correctement et peut corrompre la base de données. Parce qu'il n'y a pas de serveur unique qui maintient le verrouillage central, deux instances de DLL sqlite sur des machines différentes partageant le même fichier sur le réseau peuvent ne pas fonctionner correctement du tout. Si la base de données est ouverte sur la même machine, sqlite peut utiliser le verrouillage au niveau du fichier offert par le système d'exploitation pour maintenir l'intégrité, mais je doute que cela fonctionne correctement sur le partage réseau.
"Si de nombreux programmes clients accèdent à une base de données commune sur un réseau, vous devez envisager d’utiliser un moteur de base de données client/serveur au lieu de SQLite. SQLite fonctionnera sur un système de fichiers réseau, mais en raison de la latence associée à la plupart des systèmes de fichiers réseau, les performances seront pas génial. De plus, la logique de verrouillage de fichier de l'implémentation de nombreux systèmes de fichiers réseau contient des bogues (sous Unix et Windows). Si le verrouillage de fichier ne fonctionne pas comme il se doit, il est possible que deux ou plusieurs programmes clients modifient la même partie de la même base de données en même temps, ce qui entraîne une corruption de la base de données. Étant donné que ce problème résulte de bogues dans l'implémentation du système de fichiers sous-jacent, SQLite ne peut rien faire pour l'empêcher. "
de https://www.sqlite.org/whentouse.html
qui s'applique également à tout type de bases de données basées sur des fichiers comme Microsoft Access
Vous avez demandé une expérience du monde réel. En voici quelques-uns:
Le verrouillage SQLite est robuste, en supposant que le système de fichiers sous-jacent (en réseau) est également robuste. Historiquement, c'était une mauvaise hypothèse. Les systèmes d'exploitation récents s'améliorent beaucoup.
Si vous respectez les règles, votre plus gros problème sera les cas où la base de données reste "verrouillée" pendant plusieurs minutes d'affilée. Par exemple, si le réseau abandonne une demande de "déverrouillage" d'un lecteur, il se peut que vous ne puissiez pas écrire jusqu'à ce que le verrou expire. Si un "déverrouillage" d'un écrivain disparaît, vous ne pourrez pas lire. (Pour être honnête, vous pouvez rencontrer les mêmes problèmes avec des documents ordinaires.)
Vous aurez moins de problèmes sur un bon réseau fiable avec le "verrouillage opportuniste" (mise en cache des fichiers au niveau du client) désactivé pour la base de données.