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
fuente
Respuestas:
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 :
fuente
fopen(), por lo tanto, considere toda la delicadeza que viene con la escritura concurrente en un archivo de texto sin formato.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 .
fuente