mysqlclient - MySQL vs PostgreSQL? ¿Qué debería elegir para mi proyecto Django?
django database mysql (10)
gran base de datos con varios cientos de miles de entradas,
Esta no es una gran base de datos, es muy pequeña.
Elegiría PostgreSQL, porque tiene muchas más características. Lo más significativo es este caso: en PostgreSQL puede usar Python como lenguaje de procedimiento.
Mi proyecto Django contará con el respaldo de una gran base de datos con cientos de miles de entradas, y será necesario que admita la búsqueda (probablemente terminaré usando djangosearch o un proyecto similar).
¿Qué back-end de base de datos se adapta mejor a mi proyecto y por qué? ¿Puedes recomendar algún buen recurso para seguir leyendo?
¿Se alojará esta aplicación en sus propios servidores o por una empresa de hosting? Asegúrate de que si estás utilizando una empresa de hosting, admiten la base de datos de tu elección.
Como alguien que recientemente cambió un proyecto de MySQL a Postgresql, no me arrepiento del cambio.
La principal diferencia, desde el punto de vista de Django, es la comprobación de restricciones más rigurosa en Postgresql, lo cual es algo bueno, y también es un poco más tedioso hacer cambios de esquema manuales (también conocidos como migraciones).
Probablemente hay alrededor de 6 aplicaciones de migración de bases de datos Django y al menos una no es compatible con Postgresql. No considero que esto sea una desventaja porque puedes usar uno de los otros o hacerlo manualmente (que es lo que prefiero ATM).
La búsqueda de texto completo podría ser mejor soportada para MySQL. MySQL tiene una búsqueda incorporada de texto completo compatible desde Django, pero es bastante inútil (no se derivan palabras, búsqueda de frases, etc.). Utilicé django-sphinx como una mejor opción para la búsqueda de texto completo en MySQL.
La búsqueda de texto completo está incorporada con Postgresql 8.3 (las versiones anteriores necesitan el módulo TSearch). Aquí hay una buena publicación de blog de instrucciones: búsqueda de texto completo en Django con PostgreSQL y tsearch2
Cuando una migración falla en django-sur, los desarrolladores lo alientan a no usar MySQL:
! The South developers regret this has happened, and would
! like to gently persuade you to consider a slightly
! easier-to-deal-with DBMS (one that supports DDL transactions)
Existe una gran diferencia de licencia entre las dos bases de datos que lo afectará si alguna vez tiene la intención de distribuir código utilizando la base de datos. Las bibliotecas de cliente de MySQL son GPL y PostegreSQL está bajo una licencia tipo BSD con la que podría ser más fácil trabajar.
Incluso si Postgresql se ve mejor, me parece que tiene algunos problemas de rendimiento con Django:
Postgresql está hecho para manejar "conexiones largas" (agrupación de conexiones, conexiones persistentes, etc.)
MySQL está hecho para manejar "conexiones cortas" (conéctese, haga sus consultas, desconéctese, tiene algunos problemas de rendimiento con muchas conexiones abiertas )
El problema es que Django no es compatible con la agrupación de conexiones o la conexión persistente, tiene que conectarse / desconectarse a la base de datos en cada visita a la vista.
Funciona con Postgresql, pero conectarse a un Postgresql cuesta MUCHO más que conectarse a una base de datos MySQL (En Postgresql, cada conexión tiene su propio proceso, es mucho más lento que simplemente abrir un nuevo hilo en MySQL).
Luego obtienes algunas características como Query Cache que pueden ser realmente útiles en algunos casos. (Pero perdió la excelente búsqueda de texto de PostgreSQL)
Para agregar a respuestas anteriores:
- "La búsqueda de texto completo podría ser mejor soportada para MySQL"
El índice FULLTEXT en MySQL es una broma.
- Solo funciona con tablas MyISAM, por lo que pierde ACID, Transacciones, Restricciones, Relaciones, Durabilidad, Concurrencia, etc.
- INSERT / UPDATE / DELETE a una columna TEXT grande (como una publicación en el foro) reconstruirá una gran parte del índice. Si no cabe en myisam_key_buffer, se producirán IO grandes. He visto que la inserción de una sola publicación de foro dispara 100 MB o más de IO ... mientras tanto, la tabla de publicaciones está bloqueada de forma exclusiva.
- Hice algunos benchmarking (hace 3 años, puede ser obsoleto ...) que demostró que en grandes conjuntos de datos, básicamente el texto completo de postgres es 10-100x más rápido que mysql, y Xapian 10-100x más rápido que postgres (pero no integrado).
Otros motivos no mencionados son el optimizador de consultas extremadamente inteligente, gran variedad de tipos de combinación (fusión, hash, etc.), agregación hash, índices básicos en matrices, búsqueda espacial, etc. que pueden dar como resultado planes extremadamente rápidos en consultas muy complicadas.
Para lo que valga la pena, los creadores de Django recomiendan PostgreSQL.
Si no está vinculado a ningún sistema heredado y tiene la libertad de elegir un back-end de base de datos, recomendamos PostgreSQL, que logra un equilibrio fino entre costo, características, velocidad y estabilidad. ( La guía definitiva de Django , página 15)
Todas las respuestas traen información interesante a la mesa, pero algunas están un poco desactualizadas, así que aquí está mi grano de sal.
A partir del 1.7, las migrations ahora son una característica integral de Django. Así que documentaron las principales diferencias que los desarrolladores de Django podrían querer saber de antemano.
Soporte de Backend
Las migraciones se admiten en todos los SchemaEditor con los que se envía Django, así como también los SchemaEditor terceros si se han programado para admitir la alteración del esquema (realizada a través de la clase SchemaEditor ).
Sin embargo, algunas bases de datos son más capaces que otras cuando se trata de migraciones de esquemas; algunas de las advertencias están cubiertas a continuación.
PostgreSQL
PostgreSQL es la más capaz de todas las bases de datos aquí en términos de soporte de esquemas; la única advertencia es que agregar columnas con valores predeterminados provocará una reescritura completa de la tabla, por un tiempo proporcional a su tamaño.
Por esta razón, se recomienda siempre crear nuevas columnas con null = True, ya que de esta forma se agregarán inmediatamente.
MySQL
MySQL no admite las transacciones relacionadas con las operaciones de alteración del esquema, lo que significa que si una migración no se aplica, deberá anular manualmente los cambios para volver a intentarlo (es imposible retrotraer a un punto anterior).
Además, MySQL reescribirá completamente las tablas para casi todas las operaciones de esquema y generalmente toma un tiempo proporcional al número de filas en la tabla para agregar o eliminar columnas. En hardware más lento, esto puede ser peor que un minuto por millón de filas: agregar algunas columnas a una tabla con solo unos pocos millones de filas podría bloquear su sitio durante más de diez minutos.
Finalmente, MySQL tiene límites razonablemente pequeños en las longitudes de nombre para columnas, tablas e índices, así como un límite en el tamaño combinado de todas las columnas que cubre un índice. Esto significa que los índices que son posibles en otros backends no serán creados bajo MySQL.
SQLite
SQLite tiene muy poco soporte de alteración de esquema incorporado, por lo que Django intenta emularlo de la siguiente manera:
- Creando una nueva tabla con el nuevo esquema
- Copiando los datos en
- Dejar caer la mesa vieja
- Cambiar el nombre de la nueva tabla para que coincida con el nombre original
Este proceso generalmente funciona bien, pero puede ser lento y ocasionalmente con errores. No se recomienda que ejecute y migre SQLite en un entorno de producción a menos que sea muy consciente de los riesgos y sus limitaciones; el soporte con el que Django se envía está diseñado para permitir a los desarrolladores usar SQLite en sus máquinas locales para desarrollar proyectos de Django menos complejos sin la necesidad de una base de datos completa.
Ve con lo que te resulte más familiar. MySQL vs PostgreSQL es una guerra sin fin. Ambos son excelentes motores de bases de datos y ambos están siendo utilizados por los principales sitios. Realmente no importa en la práctica.