Transacciones
Editar la sección
No hay sobrecarga asociada con cada transacción. Cuando se ejecuta una SQL de forma aislada, una transacción implícita se crea alrededor de esa declaración. Cuando las transacciones se han comprometido, sqlite es el diario que requiere la sincronización de datos en el disco. Esta operación es extremadamente lento. Por lo tanto, si usted está haciendo muchas de las transacciones en una fila, obtendrás mejoras significativas en el rendimiento de las rodea en una transacción.
Si usted no está usando el almacenamiento en caché avanzadas más adelante, la caché de base de datos en memoria se borra al final de cada transacción. Esta es otra razón para utilizar las transacciones, incluso si sólo está ejecutando operaciones de lectura.
El asincrónico escribe discuten a continuación elimina la mayor parte de la pena inmediata de una comisión, por lo que no notará el problema como mucho. Sin embargo, todavía hay sobrecarga, y el uso de una transacción seguirá siendo más rápido. Un gran problema es que la cola de operaciones de archivo tendrá mucho tiempo si hay muchas operaciones. Algunas operaciones requieren caminar esta cola para ver qué operaciones han estado pendientes, y que será más lento. Si el usuario cierra el navegador pronto después de hacer este tipo de operaciones, puede retrasar el apagado (posiblemente durante decenas de segundos para que un gran número de transacciones y discos lentos), lo que hace que parezca que el navegador se cuelga.
Consultas
Reordenación de la atención de la declaración SQL, o la creación de los índices adecuada, a menudo puede mejorar el rendimiento. Véase la descripción general del optimizador sqlite en el sitio web de sqlite para información sobre cómo utiliza los índices de sqlite y ejecuta sentencias.
Usted también puede tratar de la "explicar" en función de sus estados de cuenta para ver si están utilizando los índices que usted espera. Tipo de "explicar", seguido de su estado de cuenta para ver el plan. Por ejemplo, explicar select * from moz_history; Los resultados son difíciles de entender, pero usted debería ser capaz de ver si es la utilización de índices. Un comando que le dará una visión general de alto nivel es "explicar plan de consulta". Por ejemplo:
sqlite> explain query plan select * from moz_historyvisit v join moz_history h
on v.page_id = h.id where v.visit_date > 1000000000;
0|0|TABLE moz_historyvisit AS v WITH INDEX moz_historyvisit_dateindex
1|1|TABLE moz_history AS h USING PRIMARY KEY
Esto nos dice que primero buscará en moz_historyvisit partir de un índice, y luego buscará en moz_history utilizando la clave principal. Ambas son "buenas" porque utilizan índices y claves principales, que son rápidos.
sqlite> explain query plan select * from moz_historyvisit where session = 12; 0|0|TABLE moz_historyvisit
En este ejemplo, se puede ver que no está usando un índice, por lo que esta consulta podría ser muy lento.
Caché
Sqlite tiene un caché de páginas de bases de datos en la memoria. Mantiene páginas relacionadas con la transacción actual por lo que puede hacer retroceder, y que además mantiene los utilizados recientemente para que pueda correr más rápido.
De forma predeterminada, sólo guarda las páginas en la memoria durante una operación (si no explícitamente abierta una transacción, será abierto para usted que rodea cada declaración individual). Al final de una transacción, el caché se vacía. Si, posteriormente, iniciar una nueva transacción, las páginas que necesita se volverá a leer el disco (o esperar que el caché de sistema operativo). Esto hace que incluso bloquear las operaciones simples en los archivos del SO lecturas, que pueden ser prohibitivos en algunos sistemas con cachés de disco malo o unidades de red.
Usted puede controlar el tamaño de la caché de memoria mediante el cache_sizepragma. Este valor controla el número de páginas del archivo que se puede guardar en la memoria a la vez. El tamaño de página se pueden establecer mediante el page_size pragma antes de que las operaciones se han realizado en el archivo. Puede ver un ejemplo de establecer el tamaño máximo de caché a un porcentaje de la memoria en nsNavHistory:: initdb en toolkit / components / places / src / nsNavHistory.cpp.
El almacenamiento en caché
Activa el modo de almacenamiento para sqlite shared-cache mode), que hace varias conexiones a la parte misma base de datos la misma caché. Debido a que el caché no es multi-hilo, esto significa que por desgracia no se puede tener diferentes conexiones desde diferentes subprocesos el acceso a la misma base de datos. Sin embargo, la memoria caché compartida que nos permite seguir en directo entre las operaciones, en lugar de borrarlo después de cada transacción como sqlite no por defecto.
Si su aplicación utiliza muchas transactons pequeña, puede obtener una mejora significativa del rendimiento al mantener el caché en vivo entre las transacciones. Esto se hace mediante el uso de un suplemento "ficticia" la conexión a la misma base de datos (es importante que utilice exactamente el mismo nombre de archivo al abrir estas conexiones según lo determinado por
strcmp). La conexión ficticia mantiene una transacción perpetuamente abierta, que bloquea el caché en la memoria. Dado que el caché es compartida con la conexión principal, el caché nunca expira. La transacción debe ser un maniquí que bloquea una página en la memoria. Una simple instrucción
BEGIN TRANSACTION no hace esto porque el bloqueo no sqlite perezosamente. Por lo tanto, debe tener una declaración que modifica los datos. Puede ser tentador para ejecutar una declaración sobre la sqlite_master que contiene la información sobre las tablas e índices en la base de datos. Sin embargo, si su aplicación se está inicializando la base de datos por primera vez, esta tabla estará vacía y la caché no estará bloqueado. nsNavHistory:: StartDummyStatement crea una tabla de maniquí con un solo elemento en él para este fin. Es importante señalar que cuando una instrucción está abierta, el esquema de base de datos no pueden ser modificados. Esto significa que cuando la operación simulada se está ejecutando, no puede crear o modificar las tablas o índices, o el vacío de la base de datos. Usted tiene que parar la operación simulada, hacer la operación de modificación de esquema, y reiniciarlo.
Escrituras en disco
Sqlite establece las normas básicas de la teoría ACID base de datos:
- Atomicidad: cada transacción es atómica y no puede ser "parcialmente" cometidos.
- Consistencia: la base de datos no se corrompe.
- Aislamiento: varias transacciones no se afectan entre sí.
- Durabilidad: una vez ha pasado por cometer, los datos se garantiza que sea cometido.
Pasar la aspiradora y cero de relleno
Sqlite tiene un comando VACUUM para comprimir el espacio no utilizado de la base de datos. Sqlite funciona como un administrador de memoria o un sistema de archivos. Cuando se eliminan datos, los bytes asociados se marcan como libres, pero no se quita del archivo. Esto significa que el archivo no se reducirá, y los datos todavía pueden ser visibles en el archivo. La manera de evitar esto es ejecutar el comando de vacío para eliminar este espacio.
Pasar la aspiradora es muy lenta. El comando de vacío es esencialmente la misma que la línea de comandos sqlite3 olddb. Volcado
sqlite3 olddb .dump | sqlite3 newdb; mv newdb olddb.En algunas unidades de red, pasar la aspiradora una base de datos de 10 MB ha sido el tiempo en más de un minuto. Por lo tanto, debe evitar siempre que sea posible pasar la aspiradora. Algunos artículos de bases de datos son la privacidad sensibles, como los elementos eliminados de la historia. Los usuarios tienen la expectativa de que a borrar los elementos de su historia será eliminar los restos de que a partir de la base de datos. Como resultado, Mozilla permite la bandera preprocesador
SQLITE_SECURE_DELETE en db/sqlite3/src/Makefile.in .Esta opción hace que los elementos eliminados para ser llenado con 0s en el disco. Esto elimina la necesidad de vacío, excepto para recuperar espacio en disco, y hace que muchas operaciones mucho más rápido. Zero-llenado pueden tener sobrecarga de rendimiento significativas en algunas situaciones. Por ejemplo, el servicio de la historia usa para eliminar varios elementos de base de datos cuando se apaga cuando expira elementos antiguos de la historia. Esta operación no es necesariamente lento, pero 0s escribir en el disco en un "ACI" base de datos todavía son lentos. Esto hizo que cierre muy lento porque el hilo AsyncIO bloquearía apagado (bug 328598). tiempos de parada de más de 30 segundos fueron vistos. Como resultado, este error introducido la historia de caducidad incremental eliminando la necesidad de escribir muchas 0s en el disco en el apagado.
Desafortunadamente, esta operación no puede ser controlado en un esquema por transacción o cada conexión. Algunas operaciones se beneficiarán, mientras que otros serán afectados.