使用 ORM 与原始 SQL 的性能对比

2022 年 4 月 12 日
本文字数：1908 字
阅读完需：约 6 分钟

最近使用号称 python web 框架中性能最为强悍的框架 sanic , 搭建了项目的基础环境与项目框架,但是在是否使用 ORM 的时候犯了选择困难综合症了,对于一个追求性能的框架,在使用了 ORM 以后必定会对性能有些影响,但是影响究竟有多大呢? ORM 的存在也是有它的理由的, 那么它的优点能否消除它在性能上的损耗呢?

我主要使用了两个 ORM, 与其说是两个,其实也就是一个 sqlalchemy ,但是这里的 sqlalchemy 是两个不同库中的,一个是 aiomysql 中自带的 sqlalchemy, 我简称aiomysql.sa, 一个是大名鼎鼎的 sqlalchemy 库.

数据准备,就是一个简单的 user 表,里面有 id, username.

我是在查看 sanic 教程时, 它有提到如何使用 ORM, 它是用中间件的方式在处理每一个请求之前使用sessionmaker 创建了一个 session 挂到请求的上下文中,并且在结束请求时再将 session 关掉

@app.middleware("request")async def inject_session(request):    request.ctx.session = sessionmaker(bind, AsyncSession, expire_on_commit=False)()    request.ctx.session_ctx_token = _base_model_session_ctx.set(request.ctx.session)

@app.middleware("response")async def close_session(request, response):    if hasattr(request.ctx, "session_ctx_token"):        _base_model_session_ctx.reset(request.ctx.session_ctx_token)        await request.ctx.session.close()

复制代码

我隐约的感觉到这种方式可能会带来一些性能上的损耗,如果请求量很大的时候,每个请求都要重新创建一个 session 用于处理数据库,然后再释放掉,那么如果该请求没有进行数据库操作的时候,岂不是浪费了? 并且大量请求到来的时候，系统也要花费一定的资源用于这种创建与关闭，且这些 session 无法共用, 其实也不能说不能共用,我尝试过将 session 挂到 app.ctx 下, 也是可以用的,但是会有一个问题,如果某个请求需要比较长的时间,比如说 5 秒钟,那么下一个请求如果想要使用该 session, 那么就要等到之前的请求结束才可以复用.

所以以下的压力测试分为两个阶段,第一是不存在请求与响应中间件,这时就只对使用 aiomysql 库来进行压力测试.

第二阶段是在请求与响应前后加上中间件,这里会有三个测试.

以下是使用 wrk 进行的压测, 10 个线程,2000 个连接, 压测 10 秒钟得到的结果

服务端开启 4 个 workers, 使用 uvloop

使用纯 sql 语句查询

10 threads and 2000 connections  Thread Stats   Avg      Stdev     Max   +/- Stdev    Latency   558.19ms  200.95ms   1.32s    59.15%    Req/Sec   344.02    230.72     1.76k    68.29%  Latency Distribution     50%  583.50ms     75%  707.32ms     90%  819.57ms     99%    1.00s  33488 requests in 10.03s, 3.74MB readRequests/sec:   3337.65Transfer/sec:    381.35KB

复制代码

使用 aiomysql.sa 压测结果

10 threads and 2000 connections  Thread Stats   Avg      Stdev     Max   +/- Stdev    Latency   905.52ms  206.57ms   1.40s    65.57%    Req/Sec   231.70    202.40     1.12k    72.10%  Latency Distribution     50%  909.34ms     75%    1.05s     90%    1.17s     99%    1.33s  20031 requests in 10.03s, 2.24MB readRequests/sec:   1997.86Transfer/sec:    228.27KB

复制代码

以下为在请求与响应前后添加 session 钩子的压测结果

使用 sqlalchemy 在请求前后添加钩子时的压测结果

10 threads and 2000 connections  Thread Stats   Avg      Stdev     Max   +/- Stdev    Latency   638.07ms  632.25ms   2.00s    82.41%    Req/Sec   148.81     61.53   380.00     71.04%  Latency Distribution     50%  126.46ms     75%    1.15s     90%    1.54s     99%    1.96s  14094 requests in 10.02s, 1.57MB read  Socket errors: connect 0, read 0, write 0, timeout 2510Requests/sec:   1406.67Transfer/sec:    160.72KB

复制代码

这次还有 timeout 的超时错误.

之后的结果就不详细展示了,我总结了一张表格

可以简单的得到以下结论:

单纯的以吞吐量为衡量指标的话,纯 SQL 是添加 session 的 sqlalchemy 的 2.37 倍
在请求前后添加 session 会对性能有一些影响,大概有 20%的性能损耗.

以上只是单纯的从吞吐量来比较纯 SQL 与 ORM 之间的性能差异,其实有这样的性能差异也很好理解, ORM 会做一些对象的解析工作.

就我个人而言,我还是比较喜欢直接用 SQL 来进行查询, 我总觉得 ORM 还得熟悉它的各种查询条件,但是 ORM 对于后期切换数据库来说很方便,但是又有多少项目会切换数据库呢?

ORM 对于一些比较复杂的 sql 语句就更加难以控制.

但是如果你只是做一个很小的系统,请求量没有那么大的时候,我觉得使用 ORM 或者 SQL 应该都可以.

发布于: 刚刚阅读数: 3

原文链接:【http://xie.infoq.cn/article/9ba12da7f25dbaafc388d9a90】。文章转载请联系作者。

杨彦星

关注

还未添加个人签名 2018.08.08 加入

还未添加个人简介

发布

暂无评论

创作场景

使用 ORM 与原始 SQL 的性能对比

杨彦星

评论