que - sqlite tutorial

¿Qué tan escalable es SQLite? (11)

¿Has leído estos documentos SQLite - http://www.sqlite.org/whentouse.html ?

SQLite generalmente funcionará muy bien como el motor de base de datos para sitios web de tráfico bajo a mediano (es decir, el 99,9% de todos los sitios web). La cantidad de tráfico web que puede manejar SQLite depende, por supuesto, de la cantidad de veces que el sitio web utiliza su base de datos. En términos generales, cualquier sitio que obtenga menos de 100.000 visitas / día debería funcionar bien con SQLite. La cifra 100K hits / day es una estimación conservadora, no un límite superior difícil. Se ha demostrado que SQLite funciona con 10 veces esa cantidad de tráfico.

Hace poco leí esta pregunta sobre SQLite frente a MySQL y la respuesta señaló que SQLite no escala bien y, sin embargo, el tipo de sitio web oficial lo confirma .

¿Cuán escalable es SQLite y cuáles son sus límites superiores?

Ayer publiqué un pequeño sitio ^* para rastrear tu representante que utilizaba una base de datos SQLite compartida para todos los visitantes. Desafortunadamente, incluso con la carga modesta que puso en mi host, funcionó con bastante lentitud. Esto se debe a que toda la base de datos estaba bloqueada cada vez que alguien veía la página porque contenía actualizaciones / inserciones. Pronto cambié a MySQL y aunque no tuve mucho tiempo para probarlo, parece mucho más escalable que SQLite. Solo recuerdo cargas de páginas lentas y ocasionalmente obtengo un error bloqueado en la base de datos cuando intento ejecutar consultas desde el shell en sqlite. Dicho esto, estoy ejecutando otro sitio de SQLite muy bien. La diferencia es que el sitio es estático (es decir, soy el único que puede cambiar la base de datos) y funciona bien para lecturas simultáneas. Moraleja de la historia: solo use SQLite para sitios web donde las actualizaciones de la base de datos ocurren raramente (con menos frecuencia que cada página cargada).

editar : Me acabo de dar cuenta de que puede que no haya sido justo con SQLite: no indexé ninguna columna en la base de datos SQLite cuando la estaba publicando desde una página web. Esto parcialmente causó la desaceleración que estaba experimentando. Sin embargo, la observación de las bases de bloqueo de bases de datos: si tiene actualizaciones particularmente onerosas, el rendimiento de SQLite no coincidirá con MySQL o Postgres.

Otra edición: desde que publiqué esto hace casi 3 meses, tuve la oportunidad de examinar de cerca la escalabilidad de SQLite, y con algunos trucos puede ser bastante escalable. Como mencioné en mi primera edición, los índices de la base de datos reducen drásticamente el tiempo de consulta, pero esto es más una observación general sobre las bases de datos que sobre SQLite. Sin embargo, hay otro truco que puede usar para acelerar SQLite: transactions . Siempre que tenga que hacer múltiples escrituras de bases de datos, colóquelas dentro de una transacción. En lugar de escribir (y bloquear) el archivo cada vez que se emite una consulta de escritura, la escritura solo se producirá una vez cuando finalice la transacción.

El sitio que mencioné que publiqué en el primer párrafo se ha cambiado a SQLite, y está funcionando sin problemas una vez que sintonicé mi código en algunos lugares.

^{* el sitio ya no está disponible}

Creo que un servidor web (en números 1) que sirve cientos de clientes aparece en el back-end con una única conexión a la base de datos, ¿no?

Por lo tanto, no hay acceso concurrente en la base de datos y, por lo tanto, podemos decir que la base de datos está funcionando en ''modo de usuario único''. No tiene sentido difundir el acceso multiusuario en tal circunstancia, por lo que SQLite funciona tan bien como cualquier otra base de datos basada en servidor.

El sitio web de SQLite (la parte a la que hizo referencia) indica que se puede usar para una variedad de situaciones de múltiples usuarios.

Yo diría que puede manejar bastante. En mi experiencia, siempre ha sido muy rápido. Por supuesto, necesita indexar sus tablas y, al codificar, debe asegurarse de utilizar consultas parameritizadas y similares. Básicamente, lo mismo que harías con cualquier base de datos para mejorar el rendimiento.

En respuesta a GateKiller (arriba), si estás haciendo actualizaciones / inserciones sin usar declaraciones SQL Transaction, entonces SQLLite "parecerá" lento. Si envía SQL en transacciones, la velocidad será mucho más rápida. La mayoría de los servidores SQL no requieren ese tipo de cosas, pero SQLlite, Firebird y JavaDB son algunas de las que requieren transacciones formales ...

Por favor, lea esto: transactions

La escalabilidad de SQLite dependerá en gran medida de los datos utilizados y su formato. He tenido algunas experiencias difíciles con tablas extra largas (registros de GPS, un registro por segundo). La experiencia demostró que SQLite se ralentizaría en etapas, en parte debido al constante reequilibrio de los árboles binarios en crecimiento que contienen los índices (y con índices con sello de tiempo, usted sabe que el árbol se volverá a equilibrar mucho, pero es vital para su búsquedas). Así que al final a aproximadamente 1GB (muy estadio, lo sé), las consultas se vuelven lentas en mi caso. Su kilometraje variará.

Una cosa para recordar, a pesar de todos los alardes, SQLite NO está hecho para el almacenamiento de datos. Hay varios usos no recomendados para SQLite. Las buenas personas detrás de SQLite lo dicen ellos mismos:

Otra forma de ver SQLite es esta: SQLite no está diseñado para reemplazar a Oracle. Está diseñado para reemplazar fopen ().

Y esto conduce al argumento principal (no cuantitativo, lo siento, pero cualitativo), SQLite no es para todos los usos, mientras que MySQL puede cubrir muchos usos variados, incluso si no idealmente. Por ejemplo, podría tener MySQL almacenar cookies de Firefox (en lugar de SQLite), pero necesitaría ese servicio todo el tiempo. Por otro lado, podría tener un sitio web transaccional ejecutándose en SQLite (como hacen muchas personas) en lugar de MySQL, pero se espera mucho tiempo de inactividad.

Piénsalo de esta manera. SQL Lite se bloqueará cada vez que alguien lo use. Por lo tanto, si está publicando una página web o una aplicación que tiene varios usuarios simultáneos, solo uno podría usar su aplicación a la vez con SQLLite. Entonces, hay un problema de escalado. Si se trata de una aplicación para una persona que dice Music Library donde tienes cientos de títulos, clasificaciones, información, uso, reproducción y tiempo de reproducción, SQL Lite se escalará maravillosamente con miles, sino millones de registros (Disco duro dispuesto)

MySQL, por otro lado, funciona bien para aplicaciones de servidores donde personas de todo el mundo lo usarán al mismo tiempo. No se bloquea y es bastante grande en tamaño. Entonces, para su biblioteca de música, MySql sería exagerado ya que solo una persona lo vería, A MENOS QUE esta sea una biblioteca de música compartida donde miles la agreguen o actualicen. Entonces MYSQL sería el que usar.

Así que, en teoría, MySQL escala mejor que Sqllite, ya que puede manejar usuarios múltiples, pero es excesiva para una sola aplicación de usuario.

Podría valer la pena verificar REAL SQL Server , que es un servidor de base de datos basado en SQLite.

SQLite maneja el sitio web sqlite.org y otros que tienen mucho tráfico. Sugieren que si tienes menos de 100.000 visitas por día, SQLite debería funcionar bien. Y eso fue escrito antes de que entregaran la característica "Writeahead Logging".

Si desea acelerar las cosas con SQLite, haga lo siguiente:

actualizar a SQLite 3.7.x
Habilitar el registro por escritura anticipada
Ejecute el siguiente pragma: "PRAGMA cache_size = Number-of-pages;" El tamaño predeterminado (Número de páginas) es 2000 páginas, pero si eleva ese número, aumentará la cantidad de datos que se está ejecutando sin memoria.

Es posible que desee echar un vistazo a mi video en YouTube llamado " Mejorar el rendimiento de SQLite con Writeahead Logging " que muestra cómo usar el registro de escritura anticipada y demuestra una mejora de velocidad de 5x para las escrituras.

Sqlite es escalable en términos de usuario único, tengo una base de datos de varios gigabytes que funciona muy bien y no he tenido muchos problemas con ella.

Pero es un usuario único, por lo que depende de qué tipo de escala esté hablando.

En respuesta a los comentarios. Tenga en cuenta que no hay nada que impida usar una base de datos Sqlite en un entorno multiusuario, pero cada transacción (en efecto, cada declaración SQL que modifica la base de datos) bloquea el archivo , lo que evitará que otros usuarios accedan a la base de datos en todo .

Por lo tanto, si realiza muchas modificaciones en la base de datos, básicamente llegará a los problemas de escalado muy rápido. Si, por otro lado, tiene mucho acceso de lectura en comparación con el acceso de escritura, puede que no sea tan malo.

Pero Sqlite por supuesto funcionará en un entorno multiusuario, pero no funcionará bien.

Sqlite es una base de datos de escritorio o en proceso . SQL Server, MySQL, Oracle y sus hermanos son servidores .

Por su naturaleza, las bases de datos de escritorio no son una buena elección para cualquier aplicación que necesite admitir el acceso de escritura simultáneo al almacén de datos. Esto incluye en cierto nivel la mayoría de los sitios web que se hayan creado. Si incluso tiene que iniciar sesión para algo, probablemente necesite acceso de escritura al DB.