¿Por qué no se permiten escrituras concurrentes en una base de datos SQLite?

Estoy haciendo programación de bases de datos usando Java con SQLite.

He descubierto que solo una conexión a la vez a la base de datos tiene capacidades de escritura, mientras que muchas conexiones a la vez tienen capacidad de lectura.

¿Por qué la arquitectura de SQLite se diseñó así? Mientras las dos cosas que se escriben no se escriben en el mismo lugar en la base de datos, ¿por qué no pueden ocurrir dos escrituras a la vez?

database concurrency sqlite

— Puntera de acero
fuente

relacionado (posiblemente un duplicado): SQLite con dos procesos de Python para acceder a él: una lectura, una escritura

— mosquito

Porque SQLite fue diseñado para ser "lite". Baja memoria y bajo procesamiento con rendimiento. Piense cómo haría que SQLite manejara múltiples escrituras en el mismo archivo. El diseño actual es fácil de implementar: todo el archivo está bloqueado y otros tienen que esperar. Para manejar la concurrencia de escritura en un nivel inferior de granularidad se requiere el bloqueo de fila / página que se obtiene de los RDMS. Si el requisito exige concurrencia de escritura, entonces SQLite no es un candidato y, en su lugar, debería buscar RDBMS ligero: en.wikipedia.org/wiki/…

— Thomas Carlisle

Respuestas:

157

Debido a que "múltiples escrituras concurrentes" es mucho, mucho más difícil de lograr en el motor de base de datos central que un solo escritor, un lector múltiple. Está más allá de los parámetros de diseño de SQLite, e incluirlo podría subvertir el tamaño y la simplicidad deliciosamente pequeños de SQLite.

El soporte de altos grados de concurrencia de escritura es un sello distintivo de los grandes motores de bases de datos como DB2, Oracle, SQL Server, MySQL, PostgreSQL, NonStop SQL y Sybase. Pero es técnicamente difícil de lograr, ya que requiere un amplio control de concurrencia y estrategias de optimización tales como bloqueo de bases de datos, tablas y filas o, en implementaciones más modernas, control de concurrencia de múltiples versiones . La investigación sobre este problema / requisito es voluminosa y se remonta a décadas .

SQLite tiene una filosofía de diseño muy diferente de la mayoría de esos DBMS centrados en el servidor que admiten múltiples escritores. Está diseñado para llevar el poder de SQL y el modelo relacional a aplicaciones individuales y, de hecho, para integrarse en cada aplicación. Ese objetivo requiere compensaciones significativas. No agregar la importante infraestructura y los gastos generales necesarios para manejar múltiples escritores concurrentes es uno de esos.

La filosofía se puede resumir mediante una declaración en la página de usos apropiados de SQLite :

SQLite no compite con las bases de datos cliente / servidor. SQLite compite con fopen ().

— Jonathan Eunice
fuente

+1. SQLite es una base de datos en proceso. No hay un árbitro central como el que hay en una base de datos basada en servidor. Los escritores tendrían que cooperar y confiar directamente entre ellos. Un solo escritor malintencionado podría causar estragos con solo no cooperar.

— Jörg W Mittag

Además, algunos de los entornos en los que se ejecuta SQLite pueden incluso no admitir múltiples procesos.

— david25272

Presumiblemente, una escritura maliciosa ya puede causar estragos al no cooperar. No pueden usar el código SQLite para hacerlo, pero pueden tener su propio código, que podría ser solo una llamada a unlink ()

— bdsl

En aplicaciones concurrentes, no hay mucho terreno intermedio. O obtienes concurrencia, consistencia e integridad de datos correctamente esencialmente el 100% del tiempo, incluso en condiciones difíciles y casos extremos, o no. Si no lo hace, es frágil, lento y propenso a los choques, y la gente deja de confiar en él muy rápidamente. Pero hacerlo rutinariamente correcto es endiabladamente difícil. No hay muchas circunstancias en las que los escritores puedan, sin un montón de soporte básico, coordinar las escrituras entrelazadas por su cuenta.

— Jonathan Eunice el

@bdsl Las bases de datos de cualquier tipo deben asumir que los escritores no se comportarán bien para que no pierdan datos. Los autores SQLite lo posicionan como un competidor fopen(), por lo tanto, considere toda la delicadeza que viene con la escritura concurrente en un archivo de texto sin formato.

— Blrfl

Porque no hay un servidor que pueda decir si las cosas se escribirán en el mismo lugar o no. Solo hay dos procesos que intentan escribir en un archivo.

Como se señaló en un comentario, las escrituras concurrentes también podrían ser compatibles con un hilo interno. No estoy seguro de qué tan bien funcionaría esto (tampoco lo pensé demasiado). De todos modos, aquí es por qué SQLite no usa hilos: el Dr. Hipp piensa que los hilos son malvados.

El hecho de que DR Hipp piense que los hilos son malos está documentado en las Preguntas frecuentes de SQLite .

— Goyo
fuente

Esto explica la razón técnica por la cual no se permiten escrituras concurrentes, pero no por qué se tomó la decisión de diseño.

— Robert Harvey

La decisión de diseñar SQLite para que solo maneje una escritura a la vez.

— Robert Harvey

@Goyo no se requiere un servidor para manejar escrituras concurrentes: al igual que un servidor de base de datos es un proceso separado, podría haber un hilo interno separado de SQLite que sirva para el mismo propósito. Robert Harvey está en lo correcto: hubo una decisión de diseño tomada por el equipo de SQLite, y no tiene nada que ver con la capacidad de una sola biblioteca para manejar escrituras concurrentes (porque puede, en teoría).

Esta respuesta me parece bien. Para manejar escrituras concurrentes, parece que uno necesitaría tener un servidor o una implementación sqlite multi-thread. Debido a que ambas han sido descartadas por otras decisiones de diseño, implementar escrituras concurrentes sería extremadamente difícil.

— jpa

@jpa: SQLite logra sincronizar el bloqueo entre varios procesos / subprocesos sin un "servidor" ya. No se requiere un "servidor": el uso de bloqueo / sincronización / IPC / lo proporcionado por el sistema operativo es suficiente, pero se vuelve complejo muy rápido. El "hilo interno" mencionado en la publicación no tiene sentido.

— Mat