浅谈优化Django ORM中的性能问题

2023-07-21 20:50:04 71

Django是个好工具，使用的很广泛。在应用比较小的时候，会觉得它很快，但是随着应用复杂和壮大，就显得没那么高效了。当你了解所用的Web框架一些内部机制之后，才能写成比较高效的代码。

怎么查问题

Web系统是个挺复杂的玩意，有时候有点无从下手哈。可以采用自底向上的顺序，从数据存储一直到数据展现，按照这个顺序一点一点查找性能问题。

数据库(缺少索引/数据模型)

数据存储接口(ORM/低效的查询)

展现/数据使用(Views/报表等)

Web应用的大部分问题都会跟数据库扯上关系。除非你正在处理大量的数据并知道你在做什么，否则不要去考虑用Big-O表示法思考View的问题。数据库调用的开销将使循环和模板渲染的开销相形见绌。不首先解决数据库使用中的问题，您就不能继续解决其他问题。

Django的文档中有那么一节，详细的描述了DB部分优化,ORM从一开始就应该写的比较高效一些（毕竟有那么多最佳实践)

优化，很多时候意味着代码可能变得不太清晰。当你遇到选择清晰的代码，还是牺牲清晰代码来获取性能上的一点点提高的时候，请优先考虑要代码的清晰整洁

工具

解决问题的第一步是找到问题，面对ORM，有时间事情可以做。

理解django.db.connection,这个对象可以用来记录当前查询花费的时间（知道了SQL语句查询的时间，当然就知道那里慢了)

>>>fromdjango.dbimportconnection
>>>connection.queries
[]
>>>Author.objects.all()
]>
>>>connection.queries
[{u'time':u'0.002',u'sql':u'SELECT"library_author"."id","library_author"."name"FROM"library_author"LIMIT21'}]

但是使用起来好像不是很方面。

在shell命令行的环境下，可以使用django-exension'sshell_plus命令并打开--print-sql选项。

pythonmanage.pyshell_plus--print-sql

>>>Author.objects.all()
SELECT"library_author"."id","library_author"."name"FROM"library_author"LIMIT21
Executiontime:0.001393s[Database:default]
]>

还有个更方面的方式,使用Django-debug-toolbar工具，就可以在web端查看SQL查询的详细统计结果，其实它功能远不止这个。

总结下3个方式

django.db.connectiondjango自身提供，比较底层

django-extensions可以在shell环境下方面调试

django-debug-toolbar可以在web端直接看到debug结果

案例

下面是用个具体的例子来说明一些问题

model定义

很经典的外键关系,Author和Book一对多的关系

classAuthor(models.Model):
name=models.TextField()

classBook(models.Model):
title=models.TextField()
author=models.ForeignKey(
Author,on_delete=models.PROTECT,related_name='books',null=True
)

多余的查询

当你检查一个book是否有author或者想获取这本书的author的id的时候，可能更倾向于直接使用author对象。

ifbook.author:
do_stuff()
#Or
do_stuff_with_author_id(book.author.id)

这里author对象其实并不需要（主要指第一行代码，其实只需要author_id)，会导致一次多余的查询。如果后面需要author对象，在获取也不冲突。比较好的习惯是，直接使用字段名,见下面的写法。

ifbook.author_id:
do_stuff()

do_stuff_with_author_id(book.author_id)

count和exists

对于初学者,知道什么时候使用count和exists还是挺难的。Django会缓存查询结果,所以如果后续的操作会用到这些查询出来的数据，可以使用Python的内置方法(指的是len，if判断queryset，下面例子)。如果不用查询出的数据，使用queryset提供的方法(count(),exists())

#Don'twasteaqueryifyouareusingthequeryset
books=Book.objects.filter(..)
ifbooks:
do_stuff_with_books(books)

#Ifyouaren'tusingthequerysetuseexist
books=Book.objects.filter(..)
ifbooks.exists():
do_some_stuff()

#Butnever
ifBook.objects.filter(..):
do_some_stuff()

下面是关于count和len的例子

#Don'twasteaqueryifyouareusingthequeryset
books=Book.objects.filter(..)
iflen(books)>5:
do_stuff_with_books(books)

#Ifyouaren'tusingthequerysetusecount
books=Book.objects.filter(..)
ifbooks.count()>5:
do_some_stuff()

#Butnever
iflen(Book.objects.filter(..))>5:
do_some_stuff()

只获取需要的数据

默认情况下，ORM查询的时候会把数据库记录对应的所有列取出来，然后转换成Python对象，这无疑是个很大的浪费嘛(有时候只想要一两个列的，宝宝心理��)。当你只需要某些列的时候可以使用values或者values_list,它们不是把数据转换成复杂的python对象，而是dicts,tuples等。

#Retrievevaluesasadictionary
>>>Book.objects.values('title','author__name')


#Retrievevaluesasatuple
>>>Book.objects.values_list('title','author__name')

>>>Book.objects.values_list('title')


#Withonevalue,itiseasiertoflattenthelist
>>>Book.objects.values_list('title',flat=True)

处理很多记录

当你获得一个queryset的时候，Django会缓存这些数据。如果你需要对查询结果进行好几次循环，这种缓存是有意义的，但是对于queryset只循环一次的情况，缓存就没什么意义了。

forbookinBooks.objects.all():

do_stuff(book)

上面的查询，django会把books所有的数据欧载入内存，然后进行一次循环。其实我们更想要保持这个数据库connection,每次循环的取出一条book数据，然后调用do_stuff。iterator就是我们的救星。

forbookinBooks.objects.all().iterator():

do_stuff(book)

有了iterator，你就可以编写线性数据表或者CSV流了。就能增量写入文件或者发送给用户。

特别是跟values，values_list结合在一起的时候，能尽可能少的使用内存。在需要对表中的每一行进行修改的迁移期间，使用iterator也非常方便。不能因为迁移不是面向客户的就可以降低对效率的要求。长时间运行的迁移可能意味着事务锁定或停机。

关联查询问题

DjangoORM的API使得我们使用关系型数据库的时候就像使用面向对象的Python语言那样自然。

#GettheAuthor'snameofaBook
book=Book.objects.first()
book.author.name

上面的代码相当的清晰和好理解。Django使用lazyloading（懒加载)的方式，只有用到了author对象时候才会加载。这样做有好处，但是会造成爆炸��式的查询。

>>>Author.objects.count()
20
>>>Book.objects.count()
100
#Thisblockis101queries.
#1forthebooksand1foreachauthorthatlazy-loaded
books=Book.objects.all()
forbookinbooks:
do_stuff(book.title,book.author.name)

#Thisblockis20queries.
#1fortheauthorand1forthebooksofeachauthor
authors=Author.objects.all()
forauthorinauthors:
do_stuff_with_books(author.name,author.books.all())

Django意识到了这种问题，并提供select_related和prefetch_related来解决。

#Thisblockis1query
#Theauthorsofallthebooksarepre-fetchedinonequery
book=Book.objects.selected_related('author').all()
forbookinbooks:
do_stuff(book.title,book.author)

#Thisblockis1query
#Thebooksofalltheauthorsarepre-fetchedinonequery
authors=Author.objects.prefetch_related('books').all()
forauthorinauthors:
do_stuff_with_books(author.name,author.books.all())

在Djangoapp中使用prefetch_related和select_related的时候要谨慎。

prefetch_related有个坑，当你像要在related查询中使用filter时候author.books.filter(..),之前在prefetch_related中的缓存就无法使用了，相对于author.books.all()来说的。有些事情会变的复杂了，你最好2次查询来解决这种问题，上级对象和它的子对象各一次，然后在进行聚合。如果prefetch太复杂了，这时候就要在代码的整洁清晰和应用性能之间做一个取舍了。

最好是了解下prefetch_related和select_related的区别，文档在这

select_related不好用的时候

某些情况下select_related会变得不好使。看看下面的例子，id()方法用来判断Python对象实例的唯一性，如果id结果相同，表示同一个对象实例。

>>>[(id(book.author),book.author.pk)forbookinBook.objects.select_related('author')]

[(4504798608,1),(4504799824,1)]

select_related为查询的每个row，创建了一个新对象，耗费了大量的内存（上面的结果中，对于数据库中的同一个author对象创建了不同的python对象）。SQL一会为每行返回重复的信息。如果你进行一个查询，其中select_related查询的所有值都是相同的，你就需要使用别的东西。使用相关查询或翻转(flip)查询并使用prefetch_related。

使用author.books.all()结合对象相关查询，Django会为每个已经查询的book记录保存相同的author对象

>>id(author)
4504693520
>>>[(id(book.author),book.author.pk)forbookinauthor.books.all()]
[(4504693520,1),(4504693520,1)]

使用select_related还有一个隐含问题，当你修改一个author对象的时候，如果其他book也关联到这个author，这个改变不会传播过去，因为它们在python内存中是不同的对象实例。如果使用对象相关查询，修改就能传播。

简单不一定更好

Django使得关系查询太容易了，这也带来了一些副作用。当你将一个对象传入函数中，接着使用了relationship(对象关系),实际上无法知道这种关联的数据是否已经从数据库取出来。

defauthor_name_length(book):
returnlen(book.author.name)

defprocess_author_books(author):
forbookinauthor.books.all():
do_stuff(book)

上面的函数中author_name_length和process_author_books,谁将会查询？我们无从所知。DjangoORM中的关联查询非常好用，我们自然希望使用这种方式。在一个循环中，如果不使用select_related或者prefetch_related，可能会导致几百个查询。Django只会知道查询，而不会多看一眼。这种情况只能依靠SQL的logs，还有函数调用来监控，然后确定是否进行预查询。

我们可以重写函数，参数的传递采用扁平的数据结构，类似namedtuple,而不是model，但这种别考虑这种方案。

怎么修复?

我们已经知道了这个问题，那么怎样拓展Django能让我们更明确的知道资源的消耗呢。很多数据库的封装已经通过不同的方式解决了这个问题。在Ecto中，Elixir的数据库封装，一个没有获取数据的关系调用会返回Ecto.Association.NotLoaded提示，而不是默默的查询。

我们可以想象Django的某个版本使用pythonic的方式实现了这种功能。

>>>book.author.name
Traceback(mostrecentcalllast):
File"",line1,in
File"/Users/kyle/orm_test/library/models.py",line18,in__get__
'Use`select_related`or`fetch_{rel}`'.format(rel=self.field.name)
RelationNotLoaded:Relation`author`notloaded.Use`select_related`or`fetch_author`

#Weexplicitlyfetchtheresource
>>>book.fetch_author()

>>>book.author.name
"FyodorDostoevsky"

#Selectrelatedworksjustaswell
>>>book=Book.objects.select_related('author').first()
>>>book.author.name
"AntonChekhov"

总结

ORM的使用并没有固定的标准。对于小的应用来说，优化可能并没有多么明显的效果。应该以代码清晰为优先，然后在考虑优化的事情。程序增长过程中，对ORM的使用一定要保持好的习惯。养成对资源消耗敏感的习惯，以后会有很多好处。

优化的方法很多，对于长远来说了解一些原则更为实用

习惯隔离代码并记录产生的查询

不要在循环中查询

了解ORM是怎么缓存数据的

知道Django何时会做查询

不要以牺牲清晰度为代价过度优化

以上这篇浅谈优化DjangoORM中的性能问题就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持毛票票。

浅谈优化Django ORM中的性能问题

热门推荐

随机推荐