前言

由于數(shù)據(jù)庫每天都用來存儲越來越多的信息，因此這些也是每個Django項(xiàng)目中的關(guān)鍵組件。 因此了解它們的工作方式非常重要。

當(dāng)然，我無法解釋所有可用于Django的不同數(shù)據(jù)庫的全部細(xì)節(jié)。 不僅如此，因?yàn)槲也恢肋@一切，但也因?yàn)檫@會造成一場談話。 或者可能是整個會議。

關(guān)于數(shù)據(jù)庫的理論背景我唯一想說的是，有一種叫做“關(guān)系代數(shù)”的東西。 用你可能想出的每 一條SELECT語句都可以表達(dá)出來。 數(shù)學(xué)證明。

數(shù)據(jù)庫查找如何工作

相反，讓我們從數(shù)據(jù)庫查找的工作方式開始。 因?yàn)槟鞘俏覀冏疃嗟臅r間。

假設(shè)我們有這個數(shù)據(jù)庫的人名表及其相應(yīng)的年齡，當(dāng)他們開始編程時。

現(xiàn)在我們要選擇每個19歲開始的人。

我們可以用SQL查詢來表達(dá)：

SELECT * FROM people WHERE age = 19

現(xiàn)在，我們?nèi)绾握业矫總€人匹配該查詢？

表掃描查找

那么，這很容易。 我們只查看表中的每一行，檢查條件是否適用，如果是，則返回該行。

這被稱為“全表掃描”

到現(xiàn)在為止還挺好。 我們在這里有7排。 因此我們看7行。 這是少量的行，所以查詢速度很快。

但是想象一下，你有10萬，1億，100億甚至更多的行。 遍歷每一行可能非常耗時。 這不是我們想要的或我們可以負(fù)擔(dān)得起的東西。 我們希望能夠提供有保證的時機(jī)來查找特定行。 與行數(shù)無關(guān)。

這是索引加入派對的地方。

什么是索引？

對于數(shù)量不斷增加的數(shù)據(jù)，索引可以快速訪問單個（或多個）項(xiàng)目，而不會減少很多速度。 這也被稱為“隨機(jī)訪問”。 你會看到為什么這樣叫。 但首先讓我們看看現(xiàn)代數(shù)據(jù)庫系統(tǒng)中最常見的索引類型。

B-Trees / B +樹

目前最常見的索引是B-Tree索引。 或者更確切地說，B +樹索引。

它們或者以其發(fā)明者之一Rudolf Bayer命名，或者因?yàn)樗麄冏晕移胶狻?這不是很清楚，但也并不重要。 自我平衡意味著樹木有一定的時間保證：對于B樹最有意思的是，索引的大小并不重要，對于任何相同大小的索引，時間將是相同的。 你也會看到這一點(diǎn)。

就像所有的樹（無論是在計(jì)算機(jī)科學(xué)還是在自然界中），你都以一個根開始。 計(jì)算機(jī)科學(xué)與自然的區(qū)別在于，在計(jì)算機(jī)科學(xué)中，我們把樹的根部放在頂部。

隨你。 這是3級B +樹的根音。

等級3意味著，這個節(jié)點(diǎn)可以有3個鍵。 這就是該節(jié)點(diǎn)頂部的3個盒子的用途。 下面的4個盒子保存指向另一個節(jié)點(diǎn)的指針或數(shù)據(jù)庫表中的一行。

現(xiàn)在，假設(shè)您在此節(jié)點(diǎn)中具有密鑰11和37，并且您沒有第三個密鑰。

然后最左邊的指針指向一個節(jié)點(diǎn)的鍵小于11.第二個指針指向一個節(jié)點(diǎn)，其鍵大于或等于11，小于37.第三個指針指向一個鍵大于或等于37的節(jié)點(diǎn)。

從我在開始時顯示的表格的年齡欄索引中，可以看起來像這樣。

現(xiàn)在的魔法就是第二行節(jié)點(diǎn)中的指針。 它們中的每一個指向表中具有特定鍵的單個行，在我們的示例中，這是年齡。

但不只是這個。

您會看到每個底層節(jié)點(diǎn)中的最后一個指針如何指向下一個節(jié)點(diǎn)？ 這用于“索引掃描”。 我會在稍后回來。

我們來更詳細(xì)地看看第二排節(jié)點(diǎn)。

您現(xiàn)在可以看到，來自其中一個樹節(jié)點(diǎn)的每個指針如何指向表中的單個行。

您還可以看到來自樹節(jié)點(diǎn)的這些指針如何隨機(jī)地指向表中的某些行。 這就是為什么這被稱為“隨機(jī)訪問”。 數(shù)據(jù)庫隨機(jī)在數(shù)據(jù)庫表中跳轉(zhuǎn)。

隨機(jī)訪問查找

讓我們用我們之前的SQL查詢刷新我們的記憶。

SELECT * FROM people WHERE age = 19

現(xiàn)在索引如何幫助更快找到相應(yīng)的行？

那么，讓我們看看樹：

它需要1步從第一個節(jié)點(diǎn)到第二個節(jié)點(diǎn)。 并且從第二個節(jié)點(diǎn)到數(shù)據(jù)庫表中的行一秒鐘。

請記住，我們必須查看所有7行以查看它們是否與數(shù)據(jù)庫查詢匹配。

而且由于19個指數(shù)中沒有更多的關(guān)鍵，我們就完成了。

索引掃描

現(xiàn)在，回到“索引掃描”，假設(shè)你想要計(jì)算從5歲到13歲時開始編碼的人數(shù)。

SELECT COUNT(*) FROM people WHERE age BETWEEN 5 AND 19;
SELECT COUNT(*) FROM people WHERE age >= 5 AND age <= 19;

數(shù)據(jù)庫將查找密鑰5，然后使用指向下一個節(jié)點(diǎn)的指針查找更多密鑰。

而且因?yàn)閿?shù)據(jù)庫所需的所有查詢信息都在索引中，所以數(shù)據(jù)庫根本不會查看表。

索引非常棒

讓我們讓他們在Django。

實(shí)際上，我們已經(jīng)做到了。

有

• db_index = True ，您可以在模型字段上設(shè)置
• index_together =（（'name'， 'age'），）你可以在模型的Meta類中設(shè)置
• ForeignKey（） / OneToOneField（）使用索引快速查找相關(guān)表中的數(shù)據(jù)
• primary_key = True ，Django自動使用AutoField表示每個模型上的id列。

這已經(jīng)很棒了。 但是這個功能集有點(diǎn)限制。 那里不僅有B +樹索引。 還有一噸多

2016

我們來看看2016年。

馬克·坦林和我有索引的想法。 實(shí)際上，Marc在他的contrib.postgres工作中已經(jīng)有了一些想法。 我們有關(guān)于API的想法。 我們希望在Django中擁有的東西。 像，讓我們讓Django支持所有的索引 。

但是我們沒有時間去實(shí)現(xiàn)我們的想法！

但我們很幸運(yùn)。 事實(shí)上，Django項(xiàng)目很幸運(yùn)。

Google Summer of Code 2016

Django再次被接受為Google Summer of Code的組織。 謝謝Google！

對于那些不知道這是什么的人：谷歌支付學(xué)生3個月的時間在開源項(xiàng)目上工作，同時由項(xiàng)目貢獻(xiàn)者進(jìn)行指導(dǎo)。

大多數(shù)情況下， Tim Graham ，還有Marc和我輔導(dǎo)學(xué)生Akshesh Doshi在Django中處理更通用的索引支持。 從寫下API等提議，直到最終合并到Django中。

GSoC 2016的主要成果是django.db.models.indexes.Index（fields，name） （ docs ）

它定義了所有索引的基類。 您可以通過模型的Meta類中的索引選項(xiàng)使用它們。

例如像這樣：

from django.db import models

class Person(models.Model):
 name = models.CharField(max_length=200)

 class Meta:
  indexes = [
   models.Index(
    fields=['name'],
    name='name_idx',
   ),
  ]

這將在數(shù)​​據(jù)庫表的名稱列上創(chuàng)建一個B +樹索引。

當(dāng)然，這并不是什么新鮮事。 這就是在名稱字段中使用db_index = True時可以執(zhí)行的操作。

您當(dāng)然也可以在多列上定義索引：

from django.db import models

class Person(models.Model):
 name = models.CharField(max_length=200)
 age = models.PositiveSmallIntegerField()

 class Meta:
  indexes = [
   models.Index(
    fields=['name', 'age'],
    name='name_age_idx',
   ),
  ]

當(dāng)然，這也不是什么新東西。 你可以用index_together來完成。

但你現(xiàn)在也可以這樣做：

from django.contrib.postgres.fields import JSONField
from django.contrib.postgres.indexes import GinIndex
from django.db import models

class Doc(models.Model):
 data = JSONField()

 class Meta:
  indexes = [
   GinIndex(
    fields=['data'],
    name='data_gin',
   ),
  ]

定義一個GinIndex 。 這是PostgreSQL特有的。 但這是你以前無法做到的事情。 至少不可靠，沒有太多的痛苦。

GinIndex可用于索引JSON blob中的鍵值。 因此，您可以篩選表中JSONB字段中的鍵映射到特定值的表中的行。 這就像“NoSQL 1-0-1”。

Django 1.11附帶的另一種內(nèi)置索引類型是BrinIndex ，簡單地說，它可以允許更快地計(jì)算聚合。 比如，找出每篇文章最后一次購買的時間。

而且由于索引是數(shù)據(jù)庫模式的一部分，顯然通過遷移來追蹤索引。 因此，當(dāng)您運(yùn)行python manage.py migrate時會創(chuàng)建索引：

BEGIN;
--
-- Create model Doc
--
CREATE TABLE "someapp_doc" (
 "id" serial NOT NULL PRIMARY KEY,
 "data" jsonb NOT NULL);
--
-- Create index data_gin on field(s) data of model doc
--
CREATE INDEX "data_gin" ON "someapp_doc" USING gin ("data");
COMMIT;

特色創(chuàng)意

大。

這就是昨天發(fā)布的Django 1.11。

但是Django 2.0有什么用？

什么在地平線上？

我們最終想要什么？

功能索引

它們在各種情況下都很有用，在這種情況下，您不希望對原始值進(jìn)行索引，但可以對其進(jìn)行變化，例如字符串的小寫。 我已經(jīng)在為此工作。 我還沒到。 我很想從理解表達(dá)式API的人那里獲得幫助。

from django.db import models

class Author(models.Model):
 name = models.CharField(max_length=200)

 class Meta:
  indexes = [
   FuncIndex(
    expression=Lower('name'),
    name='name_lower_idx',
   ),
  ]

db_index = <IndexClass>

如前所述，對單個列使用索引可能非常麻煩。 因此，讓我們支持Index類作為db_index的一個屬性。

from django.db import models

class Author(models.Model):
 name = models.CharField(
  max_length=200,
  db_index=HashIndex
 )

對某些領(lǐng)域有一個B +樹是沒有意義的。 如前所示， GinIndex對于JSONField來說非常完美。 為什么不在db_index = True時使用每個字段類的default_index_class ？

from django.contrib.postgres.fields import JSONField
from django.contrib.postgres.indexes import GinIndex
from django.db import models

# Somewhere in Django's JSONField implementation:
# JSONField.default_index_class = GinIndex

class Document(models.Model):
 data = JSONField(db_index=True)

重構(gòu)index_together和db_index

這個比面向用戶更引人注目：

我可以想象， db_index和index_together在內(nèi)部使用Model._meta.indexes可能是有意義的。 這是要調(diào)查的東西。

GiSTIndex

PostgreSQL中有一個GiSTIndex ，可用于地理空間查詢，例如“給我所有與給定點(diǎn)最大距離為10的點(diǎn)”。 這不是在Django 1.11中。 我不知道為什么，但我猜是因?yàn)闆]有人添加它。

請注意，Django 2.0不再支持Python 2了！

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論