Hace mucho tiempo que conozco SQLite y sé que es increíblemente rápido, pero nunca lo he probado en un servidor de producción. Nunca pude encontrar una estimación sólida sobre cuánto tráfico podría manejar antes de fallar.
¿Alguien tiene algún número o un artículo sobre esto?
Desafortunadamente, no tengo cifras para usted sobre las capacidades de carga, pero algunos comentarios sobre algunos de los factores que restringen el rendimiento:
La velocidad de SQLite se ve afectada por la velocidad del disco en el que se encuentra y si hay muchas inserciones / actualizaciones (es decir, acceso de escritura). El bloqueo de escritura está limitado por la velocidad de giro del disco
Las transacciones se inician de forma predeterminada, pero se obtiene un mejor rendimiento si se iniciar y confirmar la transacción. He tenido inserciones masivas muy rápidas al manejar la transacción mediante programación
Si, en general, solo está leyendo datos, obtendrá un buen rendimiento en mi experiencia. Por lo tanto, SQLite se puede usar como un sistema de almacenamiento en caché para almacenar lecturas del servidor de bases de datos, particularmente remotas o consultas complejas.
Utiliza menos recursos que un servidor de base de datos, por lo que esto puede afectar el rendimiento del sitio al liberar más recursos para el servidor web y el código de la aplicación
Si necesita varias escrituras concurrentes para que sea posible, entonces un servidor de base de datos (por ejemplo, MySQL, Postgres) puede servirle mejor
Como dijo Devrim , el sitio SQLite afirma que alrededor de 100k usuarios / día deberían estar bien. Un sistema Trac requiere escrituras, por lo que el rendimiento probablemente sería más lento en ese caso
Gracias por las respuestas, ¿entonces básicamente solo puedes escribir en la base de datos 1 a la vez? ¿Pero aún puede hacer que varias personas lean de la base de datos sin bloquearse? Si es así, acabo de recibir algunas ideas para un sistema de almacenamiento en caché.
Dr Hydralisk
El número "100K" que se arroja es inútil. Los documentos dicen "En términos generales, cualquier sitio que obtenga menos de 100K visitas / día debería funcionar bien con SQLite". Un "hit" generalmente se define como una solicitud HTTP. Esto incluye una solicitud para cada .js, .css e imagen de un hit. ¿Qué tiene esto que ver con el rendimiento de la base de datos? Asumiendo que los autores significan "vista de página", sigue siendo inútil. ¿Cuántas consultas por página vista? Proporción de lecturas a escrituras? ¿En qué tipo de hardware se está ejecutando el DB? No es una buena idea usar SQLite para un sitio web cuando hay al menos una docena de otras herramientas mejores para el trabajo.
jamieb
@Dr Hydralisk Sí, las lecturas pueden ocurrir en paralelo ... como un archivo
Cez
@jamieb El punto sobre los "éxitos" es justo. Sin embargo, nadie ha mencionado qué recursos de hardware o servidor están disponibles, por lo que podría ser un pequeño servidor virtual para todo lo que sabemos. La participación de bases de datos SQLite en un sistema de almacenamiento en caché, o principalmente tablas de solo lectura, puede brindar beneficios de rendimiento, particularmente cuando el servidor de la base de datos es remoto. La memoria caché + caché SQLite de las consultas de la base de datos superará las consultas de la base de datos solo.
Cez
3
Tengo algunos puntos que agregar a estas buenas respuestas.
La versión actual de SQLite tiene WAL (Registro de escritura anticipada) para que la lectura y la escritura puedan continuar simultáneamente. Por lo tanto, la limitación tradicional de escritor único mencionada en las respuestas anteriores ya no existe. Todavía no he visto WAL en producción, así que no puedo comentar qué tan bien escala.
Usando WAL o no, si su base de datos SQLite es de solo lectura (o se actualiza por lotes) y cabe en la RAM (su sistema operativo tiene suficiente RAM de reserva para mantenerla en los buffers), puede escalar muy bien en una aplicación web de producción. Personalmente, era muy escéptico sobre su rendimiento, escalabilidad y robustez, pero ahora, después de nueve meses de producción , ha demostrado que funciona muy bien incluso las partes más complejas del sistema .
Sqlite es ideal para incrustar en aplicaciones, y para eso está diseñado, pero ciertamente no es "increíblemente rápido". Lo uso para varias de mis propias aplicaciones, solo por la conveniencia de tener solo dos archivos que se pueden copiar en otra máquina para proporcionar una aplicación que funcione completamente. Las pruebas contra MySQL, utilizando la misma estructura, índices, etc., muestran que Sqlite es considerablemente más lento, incluso para bases de datos pequeñas. Esperaría que la diferencia de rendimiento crezca a medida que crece el tamaño de la base de datos, aunque no puedo decirlo con certeza, ya que solo lo he usado con bases de datos de menos de 100 MB.
PRAGMA se puede ajustar para aumentar el rendimiento a expensas de corromper ocasionalmente la base de datos (aunque sin perder datos). En mi experiencia, pude hacer que SQLite tomara inserciones a aproximadamente 250-300rps en una vieja máquina WindowsXP.
djangofan
-1, porque no estoy de acuerdo. He creado y consultado bases de datos SQLite de varios GB de tamaño y nunca obtendría la misma cantidad de consultas por segundo usando MySQL, por ejemplo (en el mismo tipo de hardware). SQLite puede hacer fácilmente 120k consultas de escritura por segundo si sabe cómo masajearlo correctamente .
Alix Axel
0
Creo que sqlite es solo más rápido que un archivo de texto / xml (puede que se sorprenda si lo intenta). Y no es compatible con la concurrencia, si desea crear un sitio para la intranet donde las personas registren sus horas de trabajo o usen el boleto de tránsito, puede ser útil. Aparte de eso, debe evitarse y reemplazarse por mysql o couchdb.
El sitio web sqlite dice que 100k usuarios / día deberían estar bien, pero lo dudo mucho, ya que un simple proyecto de seguimiento se atasca mucho con el uso de la oficina de 10 personas.
Sqlite no es una aplicación de base de datos cliente / servidor tradicional. Es esencialmente una biblioteca que está incrustada dentro de otra aplicación. Está diseñado para aplicaciones de escritorio de un solo usuario. Absolutamente no desea intentar usarlo como una especie de reemplazo independiente de MySQL / PostgreSQL / MS-SQL en un entorno multiusuario porque toda la base de datos está bloqueada en escritura. Se ocupará de problemas de contención incluso con una carga ligera que destruirá el rendimiento.
En WAL, solo los escritores concurrentes están bloqueados. Además, el motor MySQL predeterminado (MyISAM) también bloquea las tablas completas cuando hay una consulta de escritura.
Alix Axel
1
@AlixAxel Esta respuesta se escribió seis meses antes de que WAL estuviera disponible.
Respuestas:
Desafortunadamente, no tengo cifras para usted sobre las capacidades de carga, pero algunos comentarios sobre algunos de los factores que restringen el rendimiento:
La velocidad de SQLite se ve afectada por la velocidad del disco en el que se encuentra y si hay muchas inserciones / actualizaciones (es decir, acceso de escritura). El bloqueo de escritura está limitado por la velocidad de giro del disco
Las transacciones se inician de forma predeterminada, pero se obtiene un mejor rendimiento si se iniciar y confirmar la transacción. He tenido inserciones masivas muy rápidas al manejar la transacción mediante programación
Si, en general, solo está leyendo datos, obtendrá un buen rendimiento en mi experiencia. Por lo tanto, SQLite se puede usar como un sistema de almacenamiento en caché para almacenar lecturas del servidor de bases de datos, particularmente remotas o consultas complejas.
Utiliza menos recursos que un servidor de base de datos, por lo que esto puede afectar el rendimiento del sitio al liberar más recursos para el servidor web y el código de la aplicación
Si necesita varias escrituras concurrentes para que sea posible, entonces un servidor de base de datos (por ejemplo, MySQL, Postgres) puede servirle mejor
Como dijo Devrim , el sitio SQLite afirma que alrededor de 100k usuarios / día deberían estar bien. Un sistema Trac requiere escrituras, por lo que el rendimiento probablemente sería más lento en ese caso
fuente
Tengo algunos puntos que agregar a estas buenas respuestas.
La versión actual de SQLite tiene WAL (Registro de escritura anticipada) para que la lectura y la escritura puedan continuar simultáneamente. Por lo tanto, la limitación tradicional de escritor único mencionada en las respuestas anteriores ya no existe. Todavía no he visto WAL en producción, así que no puedo comentar qué tan bien escala.
Usando WAL o no, si su base de datos SQLite es de solo lectura (o se actualiza por lotes) y cabe en la RAM (su sistema operativo tiene suficiente RAM de reserva para mantenerla en los buffers), puede escalar muy bien en una aplicación web de producción. Personalmente, era muy escéptico sobre su rendimiento, escalabilidad y robustez, pero ahora, después de nueve meses de producción , ha demostrado que funciona muy bien incluso las partes más complejas del sistema .
fuente
Sqlite es ideal para incrustar en aplicaciones, y para eso está diseñado, pero ciertamente no es "increíblemente rápido". Lo uso para varias de mis propias aplicaciones, solo por la conveniencia de tener solo dos archivos que se pueden copiar en otra máquina para proporcionar una aplicación que funcione completamente. Las pruebas contra MySQL, utilizando la misma estructura, índices, etc., muestran que Sqlite es considerablemente más lento, incluso para bases de datos pequeñas. Esperaría que la diferencia de rendimiento crezca a medida que crece el tamaño de la base de datos, aunque no puedo decirlo con certeza, ya que solo lo he usado con bases de datos de menos de 100 MB.
fuente
Creo que sqlite es solo más rápido que un archivo de texto / xml (puede que se sorprenda si lo intenta). Y no es compatible con la concurrencia, si desea crear un sitio para la intranet donde las personas registren sus horas de trabajo o usen el boleto de tránsito, puede ser útil. Aparte de eso, debe evitarse y reemplazarse por mysql o couchdb.
El sitio web sqlite dice que 100k usuarios / día deberían estar bien, pero lo dudo mucho, ya que un simple proyecto de seguimiento se atasca mucho con el uso de la oficina de 10 personas.
fuente
Sqlite no es una aplicación de base de datos cliente / servidor tradicional. Es esencialmente una biblioteca que está incrustada dentro de otra aplicación. Está diseñado para aplicaciones de escritorio de un solo usuario. Absolutamente no desea intentar usarlo como una especie de reemplazo independiente de MySQL / PostgreSQL / MS-SQL en un entorno multiusuario porque toda la base de datos está bloqueada en escritura. Se ocupará de problemas de contención incluso con una carga ligera que destruirá el rendimiento.
fuente