将 Django 项目从 MySQL 转换为 Mongo，有什么重大陷阱吗？
我想尝试使用 Mongodb 和 mongoengine。我是 Django 和数据库的新手，我对外键、连接、循环导入（凡是你能想到的）都很感兴趣。我知道我最终可以解决这些问题，但对于我正在做的事情来说，Mongo 似乎是一个更简单的解决方案。我的问题是，我正在使用很多可插入应用程序（Imagekit、Haystack、Registration 等），并且想知道如果我进行切换，这些应用程序是否会继续工作。有没有我会遇到的已知的令人头疼的问题，如果是的话，我可能会继续用 MySQL 敲脑袋。
I want to try Mongodb w/ mongoengine. I'm new to Django and databases and I'm having a fit with Foreign Keys, Joins, Circular Imports (you name it). I know I could eventually work through these issues but Mongo just seems like a simpler solution for what I am doing. My question is I'm using a lot of pluggable apps (Imagekit, Haystack, Registration, etc) and wanted to know if these apps will continue to work if I make the switch. Are there any known headaches that I will encounter, if so I might just keep banging my head with MySQL.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您没有理由不能为所有标准 Django 应用程序使用标准 RDBMS 之一，然后为您的应用程序使用 Mongo。您只需将 Django ORM 处理事物的所有标准方法替换为 Mongo 方法即可。
因此，您可以保留 urls.py 及其整齐的模式匹配，视图仍然会获取参数，模板仍然可以接受对象。
您将丢失查询集，因为我怀疑它们与 RDBMS 模型联系得太紧密 - 但它们实际上只是延迟评估的列表。只需忽略有关编写 models.py 的 Django 文档，并以 Mongo 范例编写数据库业务逻辑即可。
哦，您将无法使用 Django 管理界面来轻松访问数据。
There's no reason why you can't use one of the standard RDBMSs for all the standard Django apps, and then Mongo for your app. You'll just have to replace all the standard ways of processing things from the Django ORM with doing it the Mongo way.
So you can keep urls.py and its neat pattern matching, views will still get parameters, and templates can still take objects.
You'll lose querysets because I suspect they are too closely tied to the RDBMS models - but they are just lazily evaluated lists really. Just ignore the Django docs on writing models.py and code up your database business logic in a Mongo paradigm.
Oh, and you won't have the Django Admin interface for easy access to your data.
你可能想看看 django-nonrel，这是一个年轻但有前途的尝试Django 的 NoSQL 后端。目前缺乏文档，但如果你能解决它，效果会很好。
You might want to check out django-nonrel, which is a young but promising attempt at a NoSQL backend for Django. Documentation is lacking at the moment, but it works great if you just work it out.
我已经将 mongoengine 与 django 一起使用，但您需要创建一个像 mongo_models.py 这样的文件。在该文件中，您定义 Mongo 文档。然后，您创建表单来匹配每个 Mongo 文档。每个表单都有一个 save 方法，用于插入或更新 Mongo 中存储的内容。 Django 表单旨在插入任何数据后端（需要一些技巧）
注意：如果您有可以在文档或模型中描述的定义良好且结构化的数据，那么不要使用 Mongo。它不是为此而设计的，像 PostGreSQL 这样的东西会工作得更好。
不要用圆来填充方孔。它不会填满它。
我看过太多帖子，有人想用 Mongo 交换关系数据库，因为 Mongo 是一个流行词。不要误会我的意思，Mongo 真的很棒......当你正确使用它时。我喜欢适当地使用 Mongo
I've used mongoengine with django but you need to create a file like mongo_models.py for example. In that file you define your Mongo documents. You then create forms to match each Mongo document. Each form has a save method which inserts or updates whats stored in Mongo. Django forms are designed to plug into any data back end ( with a bit of craft )
BEWARE: If you have very well defined and structured data that can be described in documents or models then don't use Mongo. Its not designed for that and something like PostGreSQL will work much better.
Don't circle to fill a square hole. It won't fill it.
I've seen too many posts where someone wanted to swap a relational DB for Mongo because Mongo is a buzz word. Don't get me wrong, Mongo is really great... when you use it appropriately. I love using Mongo appropriately
首先，它不适用于任何提供其模型的现有 Django 应用程序。目前没有用于将 Django 的模型数据存储在 mongodb 或其他 NoSQL 存储中的后端，并且除了数据库后端之外，模型本身在某种程度上是一个没有实际意义的问题，因为一旦您开始使用某人的应用程序（< code>django.contrib apps include），它附带了模型-模板-视图三元组，每当您需要一个稍微不同的模型来满足您的目的时，您要么必须编辑应用程序代码（明显错误），要么动态编辑导入的内容运行时的 Python 模块（神奇）、完全分叉应用程序源（麻烦）或提供额外的设置（很好，但这种情况很少见，
django.contrib.auth可能是唯一广为人知的示例一个允许您动态指定将使用哪个模型的应用程序，就像通过 AUTH_PROFILE_MODULE 设置的用户配置文件模型一样）。这可能听起来很糟糕，但它真正意味着您必须并行部署 SQL 和 NoSQL 数据库，并从应用程序到应用程序进行基础操作（就像 Spacedman 所建议的那样），并且如果 mongodb 最适合某些应用程序，见鬼，只需推出您自己的自定义应用程序即可。
有很多优秀的 Djangonauts 都在考虑 NoSQL 存储。如果您关注过去的 Djangocon 演示，每年都会有关于 Django 应如何利用 NoSQL 存储的重要讨论。我非常确定，在今年或明年，有人会重构应用程序和模型 API，为干净的设计铺平道路，最终可以将所有不同风格的 NoSQL 存储统一为 Django 核心的一部分。
Upfront, it won't work for any existing Django app that ships it's models. There's no backend for storing Django's Model data in mongodb or other NoSQL storages at the moment and, database backends aside, models themselves are somewhat of a moot point, because once you get in to using someones app (
django.contribapps included) that ships model-template-view triads, whenever you require a slightly different model for your purposes you either have to edit the application code (plain wrong), dynamically edit the contents of imported Python modules at runtime (magical), fork the application source altogether (cumbersome) or provide additional settings (good, but it's a rare encounter, withdjango.contrib.authprobably being the only widely known example of an application that allows you to dynamically specify which model it will use, as is the case with user profile models through theAUTH_PROFILE_MODULEsetting).This might sound bad, but what it really means is that you'll have to deploy SQL and NoSQL databases in parallel and go from an app-to-app basis--like Spacedman suggested--and if mongodb is the best fit for a certain app, hell, just roll your own custom app.
There's a lot of fine Djangonauts with NoSQL storages on their minds. If you followed the streams from the past Djangocon presentations, every year there's been important discussions about how Django should leverage NoSQL storages. I'm pretty sure, in this year or the next, someone will refactor the apps and models API to pave the path to a clean design that can finally unify all the different flavors of NoSQL storages as part of the Django core.
我最近尝试过这个（尽管没有 Mongoengine）。恕我直言，有很多陷阱：
基本上，在 django 接口中搜索对 django.contrib.auth 的引用，您就会看到有多少东西会被破坏。
也就是说，MongoEngine 可能提供一些支持来用更好的东西替换/增强 django.contrib.auth，但是有太多东西依赖于它，很难说你如何猴子修补那么多东西。
I have recently tried this (although without Mongoengine). There are a huge number of pitfalls, IMHO:
Basically, search through the django interface for references to django.contrib.auth and you'll see how many things will be broken.
That said, it's possible that MongoEngine provides some support to replace/augment django.contrib.auth with something better, but there are so many things that depend on it that it's hard to say how you'd monkey patch something that much.
主要陷阱（对我来说）：没有加入！
Primary pitfall (for me): no JOINs!