您好,登錄后才能下訂單哦!
這篇文章主要介紹如何優(yōu)化Django中ORM的性能問題,文中介紹的非常詳細(xì),具有一定的參考價值,感興趣的小伙伴們一定要看完!
Django是個好工具,使用的很廣泛。 在應(yīng)用比較小的時候,會覺得它很快,但是隨著應(yīng)用復(fù)雜和壯大,就顯得沒那么高效了。當(dāng)你了解所用的Web框架一些內(nèi)部機制之后,才能寫成比較高效的代碼。
怎么查問題
Web系統(tǒng)是個挺復(fù)雜的玩意,有時候有點無從下手哈??梢圆捎?自底向上 的順序,從數(shù)據(jù)存儲一直到數(shù)據(jù)展現(xiàn),按照這個順序一點一點查找性能問題。
數(shù)據(jù)庫 (缺少索引/數(shù)據(jù)模型)
數(shù)據(jù)存儲接口 (ORM/低效的查詢)
展現(xiàn)/數(shù)據(jù)使用 (Views/報表等)
Web應(yīng)用的大部分問題都會跟 數(shù)據(jù)庫 扯上關(guān)系。除非你正在處理大量的數(shù)據(jù)并知道你在做什么,否則不要去考慮用Big-O表示法思考View的問題。 數(shù)據(jù)庫調(diào)用的開銷將使循環(huán)和模板渲染的開銷相形見絀。 不首先解決數(shù)據(jù)庫使用中的問題,您就不能繼續(xù)解決其他問題。
Django的文檔中有那么一節(jié),詳細(xì)的描述了DB部分優(yōu)化, ORM 從一開始就應(yīng)該寫的比較高效一些(畢竟有那么多最佳實踐)
優(yōu)化,很多時候意味著代碼可能變得不太清晰。當(dāng)你遇到選擇清晰的代碼,還是犧牲清晰代碼來獲取性能上的一點點提高的時候,請優(yōu)先考慮要代碼的清晰整潔
工具
解決問題的第一步是找到問題,面對 ORM,有時間事情可以做。
理解 django.db.connection, 這個對象可以用來記錄當(dāng)前查詢花費的時間(知道了SQL語句查詢的時間,當(dāng)然就知道那里慢了)
>>> from django.db import connection >>> connection.queries [] >>> Author.objects.all() <QuerySet [<Author: Author object>]> >>> connection.queries [{u'time': u'0.002', u'sql': u'SELECT "library_author"."id", "library_author"."name" FROM "library_author" LIMIT 21'}]
但是使用起來好像不是很方面。
在shell命令行的環(huán)境下,可以使用 django-exension's shell_plus 命令并打開 --print-sql 選項。
python manage.py shell_plus --print-sql >>> Author.objects.all() SELECT "library_author"."id", "library_author"."name" FROM "library_author" LIMIT 21 Execution time: 0.001393s [Database: default] <QuerySet [<Author: Author object>]>
還有個更方面的方式, 使用 Django-debug-toolbar 工具,就可以在web端查看SQL查詢的詳細(xì)統(tǒng)計結(jié)果,其實它功能遠(yuǎn)不止這個。
總結(jié)下3個方式
django.db.connection django自身提供,比較底層
django-extensions 可以在shell環(huán)境下方面調(diào)試
django-debug-toolbar 可以在web端直接看到debug結(jié)果
案例
下面是用個具體的例子來說明一些問題
model 定義
很經(jīng)典的外鍵關(guān)系, Author 和 Book 一對多的關(guān)系
class Author(models.Model): name = models.TextField() class Book(models.Model): title = models.TextField() author = models.ForeignKey( Author, on_delete=models.PROTECT, related_name='books', null=True )
多余的查詢
當(dāng)你檢查一個book是否有author或者想獲取這本書的author 的id的時候,可能更傾向于直接使用 author 對象。
if book.author: do_stuff() # Or do_stuff_with_author_id(book.author.id)
這里 author對象 其實并不需要(主要指第一行代碼,其實只需要author_id),會導(dǎo)致一次多余的查詢。 如果后面需要 author對象,在獲取也不沖突。 比較好的習(xí)慣是,直接使用字段名, 見下面的寫法。
if book.author_id: do_stuff() do_stuff_with_author_id(book.author_id)
count 和 exists
對于初學(xué)者, 知道什么時候使用 count 和 exists 還是挺難的。 Django會緩存查詢結(jié)果, 所以如果后續(xù)的操作會用到這些查詢出來的數(shù)據(jù) ,可以使用 Python的內(nèi)置方法(指的是len,if判斷queryset,下面例子)。如果不用查詢出的數(shù)據(jù),使用queryset提供的方法(count(), exists())
# Don't waste a query if you are using the queryset books = Book.objects.filter(..) if books: do_stuff_with_books(books) # If you aren't using the queryset use exist books = Book.objects.filter(..) if books.exists(): do_some_stuff() # But never if Book.objects.filter(..): do_some_stuff()
下面是關(guān)于count 和 len 的例子
# Don't waste a query if you are using the queryset books = Book.objects.filter(..) if len(books) > 5: do_stuff_with_books(books) # If you aren't using the queryset use count books = Book.objects.filter(..) if books.count() > 5: do_some_stuff() # But never if len(Book.objects.filter(..)) > 5: do_some_stuff()
只獲取需要的數(shù)據(jù)
默認(rèn)情況下,ORM 查詢的時候會把數(shù)據(jù)庫記錄對應(yīng)的所有列取出來,然后轉(zhuǎn)換成 Python對象,這無疑是個很大的浪費嘛(有時候只想要一兩個列的,寶寶心理��)。當(dāng)你只需要某些列的時候可以使用 values 或者 values_list, 它們不是把數(shù)據(jù)轉(zhuǎn)換成復(fù)雜的 python 對象,而是dicts, tuples等。
# Retrieve values as a dictionary >>> Book.objects.values('title', 'author__name') <QuerySet [{'author__name': u'Nikolai Gogol', 'title': u'The Overcoat'}, {'author__name': u'Leo Tolstoy', 'title': u'War and Peace'}]> # Retrieve values as a tuple >>> Book.objects.values_list('title', 'author__name') <QuerySet [(u'The Overcoat', u'Nikolai Gogol'), (u'War and Peace', u'Leo Tolstoy')]> >>> Book.objects.values_list('title') <QuerySet [(u'The Overcoat',), (u'War and Peace',)]> # With one value, it is easier to flatten the list >>> Book.objects.values_list('title', flat=True) <QuerySet [u'The Overcoat', u'War and Peace']>
處理很多記錄
當(dāng)你獲得一個 queryset 的時候,Django會緩存這些數(shù)據(jù)。 如果你需要對查詢結(jié)果進(jìn)行好幾次循環(huán),這種緩存是有意義的,但是對于 queryset 只循環(huán)一次的情況,緩存就沒什么意義了。
for book in Books.objects.all():
do_stuff(book)
上面的查詢,django會把books所有的數(shù)據(jù)歐載入內(nèi)存,然后進(jìn)行一次循環(huán)。其實我們更想要保持這個數(shù)據(jù)庫 connection, 每次循環(huán)的取出一條book數(shù)據(jù),然后調(diào)用 do_stuff。iterator 就是我們的救星。
for book in Books.objects.all().iterator():
do_stuff(book)
有了 iterator,你就可以編寫線性數(shù)據(jù)表或者CSV流了。就能增量寫入文件或者發(fā)送給用戶。
特別是跟 values,values_list 結(jié)合在一起的時候,能盡可能少的使用內(nèi)存。在需要對表中的每一行進(jìn)行修改的遷移期間,使用iterator也非常方便。 不能因為遷移不是面向客戶的就可以降低對效率的要求。 長時間運行的遷移可能意味著事務(wù)鎖定或停機。
關(guān)聯(lián)查詢問題
Django ORM的API使得我們使用關(guān)系型數(shù)據(jù)庫的時候就像使用面向?qū)ο蟮?Python 語言那樣自然。
# Get the Author's name of a Book book = Book.objects.first() book.author.name
上面的代碼相當(dāng)?shù)那逦秃美斫?。Django 使用 lazy loading(懶加載)的方式,只有用到了 author 對象時候才會加載。這樣做有好處,但是會造成爆炸��式的查詢。
>>> Author.objects.count() 20 >>> Book.objects.count() 100 # This block is 101 queries. # 1 for the books and 1 for each author that lazy-loaded books = Book.objects.all() for book in books: do_stuff(book.title, book.author.name) # This block is 20 queries. # 1 for the author and 1 for the books of each author authors = Author.objects.all() for author in authors: do_stuff_with_books(author.name, author.books.all())
Django 意識到了這種問題,并提供 select_related 和 prefetch_related 來解決。
# This block is 1 query # The authors of all the books are pre-fetched in one query book = Book.objects.selected_related('author').all() for book in books: do_stuff(book.title, book.author) # This block is 1 query # The books of all the authors are pre-fetched in one query authors = Author.objects.prefetch_related('books').all() for author in authors: do_stuff_with_books(author.name, author.books.all())
在Django app中使用 prefetch_related 和 select_related 的時候要謹(jǐn)慎。
prefetch_related 有個坑,當(dāng)你像要在related查詢中使用 filter時候author.books.filter(..), 之前在 prefetch_related 中的緩存就無法使用了,相對于 author.books.all() 來說的。有些事情會變的復(fù)雜了,你最好2次查詢來解決這種問題,上級對象和它的子對象各一次,然后在進(jìn)行聚合。 如果 prefetch太復(fù)雜了,這時候就要在代碼的整潔清晰和應(yīng)用性能之間做一個取舍了。
最好是了解下 prefetch_related 和 select_related 的區(qū)別,文檔在這
select_related 不好用的時候
某些情況下 select_related 會變得不好使。 看看下面的例子,id() 方法用來判斷 Python 對象實例的唯一性,如果 id結(jié)果相同,表示同一個 對象實例。
>>> [(id(book.author), book.author.pk) for book in Book.objects.select_related('author')]
[(4504798608, 1), (4504799824, 1)]
select_related 為查詢的每個row,創(chuàng)建了一個新對象,耗費了大量的內(nèi)存(上面的結(jié)果中,對于數(shù)據(jù)庫中的同一個author對象創(chuàng)建了不同的python對象)。SQL一會為每行返回重復(fù)的信息。 如果你進(jìn)行一個查詢,其中select_related 查詢的所有值都是相同的,你就需要使用別的東西。 使用相關(guān)查詢或翻轉(zhuǎn)(flip)查詢并使用prefetch_related。
使用 author.books.all() 結(jié)合對象相關(guān)查詢,Django會為每個已經(jīng)查詢的book記錄保存相同的author對象
>> id(author) 4504693520 >>> [(id(book.author), book.author.pk) for book in author.books.all()] [(4504693520, 1), (4504693520, 1)]
使用 select_related 還有一個隱含問題,當(dāng)你修改一個author 對象的時候,如果其他book也關(guān)聯(lián)到這個author,這個改變不會傳播過去,因為它們在python內(nèi)存中是不同的對象實例。如果使用 對象相關(guān)查詢,修改就能傳播。
簡單不一定更好
Django使得關(guān)系查詢太容易了,這也帶來了一些副作用。當(dāng)你將一個對象傳入函數(shù)中,接著使用了 relationship (對象關(guān)系), 實際上無法知道這種關(guān)聯(lián)的數(shù)據(jù)是否已經(jīng)從數(shù)據(jù)庫取出來。
def author_name_length(book): return len(book.author.name) def process_author_books(author): for book in author.books.all(): do_stuff(book)
上面的函數(shù)中 author_name_length 和 process_author_books, 誰將會查詢? 我們無從所知。 Django ORM中的關(guān)聯(lián)查詢非常好用,我們自然希望使用這種方式。在一個循環(huán)中,如果不使用 select_related 或者 prefetch_related,可能會導(dǎo)致幾百個查詢。Django只會知道查詢,而不會多看一眼。這種情況只能依靠SQL的logs,還有函數(shù)調(diào)用來監(jiān)控,然后確定是否進(jìn)行預(yù)查詢。
我們可以重寫函數(shù),參數(shù)的傳遞采用扁平的數(shù)據(jù)結(jié)構(gòu),類似 namedtuple, 而不是 model,但這種別考慮這種方案。
怎么修復(fù)?
我們已經(jīng)知道了這個問題,那么怎樣拓展Django能讓我們更明確的知道資源的消耗呢。很多數(shù)據(jù)庫的封裝已經(jīng)通過不同的方式解決了這個問題。在Ecto中,Elixir的數(shù)據(jù)庫封裝,一個沒有獲取數(shù)據(jù)的關(guān)系調(diào)用會返回 Ecto.Association.NotLoaded 提示,而不是默默的查詢。
我們可以想象Django的某個版本使用 pythonic 的方式實現(xiàn)了這種功能。
>>> book.author.name Traceback (most recent call last): File "<console>", line 1, in <module> File "/Users/kyle/orm_test/library/models.py", line 18, in __get__ 'Use `select_related` or `fetch_{rel}`'.format(rel=self.field.name) RelationNotLoaded: Relation `author` not loaded. Use `select_related` or `fetch_author` # We explicitly fetch the resource >>> book.fetch_author() <Author: Author object> >>> book.author.name "Fyodor Dostoevsky" # Select related works just as well >>> book = Book.objects.select_related('author').first() >>> book.author.name "Anton Chekhov"
ORM 的使用并沒有固定的標(biāo)準(zhǔn)。對于小的應(yīng)用來說,優(yōu)化可能并沒有多么明顯的效果。應(yīng)該以代碼清晰為優(yōu)先,然后在考慮優(yōu)化的事情。程序增長過程中,對 ORM 的使用一定要保持好的習(xí)慣。養(yǎng)成對資源消耗敏感的習(xí)慣,以后會有很多好處。
優(yōu)化的方法很多,對于長遠(yuǎn)來說了解一些原則更為實用
習(xí)慣隔離代碼并記錄產(chǎn)生的查詢
不要在循環(huán)中查詢
了解 ORM 是怎么緩存數(shù)據(jù)的
知道 Django 何時會做查詢
不要以犧牲清晰度為代價過度優(yōu)化
以上是如何優(yōu)化Django中ORM的性能問題的所有內(nèi)容,感謝各位的閱讀!希望分享的內(nèi)容對大家有幫助,更多相關(guān)知識,歡迎關(guān)注億速云行業(yè)資訊頻道!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。