Conversion de projet Django de MySQL à Mongo, les principaux écueils?

Question

Je veux essayer MongoDB w / mongoengine. Je suis nouveau à Django et bases de données et je vais avoir un ajustement avec des clés étrangères, les jointures, les importations circulaires (vous le nom). Je sais que je pourrais éventuellement travailler à travers ces questions, mais semble comme Mongo une solution plus simple pour ce que je fais. Ma question est que je utilise beaucoup d'applications connectables (Imagekit, Haystack, enregistrement, etc.) et je voulais savoir si ces applications continueront de travailler si je fais le commutateur. Y a-t-il des maux de tête connus que je rencontre, dans ce cas je pourrais juste garder ma tête cognant avec MySQL.

Answer 1

Il n'y a aucune raison pour laquelle vous ne pouvez pas utiliser l'un des SGBDR standard pour tous les standards des applications Django, puis Mongo pour votre application. Vous aurez juste à remplacer toutes les méthodes standard de traitement des choses de Django ORM avec lui faire le chemin Mongo.

Vous pouvez garder urls.py et son pattern matching propre, vues seront toujours obtenir les paramètres et les modèles peuvent encore prendre des objets.

Vous perdrez QuerySets parce que je pense qu'ils sont trop étroitement liés aux modèles de SGBDR - mais ils ne sont que des listes évaluées paresseusement vraiment. Il suffit de ne pas tenir compte des Django docs sur l'écriture et le code models.py votre logique métier de base de données dans un paradigme Mongo.

Oh, et vous n'aurez pas l'interface Django Administrateur pour accéder facilement à vos données.

Answer 2

Vous pouvez consulter django-nonrel , qui est un jeune mais prometteur tentative de back-end NoSQL pour Django. La documentation fait défaut pour le moment, mais il fonctionne très bien si vous travaillez tout simplement.

Answer 3

Je l'ai utilisé mongoengine avec django, mais vous devez créer un fichier comme mongo_models.py par exemple. Dans ce fichier, vous définissez vos documents mongo. Vous créez ensuite des formulaires pour correspondre à chaque document Mongo. Chaque forme a une méthode qui sauvegarde ce qui est des mises à jour ou insertions stockées dans Mongo. Django formes sont conçues pour se brancher dans toute extrémité arrière de données (avec un peu de métier)

ATTENTION: Si vous avez très bien défini et des données structurées qui peuvent être décrits dans les documents ou modèles alors ne pas utiliser Mongo. Ce ne est pas conçu pour cela et quelque chose comme PostGreSQL fonctionnera beaucoup mieux.

• J'utilise PostGreSQL pour des données relationnelles ou bien structurés parce que son bon pour cela. Faible empreinte mémoire et une bonne réponse.
• J'utilise Redis le cache ou opérez dans les files d'attente de mémoire / listes parce que son très bon pour cela. d'excellentes performances à condition d'avoir la mémoire pour y faire face.
• J'utilise Mongo pour stocker des documents volumineux JSON et d'effectuer Carte et réduis sur eux (si nécessaire) parce que son très bon pour cela. Assurez-vous de l'indexation de l'utilisation sur certaines colonnes si vous pouvez pour accélérer les recherches.

Ne pas cercle pour remplir un trou carré. Il ne sera pas le remplir.

J'ai vu trop de messages où quelqu'un voulait échanger une DB relationnelle pour Mongo, car Mongo est un mot à la mode. Ne vous méprenez pas, Mongo est vraiment super ... quand vous l'utilisez correctement. J'aime utiliser de manière appropriée Mongo

Answer 4

Upfront, il ne fonctionnera pas pour une application Django existante qui expédie de modèles. Il n'y a pas backend pour stocker les données du modèle de Django dans MongoDB ou d'autres entrepôts NoSQL au moment et, la base de données backends mises à part, les modèles eux-mêmes sont un peu d'un point discutable, car une fois pour l'utilisation de l'application (django.contrib applications incluses) que les navires triades modèle modèle-vue, chaque fois que vous avez besoin d'un modèle légèrement différent pour vos besoins vous avez soit à modifier le code d'application (mauvaise plaine), dynamiquement modifier le contenu des modules Python importés lors de l'exécution (magique), fourchette la source de l'application tout à fait (lourde) ou de fournir d'autres paramètres (bon, mais il est une rencontre rare, avec django.contrib.auth étant probablement le seul exemple connu largement d'une application qui vous permet de spécifier dynamiquement quel modèle il utilisera, comme cela est le cas avec l'utilisateur le profil des modèles par le paramètre AUTH_PROFILE_MODULE).

Ce son pourrait mal, mais ce que cela signifie vraiment est que vous devrez déployer des bases de données SQL et NoSQL en parallèle et passer d'une base app à l'application - comme Spacedman suggéré - et si MongoDB est le meilleur propres à une certaine application, l'enfer, juste rouler votre propre application personnalisée.

Il y a beaucoup de belles Djangonauts avec des stockages NoSQL sur leur esprit. Si vous avez suivi les cours d'eau des présentations Djangocon passé, chaque année il y a eu des discussions importantes sur la façon dont Django devrait tirer parti de NoSQL stockage. Je suis assez sûr, cette année ou l'autre, quelqu'un factoriser l'API des applications et des modèles pour ouvrir la voie à un design épuré qui peut enfin unifier toutes les différentes saveurs de NoSQL unités de stockage partie du noyau Django.

Answer 5

J'ai récemment essayé (mais sans Mongoengine). Il y a un grand nombre de pièges, à mon humble avis:

• Pas d'interface admin.
• Non Auth django.contrib.auth repose sur l'interface DB.
• Beaucoup de choses reposent sur django.contrib.auth.User. Par exemple, la classe RequestContext. Ceci est un obstacle énorme.
• Non Enregistrement (sur l'interface fait confiance DB et django.contrib.auth)

En fait, la recherche via l'interface django pour les références à django.contrib.auth et vous verrez combien de choses sera brisé.

Cela dit, il est possible que MongoEngine fournit un soutien pour remplacer / augment django.contrib.auth quelque chose de mieux, mais il y a tellement de choses qui en dépendent qu'il est difficile de dire comment vous patch singe quelque chose qui beaucoup .

Answer 6

Primaire piège (pour moi): pas JOIN