当您需要实现大容量操作时，应该放弃ORM框架吗？

Question

以下是一个常见的情况：

• 您需要在使用ORM框架的应用程序中实现批量操作。
• 在第一次测试之后，您已经注意到了显著的性能问题。

我的问题是：

• 在这种情况下，您应该选择包含原始SQL的解决方案吗？
• 或者，是否有众所周知的设计模式可以帮助您缓解通常与ORM框架的批量操作相关的问题？

编辑：

• 我不是问您是否应该从整个应用程序中删除ORM框架。
• 我的问题是:对于应用程序的这一小部分，您应该放弃ORM框架吗？

Answer 1

ORMs并不打算完全接管对数据库的访问。将它们用于80%的CRUD代码，这些代码太单调，无法单独编写。对于需要仔细优化的其余20%，请使用存储过程、动态SQL或任何您想要的内容。

Answer 2

我在一个要求高性能并处理数十亿条记录的应用程序中使用ORM (nHibernate)。随着时间的推移，我们注意到大多数重要的性能问题都与我们自己使用ORM的方式有关，而不是仅仅因为ORM。

ORM不应该取代您的强制性数据库知识。这是一个在代码中获得更高效率和灵活性的工具，但您需要了解底层流程以优化性能。

您没有指定特定的ORM，因此下面是我们为提高性能所做的工作：

• 我们用了ORM分析器。(我们用的是nhprof)
• 我们用了数据库分析器。(我们使用了Server事件探查器)
• 我们尽可能多地阅读关于这个问题的文章。(除了文档中关于这一主题的整个章节之外，还有许多可供nHibernate使用)
• 我们买了一些关于性能和可伸缩性的专门书籍。
• 我们创建了基准测试系统来测试我们自己的优化。
• 更重要的是，我们能够用大量的数据与现实生活中的客户一起测试我们的代码。仅最后一件事情就帮助我们发现了应用程序中的大多数问题。

Answer 3

我们成功地使用了实体框架( Entity )，但我们的应用程序执行了很多批处理式操作(我们会将大量记录写入各个表)，因此这是一个很好的选择。如果可能的话，我肯定会看看是否有可能保留ORM框架，这只是为了减少应用程序中特殊用途代码的数量。是否可以缓冲写，然后作为一个组执行它们？您将失去事务语义，但是如果要使用批量操作，我想您已经接受了这一点。