将 Django 项目从 MySQL 转换为 Mongo，有什么主要的陷阱吗？答案

【问题标题】：Converting Django project from MySQL to Mongo, any major pitfalls?将 Django 项目从 MySQL 转换为 Mongo，有什么主要的陷阱吗？
【发布时间】：2011-01-17 22:22:32
【问题描述】：

我想尝试带有 mongoengine 的 Mongodb。我是 Django 和数据库的新手，我很适合外键、连接、循环导入（你可以命名它）。我知道我最终可以解决这些问题，但对于我正在做的事情来说，Mongo 似乎是一个更简单的解决方案。我的问题是我正在使用很多可插入的应用程序（Imagekit、Haystack、Registration 等），并且想知道如果我进行切换这些应用程序是否会继续工作。我会遇到什么已知的头痛吗，如果是这样，我可能会一直用 MySQL 敲我的脑袋。

【问题讨论】：

如果您是 Django 和数据库的新手，您可能希望再坚持使用默认的 ORM。它确实非常强大，RDBMS 一开始会让大多数人感到困惑，但随着您的使用，它们会变得容易得多。我对你在 Django 中遇到 FK 和 Join 的问题感到困惑...... ORM 意味着你不必直接处理 JOIN 并且 FK 非常直观......
这是一种迂回的说法，我认为您不会发现 Mongo 在执行实际任务时不会那么复杂。这是一个很棒的引擎，但 NoSQL 并不是让事情变得简单的魔杖。
具体来说，我正在尝试将另一个 ForeignKey 添加到我现有的模型之一中，但它不会导入。做了一些阅读，看起来我是“循环进口”的受害者。现在还在努力！

标签： python django mongodb mongoengine

【解决方案1】：

您没有理由不能为所有标准 Django 应用程序使用标准 RDBMS 之一，然后为您的应用程序使用 Mongo。您只需将 Django ORM 中处理事物的所有标准方式替换为 Mongo 方式即可。

所以你可以保留 urls.py 及其简洁的模式匹配，视图仍然可以获取参数，模板仍然可以获取对象。

您会丢失查询集，因为我怀疑它们与 RDBMS 模型的联系过于紧密 - 但它们实际上只是延迟评估的列表。只需忽略有关编写 models.py 的 Django 文档，并在 Mongo 范例中编写您的数据库业务逻辑。

哦，您将没有 Django Admin 界面来轻松访问您的数据。

【讨论】：

【解决方案2】：

您可能想查看django-nonrel，这是一个年轻但很有希望的 Django NoSQL 后端尝试。目前缺乏文档，但如果你只是解决它，它会很好。

【讨论】：

【解决方案3】：

我在 django 中使用过 mongoengine，但您需要创建一个文件，例如 mongo_models.py。在该文件中定义您的 Mongo 文档。然后，您创建表单以匹配每个 Mongo 文档。每个表单都有一个保存方法，用于插入或更新存储在 Mongo 中的内容。 Django 表单旨在插入任何数据后端（需要一些技巧）

注意：如果您有可以在文档或模型中描述的定义明确且结构化的数据，则不要使用 Mongo。它不是为此而设计的，像 PostGreSQL 这样的东西会更好地工作。

我将 PostGreSQL 用于关系数据或结构良好的数据，因为它对此有好处。内存占用小，响应良好。
我使用 Redis 来缓存或在内存队列/列表中操作，因为它非常适合。只要您有足够的内存来处理它，就可以提供出色的性能。
我使用 Mongo 来存储大型 JSON 文档并对它们执行 Map 和 reduce（如果需要），因为它非常适合。如果可以加快查找速度，请务必对某些列使用索引。

不要用圆圈来填充方孔。它不会填满它。

我看到太多帖子有人想用 Mongo 交换关系数据库，因为 Mongo 是一个流行词。不要误会我的意思，Mongo 真的很棒......当你适当地使用它时。我喜欢适当地使用 Mongo

【讨论】：

【解决方案4】：

首先，它不适用于任何现有的 Django 应用程序，它提供了它的模型。目前没有用于将 Django 的模型数据存储在 mongodb 或其他 NoSQL 存储中的后端，而且除了数据库后端之外，模型本身在某种程度上还有争议，因为一旦你开始使用某人的应用程序 (@包括 987654321@ 应用程序）附带模型-模板-视图三元组，每当您需要稍微不同的模型时，您要么必须编辑应用程序代码（完全错误），要么在运行时动态编辑导入的 Python 模块的内容（神奇），完全分叉应用程序源（繁琐）或提供额外设置（很好，但这是一种罕见的情况，django.contrib.auth 可能是唯一广为人知的应用程序示例，它允许您动态指定它将使用哪个模型，就像通过AUTH_PROFILE_MODULE 设置的用户配置文件模型的情况）。

这听起来可能很糟糕，但它的真正含义是您必须并行部署 SQL 和 NoSQL 数据库，并从应用程序到应用程序进行 - 就像 Spacedman 建议的那样 - 如果 mongodb 是最好的适合某个应用，见鬼，只需推出您自己的自定义应用。

有很多优秀的 Djangonauts 都在考虑使用 NoSQL 存储。如果您关注过去 Djangocon 演示文稿中的信息流，那么每年都会有关于 Django 应如何利用 NoSQL 存储的重要讨论。我很确定，在今年或明年，有人会重构应用程序和模型 API，从而为干净的设计铺平道路，最终将所有不同风格的 NoSQL 存储统一为 Django 核心的一部分。

【讨论】：

重构工作已经基本完成。 1.3 包含一系列使 NoSQL 后端更易于实现的更改。还有很多事情需要做，但肯定越来越近了。

【解决方案5】：

我最近尝试过这个（虽然没有 Mongoengine）。恕我直言，有很多陷阱：

没有管理界面。
No Auth django.contrib.auth 依赖于 DB 接口。
很多事情都依赖于 django.contrib.auth.User。例如，RequestContext 类。这是一个巨大的障碍。
无注册（依赖 DB 接口和 django.contrib.auth）

基本上，通过 django 界面搜索对 django.contrib.auth 的引用，你会看到有多少东西会被破坏。

也就是说，MongoEngine 可能提供了一些支持来用更好的东西替换/增强 django.contrib.auth，但是有很多东西依赖于它，很难说你会怎么修补这么多东西.

【讨论】：

【解决方案6】：

主要陷阱（对我而言）：没有 JOIN！

【讨论】：