Sqlite en una red compartida
sqlite syntax (4)
¿Alguien tiene experiencia en el mundo real al ejecutar una base de datos Sqlite en un recurso compartido SMB en una LAN (Windows o Linux)?
Está claro por la documentation que esta no es realmente la forma más rápida de compartir una base de datos Sqlite.
Las advertencias obvias son que puede ser lento, y Sqlite solo admite la escritura de un solo hilo en el DB a la vez. Por lo tanto, se vuelve mucho menos concurrente porque las actualizaciones de su base de datos ahora bloquearán la base de datos durante más tiempo (la base de datos se bloqueará mientras los datos estén en tránsito en la red).
Para mi aplicación, la cantidad de datos que me gustaría compartir es bastante pequeña y las escrituras no son demasiado frecuentes (algunas escrituras cada pocos segundos como máximo).
¿Qué debería tener cuidado? ¿Puede esto funcionar?
Sé que esto no es para lo que Sqlite fue diseñado, estoy menos interesado en una solución basada en Postgres / MySql / Sql Server ya que trato de mantener mi aplicación lo más ligera posible con una cantidad mínima de dependencias.
Enlaces relacionados:
De la lista de correo de sqlite , así que supongo que una gran pregunta es cuán poco confiables son las API de filelock sobre SMB (Windows o Linux)
"Si tiene muchos programas cliente accediendo a una base de datos común en una red, considere usar un motor de base de datos cliente / servidor en lugar de SQLite. SQLite funcionará en un sistema de archivos de red, pero debido a la latencia asociada con la mayoría de los sistemas de archivos de red, el rendimiento La lógica de bloqueo de archivos de muchas implementaciones de sistemas de archivos de red contiene errores (tanto en Unix como en Windows). Si el bloqueo de archivos no funciona como debería, es posible que dos o más programas cliente modifiquen la misma parte. de la misma base de datos al mismo tiempo, lo que resulta en daños en la base de datos. Debido a que este problema es el resultado de errores en la implementación subyacente del sistema de archivos, no hay nada que SQLite pueda hacer para evitarlo ".
de https://www.sqlite.org/whentouse.html
eso también aplica para cualquier tipo de bases de datos basadas en archivos como Microsoft Access
Bueno, no soy un gran experto en sqlite, pero creo que el bloqueo de registros / tablas puede no funcionar correctamente y puede dañar la base de datos. Debido a que no existe un único servidor que mantenga el bloqueo central, es posible que dos instancias sqlite dll en diferentes máquinas que comparten el mismo archivo a través de la red no funcionen correctamente. Si la base de datos se abre en la misma máquina, sqlite puede usar el bloqueo de nivel de archivo ofrecido por el sistema operativo para mantener la integridad, pero dudo si funciona correctamente a través de la red compartida.
Mi experiencia con las bases de datos basadas en archivos (es decir, aquellas sin un proceso de servidor de base de datos), que se remonta a más de veinte años, es que si intentas compartirlas, inevitablemente se corromperán. Te sugiero encarecidamente que mires a MySQL de nuevo.
Y, por favor, tenga en cuenta que no estoy escogiendo SQLite, lo uso yo mismo, pero no como una base de datos compartida.
Usted pidió experiencia en el mundo real. Aquí hay algunos:
El bloqueo de SQLite es robusto, ASUMIENDO que el sistema de archivos subyacente (en red) también es robusto. Históricamente, esa ha sido una suposición pobre. Los sistemas operativos recientes lo hacen mucho mejor.
Si sigue las reglas, su mayor problema serán los casos en que la base de datos permanezca "bloqueada" durante muchos minutos seguidos. Por ejemplo, si la red deja caer una solicitud de "desbloqueo" de un lector, es posible que no pueda escribir hasta que caduque. Si un "desbloqueo" de un escritor desaparece, no podrá leer. (Para ser justos, puede experimentar los mismos problemas con los documentos comunes).
Obtendrá menos problemas en una buena red confiable con "bloqueo oportunista" (caché de archivos a nivel de cliente) deshabilitado para la base de datos.