Lapisan basisdata Django menyediakan beragam cara membantu pengembang mendapatkan sebagian dari basisdata mereka. DOkumen ini mengumpulkan bersama-sama tautan ke dokumentasi bersangkutan, dan menambah beraagam tip, mengorganisasikan dibawah sejumlah dari kepala yang meringkaskan langkah-langkah diambil ketika berusaha mengoptimalkan penggunaan basisdata anda.
\nAs general programming practice, this goes without saying. Find out what\nqueries you are doing and what they are costing you.\nUse QuerySet.explain() to understand how specific QuerySets are\nexecuted by your database. You may also want to use an external project like\ndjango-debug-toolbar, or a tool that monitors your database directly.
Ingat bahwa anda mungkin dioptimalkan untuk kecepatan atau memori atau keduanya, tergantung pada persyaraan anda. Terkadang mengoptimalkan untuk satu akan merugikan ke yang lain, tetapi terkadang mereka akan membantu satu sama lain. Juga, pekerjaan itu selesai oleh pengolahan basisdata mungkin tidak mempunyai biaya sama (kepada anda) seperti sama banyak dari pekerjaan selesai dalam pengolahan Python anda. Itu terserah anda memutuskan apa prioritas anda, dimana keseimbangan harus berbohong, dan profil semua dari ini seperti diwajibkan sejak ini akan bergantung pada aplikasi anda dan peladen.
\nDengan apapun yang mengikuti, ingat untuk menggambarkan raut muka setelah setiap perubahan untuk memastikan bahwa perubahan adalah menguntungkan, dan keuntungan cukup besar diberikan menurunkan dalam kesiapan kode anda. Semua dari saran-saran dibawah datang dengan surat keberatan yang dalam keadaan anda prinsip umum mungkin tidak berlaku, atau mungkin bahkan dibalikkan.
\n...termasuk:
\nIndexes. This is a number one priority, after you have determined from\nprofiling what indexes should be added. Use\nMeta.indexes or\nField.db_index to add these from\nDjango. Consider adding indexes to fields that you frequently query using\nfilter(),\nexclude(),\norder_by(), etc. as indexes may help\nto speed up lookups. Note that determining the best indexes is a complex\ndatabase-dependent topic that will depend on your particular application.\nThe overhead of maintaining an index may outweigh any gains in query speed.
Penggunaan sesuai dari jenis-jenis bidang
We will assume you have done the things listed above. The rest of this document\nfocuses on how to use Django in such a way that you are not doing unnecessary\nwork. This document also does not address other optimization techniques that\napply to all expensive operations, such as general purpose caching.
\nQuerySetLink to this heading#Memahami QuerySets adalah vital untuk mendapatkan penampilan baik dengan kode sederhana. Khususnya:
\nQuerySetLink to this heading#Untuk menghindari masalah penampilan, sangatlah penting memahami:
\nitu QuerySets malas.
ketika mereka dinilai.
bagaimana data ditahan dalam memori.
As well as caching of the whole QuerySet, there is caching of the result of\nattributes on ORM objects. In general, attributes that are not callable will be\ncached. For example, assuming the example blog models:
>>> entry = Entry.objects.get(id=1)\n>>> entry.blog # Blog object is retrieved at this point\n>>> entry.blog # cached version, no DB access\nTetapi secara umum, atribut callable menyebabkan pencarian DB setiap waktu:
\n>>> entry = Entry.objects.get(id=1)\n>>> entry.authors.all() # query performed\n>>> entry.authors.all() # query performed again\nHati-hati ketika membaca kode cetakan - sistem cetakan tidak mengizinkan penggunaan tanda kurun, tetapi akan memanggil callable secara otomatis, memnyembunyikan perbedaan diatas.
\nBerhati-hatilan dengan sifat penyesuaian anda sendiri - itu terserah anda menerapkan cache ketika dibutuhkan, sebagai contoh menggunakan penghias cached_property.
withLink to this heading#Untuk menggunakan perilaku cache dari QuerySet, anda mungkin butuh menggunakan etiket cetakan with.
iterator()Link to this heading#Ketika anda mempunyai banyak obyek, perilaku cache dari QuerySet dapat menyebabkan sejumlah besar memori digunakan. Dalam kasus ini, iterator() mungkin membantu.
explain()Link to this heading#QuerySet.explain() gives you detailed information about how the database\nexecutes a query, including indexes and joins that are used. These details may\nhelp you find queries that could be rewritten more efficiently, or identify\nindexes that could be added to improve performance.
Sebagai contoh:
\nPada paling tingkat dasar, gunakan filter and exclude melakukan penyaringan di basisdata
Gunakan F expressions untukmenyaring berdasarkan pada bidang-bidang lain dalam model sama.
Jika ini tidak cukup membangkitkan SQL yang anda butuhkan:
\nRawSQLLink to this heading#Sedikit ringan tetapi metode lebih kuat adalah pernyataan RawSQL, yangmengizinkan beberapa SQL secara jelas ditambahkan ke permintaan. Jika itu masih tidak cukup kuat:
Tulis custom SQL to retrieve data or populate models 1 anda sendiri. Gunakan django.db.connection.queries untuk menemukan apa yang Django sedang tulis untuk anda dan mulai dari sana.
Ada dua alasan untuk menggunakan kolom dengan unique atau db_index ketika menggunakan get() untuk mengambil obyek tersendiri. Pertama, permintaan akan lebih cepat karena indeks basisdata pokok. Juga, permintaan dapat berjalan lebih lambat jika banyak obyek mencocokan pencarian; memiliki batasan unik pada kolom menjamin ini tidak pernah terjadi.
So using the example blog models:
\n>>> entry = Entry.objects.get(id=10)\nakan lebih cepat daripada:
\n>>> entry = Entry.objects.get(headline="News Item Title")\nkarena id diindeks oleh basisdata dan dijamin menjadi unik.
Melakukan berikut berpotensi sangat lambat:
\n>>> entry = Entry.objects.get(headline__startswith="News")\nPertama-tama, headline tidak diindeks, yang akan membuat pengambilan pokok basisdata lebih lambat.
Kedua, pencarian tidak menjamin hanya satu obyek akan dikembalikan. Jika permintaan cocok lebih dari satu obyek, itu akan mengambil dan memindahkan semua dari mereka dari basisdata. Hukuman ini dapat besar jika ratusan atau ribuan dari rekaman dikembalikan. Hukuman akan digabungkan jika basisdata berada pada peladen berbeda, dimana overhead jaringan dan latensi memainkan faktor.
\nMengenai basisdata beberapa kali untuk bagian-bagian berbeda dari 'set' tunggal data yang anda akan butuh semua bagian, secara umum, kurang efisien dari mengambil itu semua dalam satu permintaan. Ini khususnya penting jika anda mempunyai sebuah permintaan yang dijalankan dalam putaran, dan dapat karena itu berakhir melakukan banyak permintaan basisdata, ketika hanya satu dibutuhkan. Jadi:
\n\nQuerySet.values() dan values_list()Link to this heading#When you only want a dict or list of values, and don't need ORM model\nobjects, make appropriate usage of\nvalues().\nThese can be useful for replacing model objects in template code - as long as\nthe dicts you supply have the same attributes as those used in the template,\nyou are fine.
QuerySet.defer() dan only()Link to this heading#Gunakan defer() dan only() jika ada kolom basisdata anda ketahui bahwa anda tidak butuh (atau tidak butuh dalam kebanyakan kasus) untuk menghindari memuatkan mereka. Catat bahwa jika anda melakukan menggunakan mereka, ORM akan harus pergi dan mendapatkan mereka dalam permintaan terpisah, membuat ini pesimis jika anda menggunakan itu secara tidak benar.
Don't be too aggressive in deferring fields without profiling as the database\nhas to read most of the non-text, non-VARCHAR data from the disk for a single\nrow in the results, even if it ends up only using a few columns. The\ndefer() and only() methods are most useful when you can avoid loading a\nlot of text data or for fields that might take a lot of processing to convert\nback to Python. As always, profile first, then optimize.
QuerySet.contains(obj)Link to this heading#...if you only want to find out if obj is in the queryset, rather than\nif obj in queryset.
QuerySet.count()Link to this heading#..jika anda hanya ingin menghitung, daripada melakukan len(queryset).
QuerySet.exists()Link to this heading#...jika anda hanya ingin menemukan jika setidaknya satu hasil ada, daripada if queryset.
Tetapi:
\ncontains(), count(), and exists()Link to this heading#Jika anda butuh data lain dari QuerySet, nilai itu segera.
\nFor example, assuming a Group model that has a many-to-many relation to\nUser, the following code is optimal:
members = group.members.all()\n\nif display_group_members:\n if members:\n if current_user in members:\n print("You and", len(members) - 1, "other users are members of this group.")\n else:\n print("There are", len(members), "members in this group.")\n\n for member in members:\n print(member.username)\n else:\n print("There are no members in this group.")\nDIa optimal karena:
\nSince QuerySets are lazy, this does no database queries if\ndisplay_group_members is False.
Storing group.members.all() in the members variable allows its\nresult cache to be re-used.
The line if members: causes QuerySet.__bool__() to be called, which\ncauses the group.members.all() query to be run on the database. If there\naren't any results, it will return False, otherwise True.
The line if current_user in members: checks if the user is in the result\ncache, so no additional database queries are issued.
The use of len(members) calls QuerySet.__len__(), reusing the result\ncache, so again, no database queries are issued.
The for member loop iterates over the result cache.
In total, this code does either one or zero database queries. The only\ndeliberate optimization performed is using the members variable. Using\nQuerySet.exists() for the if, QuerySet.contains() for the in,\nor QuerySet.count() for the count would each cause additional queries.
QuerySet.update() dan delete()Link to this heading#Daripada mengambil memuat obyek, setel beberapa nilai, dan simpan mereka masing-masing, gunakan pernyataan SQL UPDATE dalam jumlah besar, melalui QuerySet.update() 1. Demikian pula, lakukan bulk deletes 2 dimana memungkinkan.
\nCatat, bagaimanapun, metode pembaharuan jumlah besar ini tidak dapat memanggil metode save() atau delete() dari masing-masing instance, yang berarti bahwa perilaku penyesuaian apapun anda telah tambahkan untuk metode-metode ini tidak akan dijalankan, termasuk apapun didorong dari obyek basisdata biasa signals 1.
Jika anda hanya butuh nilai foreign key, gunakan nilai foreign key yang sudah pada obyek anda telah dapatkan, daripada mendapatkan keseluruhan obyek terkait dan mengambil primary key nya, yaitu. lakukan:
\nentry.blog_id\ndari pada:
\nentry.blog.id\nPengurutan tidak bebas; setiap bidang yang diurutkan adalah sebuah operai basisdata harus dilakukan. Jika sebuah model awal mengurutkan (Meta.ordering) dan anda tidak membutuhkannya, pindahkan dia pada QuerySet dengan memanggil order_by() dengan tidak ada parameter.
Menambahkan indeks ke basisdata anda mungkin membantu meningkatkan penampilan pengurutan.
\nUse bulk methods to reduce the number of SQL statements.
\nKetika membuat obyek-obyek, dimana memungkinkan, gunakan metode bulk_create() untuk mengurangi sejumlah permintaan SQL. Sebagai contoh:
Entry.objects.bulk_create([\n Entry(headline='This is a test'),\n Entry(headline='This is only a test'),\n])\n...adalah lebih baik untuk:
\nEntry.objects.create(headline='This is a test')\nEntry.objects.create(headline='This is only a test')\nCatat bahwa ada angka dari caveats to this method, jadi pastikan dia sesuai untuk kasus digunakan anda.
When updating objects, where possible, use the\nbulk_update() method to reduce the\nnumber of SQL queries. Given a list or queryset of objects:
entries = Entry.objects.bulk_create([\n Entry(headline='This is a test'),\n Entry(headline='This is only a test'),\n])\nContoh berikut:
\nentries[0].headline = 'This is not a test'\nentries[1].headline = 'This is no longer a test'\nEntry.objects.bulk_update(entries, ['headline'])\n...adalah lebih baik untuk:
\nentries[0].headline = 'This is not a test'\nentries[0].save()\nentries[1].headline = 'This is no longer a test'\nentries[1].save()\nNote that there are a number of caveats to this method, so make sure it's appropriate\nfor your use case.
When inserting objects into ManyToManyFields, use\nadd() with multiple\nobjects to reduce the number of SQL queries. For example:
my_band.members.add(me, my_friend)\n...adalah lebih baik untuk:
\nmy_band.members.add(me)\nmy_band.members.add(my_friend)\n...dimana Bands dan Artists mempunyai hubungan many-to-many.
When inserting different pairs of objects into\nManyToManyField or when the custom\nthrough table is defined, use\nbulk_create() method to reduce the\nnumber of SQL queries. For example:
PizzaToppingRelationship = Pizza.toppings.through\nPizzaToppingRelationship.objects.bulk_create([\n PizzaToppingRelationship(pizza=my_pizza, topping=pepperoni),\n PizzaToppingRelationship(pizza=your_pizza, topping=pepperoni),\n PizzaToppingRelationship(pizza=your_pizza, topping=mushroom),\n], ignore_conflicts=True)\n...adalah lebih baik untuk:
\nmy_pizza.toppings.add(pepperoni)\nyour_pizza.toppings.add(pepperoni, mushroom)\n...where Pizza and Topping have a many-to-many relationship. Note that\nthere are a number of caveats to this method, so make sure it's appropriate\nfor your use case.
When removing objects from ManyToManyFields, use\nremove() with multiple\nobjects to reduce the number of SQL queries. For example:
my_band.members.remove(me, my_friend)\n...adalah lebih baik untuk:
\nmy_band.members.remove(me)\nmy_band.members.remove(my_friend)\n...dimana Bands dan Artists mempunyai hubungan many-to-many.
When removing different pairs of objects from ManyToManyFields, use\ndelete() on a\nQ expression with multiple\nthrough model instances to reduce\nthe number of SQL queries. For example:
from django.db.models import Q\nPizzaToppingRelationship = Pizza.toppings.through\nPizzaToppingRelationship.objects.filter(\n Q(pizza=my_pizza, topping=pepperoni) |\n Q(pizza=your_pizza, topping=pepperoni) |\n Q(pizza=your_pizza, topping=mushroom)\n).delete()\n...adalah lebih baik untuk:
\nmy_pizza.toppings.remove(pepperoni)\nyour_pizza.toppings.remove(pepperoni, mushroom)\n...where Pizza and Topping have a many-to-many relationship.