ORM查询性能与RDBMS性能

根据定义,RDBMS总是会更快,因为RDBMS是您的数据库(RDBMS =关系数据库管理系统). IE – MySQL,SQL Server,PostgreSQL等.数据库确实做了一件事,非常好 – 处理数据(好吧,两件事,取决于你如何看待它 – 存储和检索数据).

由于从任何其他语言访问数据库的每一种方式都至少从数据库本身移除了一步,所以一切都比RDBMS本身慢,如果没有其他原因,语言的解释器必须首先连接到数据库至少一次,在它可以做任何事之前.

也就是说,在PHP中处理数据库时,有几个不同的层可用：

>使用PHP内置的mysql_ *函数进行原始查询.
>基本数据库抽象层(即 – PDO)
>基本查询构建器(即 – Laravel的查询生成器)
>活动记录模式ORM(即 – 雄辩)
>无状态/交易ORM(即 – 主义)

假设开发人员将完美优化的查询提供给给定方法,原始查询将是最快的,其次是基本DBAL,然后是基本DBAL之上构建的任何内容.查询构建器和构建在它们上面的ORM将取决于查询构建器本身是否构建在另一个DBAL之上(在这种情况下,我认为它使Eloquent比Doctrine更多一层被删除,因为Eloquent构建在Query上Builder,它建立在PDO上).这是因为每个都是前一个的抽象层,因此代码的路径在执行时必须通过堆栈运行.

那么问题就变成了我们谈论的差异有多大？这完全取决于您向系统提供的查询以及系统本身的质量.你在寻找什么表明差异？它能以多快的速度完成一个基本的SELECT？或者它可以做多少疯狂的多连接查询？什么决定了论文目的的“速度”？只有你能真正决定,因为你有比这里任何人更多的信息.为了彻底起见,您可能正在查看基本的SELECT,包括JOIN,ORDER BY和GROUP BY以及INSERT和UPDATE命令之类的复杂查询.

我会告诉你这一点 – 任何显示速度差异的测试都可能会成千上万或数万笔交易,至少为了显示任何重大差异,因为在个人交易层面,我们正在谈论差异中的微秒甚至纳秒.

那么,在实际的行业用途中,我们如何决定走哪条路？编写和维护代码的速度和简便性.在那个方面,ORMs or DBALs will very often beat out raw queries.对于编写和维护所讨论的代码所花费的时间,每个脚本运行丢失到抽象开销的一小部分在开发者成本中被恢复成千上万次.

事实上,当你到达ORM与DBAL与原始查询实际上重要的时候,你开始质疑你的原始数据库,语言翻译或服务器是否与你的软件需求相提并论的可能性很大.这实际上是Facebook几年前开始面临的问题,此时他们开始将部分PHP卸载到C,因为在某些情况下C更快.这也是为什么他们为PHP代码(HipHop虚拟机或HHVM)创建了一个全新的解释器,它比原始的PHP引擎快得多.