usando SQLite en Django en producción?

Question

Lo siento por esta pregunta, no sé si entendí el concepto, pero SQLite no tiene servidor, esto significa que la base de datos está en un equipo local y está almacenada en un archivo, este archivo solo está accesible en un modo: si un cliente lo lee, está hecho solo para el modo de lectura para otros clientes, y si un cliente escribe, entonces todos los clientes tienen el modo de escritura, ¡así que solo en un modo a la vez! así que imagina que he hecho una aplicación django, un blog por ejemplo; entonces, ¿cómo se hace esto usando sqlite? dado que si un cliente ingresa al blog, selecciona el modo de lectura para ver la página y las entradas del blog, y si un cliente registrado intenta agregar un comentario, el archivo se creará como modo de escritura, entonces, ¿cómo puede manejar esto sqlite? entonces, ¿SQLite está aquí como el servidor BaseHTTPServer (el servidor incluido con django), con fines de prueba y aprendizaje?

Answer 1

Diferentes bases de datos gestionan la concurrencia de diferentes maneras, pero en sqlite, el método utilizado es un bloqueo de nivel de base de datos global. Solo un hilo o proceso puede hacer cambios a una base de datos sqlite a la vez; todos los demás procesos simultáneos se verán obligados a esperar hasta que el proceso en ejecución haya finalizado.

A medida que su número de usuarios crece; La estrategia de bloqueo simple de sqlite conducirá a una contención de bloqueo cada vez mayor, y deberá migrar sus datos a otra base de datos, como MySQL (que puede hacer el nivel de fila, al menos con el motor InnoDB) o PostgreSQL (que usa control de concurrencia Multiversion) . Si prevé que obtendrá una cantidad sustancial de usuarios (en el nivel de, por ejemplo, más de 1 solicitud por segundo durante una buena parte del día), debe migrar fuera de sqlite; y cuanto antes lo hagas, más fácil será.

Answer 2

Este problema en la teoría de la base de datos se denomina concurrencia y SQLite lo soporta en versiones Windows> Win98 y en otros lugares de acuerdo con las preguntas más frecuentes:

http://www.sqlite.org/faq.html#q5

somos conscientes de ningún otro motor de base de datos SQL incrustado que admite como mucha concurrencia como SQLite. SQLite permite que múltiples procesos tengan el archivo de base de datos abierto a la vez, y para que múltiples procesos lean la base de datos a la vez. Cuando cualquier proceso desea escribir, debe bloquear el archivo de base de datos completo mientras dure su actualización. Pero eso normalmente solo toma unos pocos milisegundos. Otros procesos simplemente esperan en el escritor para finalizar y continuar con sus actividades. Otros motores de base de datos SQL incrustados generalmente solo permiten que un solo proceso se conecte a la base de datos de una vez.

Básicamente, no se preocupe por la concurrencia, cualquier base de datos que se precie se encarga de bien. Puede encontrar más información sobre cómo SQLite3 administra esto en here. A usted, como desarrollador, no como diseñador de bases de datos, no le debe importar a menos que esté interesado en el funcionamiento interno.

Answer 3

SQLite no está destinado a la producción. Es bastante fácil poner en funcionamiento MySQL o PostgreSQL, incluso en Windows, y tener una base de datos real.

El verdadero problema es que SQLite3 no está enhebrado en Django tan sólo una vista de página puede suceder en un momento en el servidor, vea este error https://code.djangoproject.com/ticket/12118

No consumo SQLite3 aún en desarrollo.

Answer 4

SQLite es no como BaseHTTPServer o algo básico como ese.Es una completa integrada base de datos. Muy rápido también Su lenguaje SQL puede no tener la mayoría de las campanas y silbatos, pero es lo suficientemente flexible. No me he encontrado con casos en los que necesitaba algo que no puede hacer para los proyectos en los que participé (que no son las aplicaciones web típicas, a decir verdad).

Cualquiera que afirme que SQLite es bueno o malo para la producción sin discutir el diseño real, no le dice mucho. SQLite es bastante rápido. En algunos casos, literalmente órdenes de magnitud más rápido que, por ejemplo, Postgres, que aparece como una alternativa a seguir entre Djangonauts. Como alguien señaló, también admite mucha concurrencia. Se trata de si su aplicación cae dentro de los 'algunos casos' o no.

Ahora, hay un factor importante que debe tenerse en cuenta. SQLite es una base de datos en proceso. Esto es realmente importante Si está utilizando algo como gevent, puede encontrarse con casos extremos en los que se rompe su aplicación. Por ejemplo, intentar hacer una transacción en la que tengas un cambio de contexto en medio de ella puede posiblemente romper la transacción de maneras horribles. En otras palabras, la 'concurrencia' realmente depende de su aplicación, porque SQLite es parte de su aplicación.

Lo que no se puede hacer con SQLite, sin embargo, en términos de escalamiento, no se pueden crear clústeres de servidores SQLite como se puede con algunos de los otros motores de base de datos, porque está en proceso. Su aplicación puede o no necesitar llegar a tal extremo en términos de escalado, pero supongo que la gran mayoría de las aplicaciones no lo hacen de todos modos (supongo).

Por otro lado, estar en proceso significa agregar funciones personalizadas y agregados es bastante trivial. No estoy seguro de si el ORM de Django lo hace más difícil de lo que debe ser, pero puede obtener diseños muy buenos aprovechando esas características.