La conversión de proyecto de Django de MySQL a Mongo, los escollos más importantes?

Question

Quiero tratar mongodb w / mongoengine. Soy nuevo en Django y bases de datos y estoy teniendo un ataque con claves externas, combinaciones circulares importaciones (lo que sea). Sé que con el tiempo podría trabajar a través de estas cuestiones, pero Mongo apenas se parece como una solución más simple para lo que estoy haciendo. Mi pregunta es que estoy usando un montón de aplicaciones conectables (Imagekit, Almiar, registro, etc.) y quería saber si estas aplicaciones a seguir trabajando si hago el interruptor. ¿Hay dolores de cabeza conocidos que voy a encontrar, si es así yo podría seguir golpeando la cabeza con MySQL.

Answer 1

No hay razón por la que no se puede utilizar uno de los sistemas RDBMS estándar para todas las aplicaciones estándar de Django, y luego Mongo para su aplicación. Usted sólo tiene que reemplazar todas las formas estándar de procesamiento de las cosas desde el ORM de Django con hacerlo de la manera Mongo.

Para que pueda mantener urls.py y su ordenada coincidencia de patrones, vistas seguirán obteniendo parámetros, y las plantillas aún puede tomar objetos.

Vas a perder QuerySets porque sospecho que están muy estrechamente ligados a los modelos de RDBMS - pero no son más que pereza evaluaron las listas de verdad. Simplemente ignorar la documentación de Django en escribir models.py y el código de su lógica de negocio de base de datos en un paradigma de Mongo.

Ah, y no tendrá la interfaz de administración de Django para facilitar el acceso a sus datos.

Answer 2

Es posible que desee echa un vistazo a django-nonrel , que es un joven pero prometedor tratar a un backend NoSQL de Django. Documentación que falta en este momento, pero funciona muy bien si sólo trabaja hacia fuera.

Answer 3

He usado mongoengine con Django, pero es necesario crear un archivo como mongo_models.py por ejemplo. En ese archivo se definen los documentos Mongo. A continuación, crea formas para que coincida con cada documento Mongo. Cada forma tiene un método para guardar las cuales inserciones o actualizaciones cuál almacenan en Mongo. formas Django están diseñados para clavija en cualquier extremo posterior de datos (con un poco de artesanía)

CUIDADO: Si ha definido muy bien y datos que pueden ser descritos en los documentos o modelos no utilice Mongo estructurado. No es diseñado para eso y algo así como PostGreSQL funcionará mucho mejor.

• Yo uso PostGreSQL de datos relacionales o bien estructurados porque su buena para eso. Pequeña huella de memoria y una buena respuesta.
• utilizo Redis de caché u operar en las colas de memoria / listas porque es muy bueno para eso. gran rendimiento, siempre que tenga la memoria para hacer frente a ella.
• Mongo utilizo para almacenar grandes documentos JSON y para realizar Mapa y reducir en ellos (si es necesario) porque es muy bueno para eso. Asegúrese de utilizar la indexación de ciertas columnas si se puede acelerar las búsquedas.

No círculo para llenar un agujero cuadrado. No va a llenarlo.

he visto demasiados mensajes en la que alguien quisiera cambiar una base de datos relacional para Mongo Mongo porque es una palabra de moda. No me malinterpreten, Mongo es realmente grande ... cuando se utiliza adecuadamente. Me encanta usar apropiadamente Mongo

Answer 4

Upfront, no va a funcionar para cualquier aplicación Django existente que lo envía de modelos. No hay backend para el almacenamiento de datos del modelo de Django en mongodb u otros almacenamientos NoSQL en el momento y, backends de bases de datos a un lado, los modelos en sí son algo así como un punto discutible, porque una vez que llegue a usar repique aplicación (django.contrib aplicaciones incluidas) que se incluye modelo de plantilla con vistas al tríadas, cada vez que requieren un modelo ligeramente diferente para sus propósitos que o bien tienen que editar el código de la aplicación (mal llano), de forma dinámica editar los contenidos de los módulos de Python importados en tiempo de ejecución (mágica), tenedor la fuente de la aplicación por completo (engorroso) o proporcionar ajustes adicionales (bueno, pero es un encuentro raro, con django.contrib.auth siendo probablemente el único ejemplo conocido de una aplicación que le permite especificar de forma dinámica qué modelo se utilizará, como es el caso con el usuario perfil modelos a través de la configuración AUTH_PROFILE_MODULE).

Este sonido mala fuerzas, pero lo que realmente significa es que usted tiene que implementar bases de datos SQL y NoSQL en paralelo y pasar de una base de aplicación a aplicación - como Spacedman sugirió - y si mongodb es la mejor aptos para una aplicación determinada, el infierno, acaba de rodar su propia aplicación personalizada.

Hay una gran cantidad de finos con Djangonautas almacenamientos NoSQL en sus mentes. Si ha seguido las corrientes procedentes de las últimas presentaciones DjangoCon, todos los años ha habido discusiones importantes sobre cómo Django debe aprovechar almacenamientos NoSQL. Estoy bastante seguro de que, en este año o el siguiente, alguien va a refactorizar el aplicaciones y modelos de API para allanar el camino hacia un diseño limpio que finalmente puede unificar todos los diferentes sabores de depósitos de NoSQL como parte del núcleo de Django.

Answer 5

Me han tratado recientemente de esto (aunque sin Mongoengine). Hay un gran número de trampas, en mi humilde opinión:

• No interfaz de administración.
• No se django.contrib.auth de autenticación se basa en la interfaz de base de datos.
• Muchas cosas dependen de django.contrib.auth.User. Por ejemplo, la clase RequestContext. Este es un gran obstáculo.
• No hay registro (se basa en la interfaz de base de datos y django.contrib.auth)

Básicamente, buscar a través de la interfaz de Django para las referencias a django.contrib.auth y verá cuántas cosas se romperá.

Dicho esto, es posible que MongoEngine proporciona algo de apoyo para reemplazar / augment django.contrib.auth con algo mejor, pero hay tantas cosas que dependen de ella que es difícil decir cómo te parche mono algo que tanto .

Answer 6

Primary pitfall (for me): no JOINs!