6
Para evitar que una base de datos en memoria SQLite se limpie, se debe usar la misma conexión para acceder a la base de datos. Sin embargo, usar la misma conexión hace que SQLite sincronice el acceso a la base de datos. Por lo tanto, si tengo muchos subprocesos que realizan lecturas en una base de datos en memoria, es más lento en una máquina multinúcleo que el mismo código exacto que se ejecuta en una base de datos respaldada por archivos.¿Pueden las bases de datos SQLite en memoria escalar con concurrencia?
¿Hay alguna manera de obtener lo mejor de ambos mundos? Es decir, ¿una base de datos en memoria que permite múltiples llamadas concurrentes a la base de datos?
Eso solo significa que es seguro de usar desde varios hilos. Puedo dar fe de ello. Pero no escala, usa solo un núcleo de mi doble núcleo. Entonces es seguridad a expensas del rendimiento. Actualizando mi título para aclarar –
"usa solo un núcleo" - ¡significa que sus hilos fueron enviados de esa manera! Esto puede deberse a un bloqueo interno u otra sincronización en sqlite. Si realmente quieres la concurrencia DB + debes considerar algún código personalizado con descarga final a la base de datos compartida. Creo que quieres de sqlite demasiado. – Andrey
El punto es que funciona con una base de datos SQLite basada en archivos (100% de consumo de CPU), pero no con una base de datos en memoria. Si SQLite no es compatible con este escenario, está bien, pero necesito una cita. –