ORM查询性能与RDBMS性能比较

Question

ORM查询性能与RDBMS性能比较

3

我正在使用laravel框架开发一个应用程序，希望能够测量ORM查询（CRUD）性能并将其与RDBMS查询性能进行比较。

我需要证明ORM查询性能优于RDBMS，但我在某个地方读到过Eloquent Laravel的查询性能很慢。我需要做出正确的决定，以展示所需的结果。Doctrine比Eloquent ORM更好吗？此外，您建议我使用哪个基准测试？我需要这些结果作为我的论文材料。

- user3660185

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Shauna · Accepted Answer

您在这里是把苹果和橙子进行比较。按照定义，RDBMS（关系型数据库管理系统）始终会更快，因为RDBMS是您的数据库，例如MySQL，SQL Server，PostgreSQL等。数据库只做一件事情非常好--处理数据（好吧，根据您的看法，可能有两件事情--存储和检索数据）。由于从任何其他语言访问数据库的每种方式都至少要比直接访问数据库本身慢一步，因此如果没有其他原因，那么所有东西都比RDBMS本身慢，因为该语言的解释器必须首先连接到数据库，然后才能执行任何操作。话虽如此，在使用PHP处理数据库时还有几个不同的层次可用：

使用PHP内置的mysql_*函数的原始查询。
基本的数据库抽象层（即-PDO）
基本查询构建器（即-Laravel的查询构建器）
活动记录模式ORM（即-Eloquent）
无状态/事务性ORM（即-Doctrine）

假设开发人员提供的查询已经完美优化，通过给定的方法传递原始查询将是最快的，其次是基本的DBAL，再次是任何构建在基本DBAL之上的内容。查询构建器及其构建的ORM将取决于查询构建器本身是否建立在另一个DBAL之上（在这种情况下，我认为它使Eloquent比Doctrine多了一层，因为Eloquent是建立在Query Builder之上，而Query Builder是建立在PDO之上）。这是因为每个抽象层都是前一个抽象层的上层，所以当执行代码时，路径必须通过整个堆栈运行。

那么问题就是我们要讨论多大程度的差别？这完全取决于您向系统提供的查询以及系统本身的质量。您要展示什么样的差异？它能多快地执行基本的SELECT语句吗？还是它能多好地执行一些疯狂的多重JOIN查询？什么决定了您论文目的的“速度”？只有您可以真正决定，因为您拥有比这里任何人都更多的信息。为了全面起见，您可能正在查看基本的SELECT语句，包括像JOIN、ORDER BY和GROUP BY这样的复杂查询，以及INSERT和UPDATE命令。

不过我告诉你——任何用来展示速度差异的测试都可能需要成千上万甚至更多的交易，至少才能显示出任何显著的差异，因为在单个交易级别上，我们正在谈论微秒甚至纳秒的差异。

在实际的行业应用中，我们如何决定采用哪种方法？编写和维护代码的速度和易用性。在这方面，ORM或DBAL通常会击败原始查询。每个脚本运行损失的抽象开销，可以通过节省开发人员编写和维护有关代码的时间成本而一次又一次地收回数千倍。

事实上，当您开始考虑ORM vs DBAL vs原始查询实际上很重要时，很可能您已经开始质疑您的原始数据库、语言解释器或服务器是否符合软件的要求。这实际上是Facebook几年前开始面临的问题，在那时，他们开始将部分PHP转移到C，因为在某些情况下C更快。这也是为什么他们为PHP代码创建了全新的解释器(HipHop Virtual Machine或HHVM)，其速度比原始的PHP引擎快得多的原因。