SQLite en un servidor de producción? [cerrado]

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

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.

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.