django - 在 MVC 框架中结合 noSQL 和 ORM 用于实际应用程序

Question

一段时间以来，我一直在尝试将我在过去几年中读到的关于 noSQL(couchDB、mongoDB、Redis...)的一些“很酷”的东西付诸实践。

我很习惯用 Django 编写应用程序，并开始使用 Play!当 Java 是唯一可接受的部署选项时(并且也很享受)。两者都有模块可以工作，例如，MongoDB , django 还有 nonrel .但我从来没有觉得需要 noSQL。

直到我终于找到了我认为是面向文档存储的一个很好的用例，例如 MongoDB。

用例

假设我们必须管理一些复杂项目的订购和跟进(无论如何)。这些项目可能有很多不同的属性，例如。过度简化我们可以:

一个可以有的冰箱

一两扇门，

属于 A、B 或 C 类，

表面颜色

独立或内置

一个 toastr 可以有:

天然气或电力或两者兼而有之

是否自洁

独立或内置

SQL/ORM 解决方案

如您所见，每个对象都可以有多个可以受类型约束的属性。

在我通常通过 ORM 的 RDBMS 中，我会定义一个“产品”模型，然后继承两个模型，一个冰箱和一个 toastr 。
如果冰箱在一段时间后获得更多属性，我会修改模型 - 因此，模式 - 运行迁移并添加一列。

noSQL 解决方案

我能想到的 noSQL 解决方案是:

使用 RDF(使用类似 Virtuoso 或构建我自己的简化三元组存储)

使用面向文档的数据库，例如 MongoDB

问题

但是 我无法理解在实际中如何不同(更容易)的开发 切换到 noSQL 解决方案，仍然使用具有正确适配器的框架 ORM(尤其是使用 DODB)。

假设我通过 mongodb-engine 将 Django 与 MongoDB 一起使用。

我仍然使用相同的 ORM，所以我仍然将这些对象描述为模型，列出所有属性。
因此，ORM 正在做完全相同的工作!
使用 ORM(特别是像 South 这样的东西)，如果模型发生变化，产生迁移的成本非常有限，不需要自己学习新技术。

DODB 可能有/other/优势，还有一些特定于 MongoDB(可扩展性、数据处理，也许是性能)，但是......我描述的确切用例和问题呢？

我很可能遗漏了一点，所以真正的问题来了:

对于此特定用例:

这个例子对 DODB 来说是好是坏(你有好的例子吗)？

将 ORM 用于基本内容(用户、订单)和 noSQL 的使用是否有意义 没有 复杂对象的 ORM，是否有令人信服的理由完全切换到 noSQL，还是应该继续使用现有的 ORM/SQL？

我知道回答这些问题可能是部分主观的，因此您可以假设您对 noSQL 和 SQL 理论以及股票 ORM 都有完美的了解；存在从库存 ORM 到 noSQL DB 的良好桥梁。让我们假设我们正在讨论这个使用 MongoDB 作为 noSQL 替代方案的用例。

但是还有一个更普遍的问题——这是这篇 SO 帖子的核心问题:

一个好的 ORM(例如 JPA、ActiveRecord 或 Django 的 ORM)不是使 noSQL 尤其是面向文档的数据库变得毫无用处吗？

...是否值得将 noSQL 与“经典”ORM 一起使用？

(“很少使用”从编程和维护的角度来看，性能和类似标准是另一回事，需要进行精确的产品间比较)

[编辑]

我还想了解的是，在切换到 noSQL 时放弃使用 ORM 是否不是更好。拥有更多“动态”模型会很好，例如。我可以有一个表格来描述 Fridge 和 Oven 模型是什么(字段)，并且代码中的 Fridge 和 Oven 模型将能够动态构建它们的 View (用于编辑的表单和用于显示的列表)。

相关问题:

[编辑] :这些是为了展示我的研究，但也是为了澄清我所问的不是关于 noSQL 与 SQL 的通用问题

Is an ORM redundant with a NoSQL API? : 相似的!但我想知道为什么大多数框架(见上文)都通过他们的 ORM 提供 noSQL 访问。这是一个好主意吗？

why the use of an ORM with NoSql (like MongoDB) : 比上一个更具体，但仍然是相反的。我是说 ORM 使 noSQL 变得无用 ，而不是相反!

When to replace RDBMS/ORM with NoSQL

When to use MongoDB or other document oriented database systems?

https://softwareengineering.stackexchange.com/questions/54373/when-would-someone-use-mongodb-or-similar-over-traditional-rdms

编辑
和链接:

Siena :受 Google App Engine Python Datastore 启发的 Java 持久性 API，它试图在 SQL 和 NoSQL 世界之间架起一座桥梁。

minimongo : MongoDB 的轻量级、无模式、Pythonic 面向对象的接口(interface)

Answer 1

这就是我在拖钓 stackoverflow 时得到的结果。偶尔有人问一个悬而未决的问题，我不得不提供我的 2 美分(冒着我自己的项目时间表的风险)。

我刚刚完成了一个项目，在该项目中我必须将 ORM 与模型分离，以便我可以实现 NoSQL 解决方案，并发现它并不困难，尽管有时试图找出最佳方法很艰难。因此，在不太具体说明我的实现的情况下，我将介绍我必须做些什么才能使其工作，因为当您沿着相同的道路前进时，它可能会提供一些启发。

我的设置:

框架 - Symfony 1.4

ORM - 学说 1.4

NoSQL - 我自己的专有解决方案

目标:

将图像路径存储在 xml 文件与数据库中

将 html 描述路径存储在 xml 文件与数据库中

我不想在持久存储(数据库)中将图像存储为 blob，也不想在数据库中存储图像路径，因为我不想支付创建数据库连接和查询的开销路径。所以我决定将路径信息存储在 NoSQL 持久存储(文件系统)中。

和 html 描述一样，我不想在我的表上创建一个文本列并在数据库中存储可能有数百行 html 的内容，原因与上述相同。

我所有的 NoSQL 文件都与一个对象(例如冰箱)相关。这些文件包含指向其相关 Assets (html 描述和图像)的路径，我称之为指针，指向文件系统上的 Assets 。我选择使用 XML 格式来存储数据，所以它看起来像这样:

// Path to pointer file
/home/files/app/needle/myApp/refrigerator/1/1.xml

// Example pointer
<pointer>/home/files/app/file/myApp/refrigerator/1.png</pointer>

现在，在框架内，我必须覆盖 save() 方法，以便我可以使用 NoSQL API 保存上述 Assets 。这很简单，我只是检查父调用并维护进入方法的值，因此它们不会破坏任何我不知道的链逻辑(方法调用具有相同参数的其他方法)。我还让我的自定义 NoSQL API 调用抛出异常，因为主要的 save() 调用被包装在一个 try/catch 块中。这里唯一需要注意的是确定您的 NoSQL Assets 是否值得停止整个事务。在我的示例中，我必须弄清楚上传图像是否会破坏数据库中其余表单字段的保存(我选择中断事务)。

我还必须更改 load() 方法以使用 NoSQL API 与标准模型逻辑检索 Assets 。与保存方法一样，这也不难做到。我只需要看看父类在做什么，而不是用任何参数值。

当一切都完成后，我能够在文件系统上存储图像和 html 描述，使用由指向它们位置的指针组成的 xml 文件。所以现在我不需要每次需要 Assets 时都调用数据库。

一些注意事项(这些可能包含在其他 NoSQL 解决方案中，我必须自己编写):

您将无法从持久存储中查询具有图像的冰箱。您必须在应用程序中编写一些逻辑来从 NoSQL 存储中提取 Assets 。

备份:在备份持久存储数据时，您还需要备份 NoSQL 数据。

孤儿:既然您的架构不知道您可能拥有的任何 Assets ，从持久存储中删除一行将孤立文件系统上的 Assets 。因此，请确保您的应用程序具有在删除行时清理 NoSQL 存储的逻辑。

我想我在使用 ORM 实现 NoSQL 解决方案时遇到了所有主要障碍，如果您有任何其他问题，请随时联系我。

- 编辑 -

对评论的回应:

正如我提到的，我不想创建数据库连接和查询只是为了获取 Assets 的路径。我觉得最好对此类信息使用 NoSQL 解决方案，因为确实没有理由针对此类信息(图像或 html 描述)运行查询。

开发我自己的 NoSQL 解决方案更像是一种自我挑战。在工作中有一个项目来实现一个自定义的 NoSQL 解决方案(在 MogileFS 上有过糟糕的经历)，坦率地说，设计和实现都很糟糕。但我并没有指出坏处，而是挑战自己提供更好的解决方案，但用于副项目。由于挑战方面，我没有研究任何已经可用的 NoSQL 解决方案，但事后看来我可能应该这样做。

我仍然认为您可以通过使用 ORM 的模型层覆盖 crud 函数来实现 MongoDB 或任何 NoSQL 解决方案，相对容易。事实上，我不仅实现了我的 NoSQL 解决方案，还在 crud 函数中添加了将数据索引到 SOLR(用于全文搜索)的功能，所以一切皆有可能。