大型高流量网站是否使用 ORM？答案

【问题标题】：Do Large High-Traffic Websites use ORMs?大型高流量网站是否使用 ORM？
【发布时间】：2010-11-24 12:12:09
【问题描述】：

我最终决定使用实体框架，因为它在所有 ORM 中具有最佳性能。但在我开始阅读和编写代码之前，我只想知道是否有任何使用 ORM 的高流量网站。

【问题讨论】：

我认为这不是真的；你看过 LLBLGen 吗？您如何确定它具有最佳性能？
它没有回答哪个性能最好，但是关于这个问题值得一读：stackoverflow.com/questions/451845/orm-performance-cost
我举手并在任何说“EF 优于任何其他 ORM”的网站上致电 BS。
与其追求“最快的 ORM”，不如选择一个似乎相当受好评且符合您的需求的，然后开始编写。我在 ORM 选择上打电话给 BS，最终成为您的瓶颈。
性能是相对的，不同的ORM根据使用特性表现不同。数据库是大还是小？有多少连接/表/关系？您是否几乎只有 SELECT 或者您也有大量的 INSERT 或 UPDATE？高流量新闻网站将具有与高流量论坛/协作网站 (BBC.co.uk != en.wikipedia.org) 不同的特征，因此我在任何“ORM X 是最快的”声明中称其为 BS。 t 符合完整的基准。

【解决方案1】：

真正高流量的网站实际上正在完全远离 SQL 数据库，因为在当今的应用程序中普遍存在大量写入的工作负载，几乎不可能让它们扩展到一台机器之外，ORM 或没有 ORM .这被称为“NoSQL movement”

然而，虽然这是一个非常时髦的话题，但对于没有数千个活跃并发用户的网站来说，它是completely irrelevant。担心 ORM 性能也是类似的问题：事实上，大多数网站的“高流量”不足以让 ORM 成为问题（除非严重错误实现或应用）。

【讨论】：

【解决方案2】：

当然，reddit 使用了部分 SQLAlchemy（出于未知的原因，我相信他们重写了大部分内容：/）。大多数（如果不是全部）大型 Django 网站都使用 ORM（包括以前的 Pownce 和 Curse）。

【讨论】：

【解决方案3】：

jrista 是正确的。我只想补充一点，您应该认真考虑 LINQ to SQL。从简单性和性能的角度来看，它是更好的技术（目前）。它非常快速且开箱即用。如果您想进一步改进 LINQ to SQL，请查看PLINQO framework。

PLINQO 是一个围绕标准 LINQ to SQL 的框架，并添加了大量功能，包括一些非常优雅的批量操作和缓存功能。最重要的是，PLINQO 可以适应数据库模式的变化，但保留了您的自定义代码。这是非常巧妙的，在我看来，这是最有价值的方面。

【讨论】：

PLINQO 不是免费的，LinqToSql 有很多问题。 Subsonic 免费提供了极大的简单性。 NHibernate 免费扩展。
是的，PLINQO 是免费的。 Codesmith 不是，如果这就是你的意思

【解决方案4】：

虽然没有像Ayende（NHibernate 作者）指出的那样直接解决哪个 ORM 更快，但很容易出错或至少会按照您想要的方式倾斜，但这里有一些使用 ORMS 作为一部分的应用程序他们的应用程序。

Twitter 正在（曾经？）使用使用 ORM 的 Ruby on Rails (RoR)。 37 signal 的人在他们的应用程序中使用 RoR .... 我知道这些不是 .Net，但正如 kuoson 所提到的，L2S 受雇于 SO，并且有很多人使用 NHibernate，例如 Jeffrey Palermo 和 Headspring。如果发现许多最近开发的 Web 应用程序都在使用 ORM，我不会感到惊讶。

即使 ORM 确实会影响性能，但大多数 ORM 允许您在必要时自定义使用的 SQL。大多数人建议使用 ORM，然后在出现瓶颈时修复它们。此外，一个好的 ORM 可以为您解决很多问题，以至于如今编写自己的 DAL 变得更加困难。

【讨论】：

Twitter 不再使用 RoR 进行后端处理，主要是出于性能原因。
是的，但这并不意味着 ORM 不能执行。 :)

【解决方案5】：

目前，.NET 3.5 中发布的 EF v1.0 版本性能很差。一年多前，当它首次发布时，我进行了广泛的测试，并就该主题与 Microsoft 进行了多次长时间的电子邮件讨论。 EF 当前的效率有很多不足之处，而且在许多情况下，它会生成绝对糟糕的 SQL 查询，从而降低您的性能。

.NET 4.0 中的实体框架 v4.0 好很多。他们已经修复了大部分（如果不是全部）困扰 EF v1.0 的不良 SQL 生成问题（包括我一年前向他们提出的问题）。EF v4.0 是否具有最佳性能还有待观察。它比 LINQ to SQL 更复杂，因为它提供了更大的灵活性。由于还没有发布版本，无法说 EF v4.0 是否会是最快的。

对此的客观回答需要对主要的 ORM 竞争者进行客观、公正的比较，例如 EF、LINQ to SQL、nHibernate（最好使用 LINQ 提供程序）、LLBLGen，甚至一些新成员，例如 Telerik 的ORM、亚音速等。

对于使用 ORM 的大规模、大批量生产系统。我建议查看 StackOverflow.com 本身，它使用 LINQ to SQL。 SO 已经成为互联网上的顶级程序员社区之一，如果不是的话。这里绝对是高容量，而且这个网站表现出色。至于其他网站，我真的不能说。大多数主要 Web 应用程序的内部实现细节通常是个谜。我所知道的 ORM 的大多数用途也用于内部企业系统。金融系统、医疗保健等。对象数据库也用于相同类型的系统中，尽管它们的使用频率要低得多。我会搜索 ORM 使用和高容量网站。

搜索时需要注意的一点。确保您找到的评论是最新的。在过去的两年中，ORM 场景发生了很大变化。自从大约十年前首次创建 ORM 以来，性能、效率、功能、动态 SQL 的 RDBMS 调优能力等都得到了显着改善。

【讨论】：

这很奇怪，我对 EF 的体验是它产生了非常优化的查询，尤其是与至少 NHibernate 相比的连接。
如果我可以挖掘它们，我在旧的 msdn EF 论坛上有几个线程，它们展示了 EF v1.0 所具有的一些真正残暴的 SQL 生成。我将 L2S 生成的 SQL 与 EF 生成的 SQL 进行了比较，不仅 SQL 是几个级别的嵌套选择、空连接和其他奇怪的杂物的怪物……它执行的量级比 L2S 查询差了大约 10 个 ORDERS OF MAGNITUDE .在一种情况下，我试图从几百条连接中选择 90 条记录。 EF 查询以这样一种方式连接，SQL Server 必须在内部过滤 500 亿个虚拟行。

【解决方案6】：

我知道在其中一个播客中，Jeff 提到 stackoverflow 使用 Linq-to-SQL

【讨论】：