Pourquoi les écritures simultanées ne sont-elles pas autorisées sur une base de données SQLite?

Je fais de la programmation de base de données en utilisant Java avec SQLite.

J'ai constaté qu'une seule connexion à la fois à la base de données permettait l'écriture, alors que de nombreuses connexions disposaient simultanément d'une capacité de lecture.

Pourquoi l'architecture de SQLite a-t-elle été conçue comme ceci? Tant que les deux choses en cours d'écriture ne sont pas écrites au même endroit dans la base de données, pourquoi deux écritures ne peuvent-elles pas se produire en même temps?

database concurrency sqlite

— Embout d'acier
source

liées (éventuellement un doublon): SQLite avec deux processus python y accédant: un en lecture, une en écriture

— gnat le

Parce que SQLite a été conçu pour être "allégé". Faible mémoire et faible traitement avec performance. Réfléchissez à la façon dont vous feriez en sorte que SQLite gère plusieurs écritures dans le même fichier. La conception actuelle est facile à mettre en œuvre - le fichier entier est verrouillé et les autres doivent attendre. Pour gérer les accès simultanés en écriture à un niveau de granularité plus bas, il faut verrouiller les lignes / pages, ce que vous obtenez du RDMS. Si l'exigence exige l'accès simultané en écriture, SQLite n'est pas un candidat. Vous devriez plutôt vous tourner vers un SGBDR léger: fr.wikipedia.org/wiki/…

— Thomas Carlisle le

Réponses:

157

Parce que "plusieurs écritures simultanées" est beaucoup, beaucoup plus difficile à accomplir dans le moteur de base de données de base qu'un simple écrivain, plusieurs lecteurs. Cela va au-delà des paramètres de conception de SQLite, et son inclusion risquerait de nuire à la taille et à la simplicité délicieuses de SQLite.

La prise en charge de niveaux élevés de concurrence d'accès en écriture est l'une des caractéristiques des moteurs de base de données volumineux tels que DB2, Oracle, SQL Server, MySQL, PostgreSQL, NonStop SQL et Sybase. Mais il est techniquement difficile à réaliser, nécessitant de nombreuses stratégies d'optimisation du contrôle de la concurrence, telles que le verrouillage de bases de données, de tables et de lignes, ou, dans les implémentations plus modernes, le contrôle de simultanéité multi-version . La recherche sur ce problème / besoin est volumineuse et remonte à plusieurs décennies .

SQLite a une philosophie de conception très différente de la plupart de ces SGBD centrés sur le serveur qui prennent en charge plusieurs rédacteurs. Il est conçu pour apporter la puissance de SQL et du modèle relationnel à des applications individuelles, et même pour pouvoir être intégré dans chaque application. Cet objectif nécessite des compromis importants. L'une de celles-ci consiste à ne pas ajouter l'infrastructure importante et les frais généraux nécessaires pour gérer plusieurs enregistreurs simultanés.

La philosophie peut être résumée par une déclaration sur la page des utilisations appropriées de SQLite :

SQLite ne concurrence pas les bases de données client / serveur. SQLite est en concurrence avec fopen ().

— Jonathan Eunice
source

+1 SQLite est une base de données en cours de traitement. Il n'y a pas d'arbitre central comme dans une base de données basée sur serveur. Les écrivains devraient coopérer directement et se faire confiance. Un seul auteur mal intentionné pourrait faire des ravages simplement en ne coopérant pas.

— Jörg W Mittag le

De plus, certains environnements exécutés par SQLite peuvent même ne pas prendre en charge plusieurs processus.

— david25272

Vraisemblablement, une écriture malveillante peut déjà causer des ravages en ne coopérant pas. Ils ne peuvent pas utiliser le code SQLite pour le faire, mais ils peuvent avoir leur propre code, qui pourrait simplement être un appel à unlink ()

— bdsl

Dans les applications simultanées, il n'y a pas beaucoup de terrain d'entente. Soit vous bénéficiez de la concurrence, de la cohérence et de l'intégrité des données pratiquement dans 100% des cas, y compris dans des conditions difficiles et dans des cas extrêmes, ou non. Si vous ne le faites pas, le système est fragile, lent et sujet aux accidents, et les gens cessent de lui faire confiance très rapidement. Cependant, il est extrêmement difficile de bien faire les choses régulièrement. Il n’existe que très peu de circonstances dans lesquelles les écrivains peuvent, sans un soutien important, coordonner eux-mêmes des écritures entrelacées.

— Jonathan Eunice

@bdsl Les bases de données de toutes sortes doivent supposer que les rédacteurs ne se comporteront pas bien pour ne pas perdre de données. Les auteurs SQLite se positionnent comme un concurrent fopen(), alors considérez toute la pilosité qui vient avec l’écriture simultanée dans un fichier texte.

— Blrfl

Parce qu’aucun serveur ne peut dire si des choses doivent être écrites au même endroit ou non. Il n'y a que deux processus essayant d'écrire dans un fichier.

Comme indiqué dans un commentaire, les écritures simultanées peuvent également être prises en charge par un thread interne. Je ne sais pas si cela fonctionnerait bien (je n'y ai pas beaucoup réfléchi non plus). Quoi qu'il en soit, voici pourquoi SQLite n'utilise pas de thread: Dr Hipp pense que les thread sont diaboliques.

Le fait que DR Hipp pense que les threads sont diaboliques est documenté dans la FAQ SQLite .

— Goyo
source

Cela explique la raison technique pour laquelle les écritures simultanées ne sont pas autorisées, mais pas pourquoi la décision de conception a été prise.

— Robert Harvey

La décision de concevoir SQLite de manière à ce qu’elle ne gère qu’une écriture à la fois.

— Robert Harvey

@Goyo, un serveur n'est pas obligé de gérer les écritures simultanées: tout comme un serveur de base de données est un processus séparé, il peut exister un thread distinct interne à SQLite ayant le même objectif. Robert Harvey a raison: l'équipe de SQLite a pris une décision de conception et cela n'a rien à voir avec la capacité d'une seule bibliothèque de gérer des écritures simultanées (parce que c'est possible, en théorie).

Cette réponse me semble bien. Pour gérer les écritures simultanées, il semble qu'il faille utiliser un serveur ou une implémentation multi-thread SQLite. Étant donné que ces deux solutions ont été exclues par d'autres décisions de conception, il serait extrêmement difficile de mettre en œuvre des écritures simultanées.

— Jpa

@jpa: SQLite parvient à synchroniser le verrouillage entre plusieurs processus / threads sans "serveur" déjà. Un "serveur" n'est pas nécessaire - à l'aide du verrouillage / synchronisation / IPC / fourni par le système d'exploitation, mais devient très vite complexe. Le "fil intérieur" mentionné dans l'article n'a pas de sens.

— Mat