該框架在管理數(shù)據(jù)庫(kù)更改方面非常強(qiáng)大和有用，但是該框架提供的靈活性受到了一定的限制。為了理解Django遷移的局限性，你將處理一個(gè)眾所周知的問(wèn)題：在不停機(jī)的情況下，在Django中創(chuàng)建一個(gè)索引。

在本教程中，你將學(xué)習(xí)：

Django如何以及何時(shí)生成新的遷移；

如何檢查Django生成的執(zhí)行遷移的命令；

如何安全地修改遷移以滿足你的需求。

本中級(jí)教程是為已經(jīng)熟悉Django遷移(Migration)的讀者設(shè)計(jì)的。

在Django遷移中創(chuàng)建索引的問(wèn)題

當(dāng)應(yīng)用程序存儲(chǔ)的數(shù)據(jù)增長(zhǎng)時(shí)，通常需要進(jìn)行的一個(gè)常見(jiàn)更改就是添加索引。索引可以用來(lái)加快查詢速度，并使你的應(yīng)用程序運(yùn)行和響應(yīng)更快。

在大多數(shù)數(shù)據(jù)庫(kù)中，添加索引時(shí)需要對(duì)表使用獨(dú)占鎖。在創(chuàng)建索引時(shí)，獨(dú)占鎖會(huì)防止數(shù)據(jù)修改(DML)操作，如UPDATE，INSERT，和DELETE。

數(shù)據(jù)庫(kù)在執(zhí)行某些操作時(shí)會(huì)隱式地獲取鎖。例如，當(dāng)用一個(gè)戶登錄到你的應(yīng)用程序時(shí)，Django將更新auth_user表中的last_login字段。要執(zhí)行更新，數(shù)據(jù)庫(kù)首先必須在這個(gè)行上獲得一個(gè)鎖。如果該行當(dāng)前被另一個(gè)連接鎖定，那么你會(huì)得到一個(gè)數(shù)據(jù)庫(kù)異常。

當(dāng)需要在遷移期間保持系統(tǒng)可用時(shí)，鎖定表可能會(huì)造成問(wèn)題。表越大，創(chuàng)建索引所需的時(shí)間就越長(zhǎng)。創(chuàng)建索引所需的時(shí)間越長(zhǎng)，系統(tǒng)不可用或?qū)τ脩魺o(wú)響應(yīng)的時(shí)間就越長(zhǎng)。

一些數(shù)據(jù)庫(kù)供應(yīng)商提供了一種創(chuàng)建索引而不鎖定表的方法。例如，要在PostgreSQL中創(chuàng)建索引而不鎖定表，你可以使用CONCURRENTLY關(guān)鍵字：

在Oracle中，有一個(gè)ONLINE選項(xiàng)允許在創(chuàng)建索引時(shí)對(duì)表執(zhí)行DML操作：

在生成遷移時(shí)，Django不會(huì)使用這些特殊的關(guān)鍵字。按原樣運(yùn)行遷移將使數(shù)據(jù)庫(kù)獲得表上的獨(dú)占鎖，并在創(chuàng)建索引時(shí)防止DML操作。

并發(fā)創(chuàng)建索引有一些注意事項(xiàng)。提前了解特定于數(shù)據(jù)庫(kù)后端的問(wèn)題是很重要的。例如，PostgreSQL中的一個(gè)警告是并發(fā)創(chuàng)建索引需要更長(zhǎng)的時(shí)間，因?yàn)樗枰M(jìn)行額外的表掃描。

在本教程中，你將使用Django遷移在一個(gè)大型表上創(chuàng)建索引，而不會(huì)導(dǎo)致任何停機(jī)。

注意：要學(xué)習(xí)本教程，建議你使用PostgreSQL后端，Django2.x和python3。

也可以使用其他數(shù)據(jù)庫(kù)后端。在使用PostgreSQL特有的SQL特性的地方，更改SQL以匹配你的數(shù)據(jù)庫(kù)后端。

設(shè)置

你將在一個(gè)名為app的應(yīng)用中使用一個(gè)虛構(gòu)的Sale模型。在現(xiàn)實(shí)生活中，Sale等模型是數(shù)據(jù)庫(kù)中的主要表，它們通常會(huì)非常大，并存儲(chǔ)大量數(shù)據(jù)：

創(chuàng)建表，生成初始遷移并應(yīng)用它：

一段時(shí)間之后，sales表變得非常大，用戶開(kāi)始抱怨速度太慢。在監(jiān)視數(shù)據(jù)庫(kù)時(shí)，你注意到許多查詢使用sold_at列。為了加快速度，你決定在列上需要一個(gè)索引。

要在sold_at上添加索引，你需要對(duì)模型進(jìn)行以下更改：

如果按原樣運(yùn)行這個(gè)遷移，那么Django將在表上創(chuàng)建索引，并且它將被鎖定，直到索引完成。在非常大的表上創(chuàng)建索引可能需要一段時(shí)間，你希望避免停機(jī)。

在具有小數(shù)據(jù)集和很少連接的本地開(kāi)發(fā)環(huán)境中，這種遷移可能是瞬間完成的。然而，對(duì)于具有許多并發(fā)連接的大型數(shù)據(jù)集，獲取鎖并創(chuàng)建索引可能需要一段時(shí)間。

在接下來(lái)的步驟中，你將修改Django創(chuàng)建的遷移，以便在不引起任何停機(jī)的情況下創(chuàng)建索引。

偽造遷移

第一種方法是手動(dòng)創(chuàng)建索引。你將生成遷移，但實(shí)際上并不會(huì)讓Django應(yīng)用它。相反，你將在數(shù)據(jù)庫(kù)中手動(dòng)運(yùn)行SQL，然后讓Django認(rèn)為遷移已經(jīng)完成。

首先，生成遷移：

使用sqlmigrate命令來(lái)查看Django將用于執(zhí)行此遷移的SQL：

你希望在不鎖定表的情況下創(chuàng)建索引，因此你需要修改命令。添加CONCURRENTLY關(guān)鍵字并在數(shù)據(jù)庫(kù)中執(zhí)行：

注意，你在執(zhí)行命令的過(guò)程中沒(méi)有BEGIN和COMMIT部分。省略這些關(guān)鍵字會(huì)在沒(méi)有數(shù)據(jù)庫(kù)事務(wù)的情況下執(zhí)行命令。我們將在本文后面討論數(shù)據(jù)庫(kù)事務(wù)。

執(zhí)行命令后，如果你嘗試應(yīng)用遷移，會(huì)出現(xiàn)以下錯(cuò)誤：

Django會(huì)提示你該索引已經(jīng)存在，因此無(wú)法繼續(xù)遷移。你剛剛在數(shù)據(jù)庫(kù)中直接創(chuàng)建了索引，所以現(xiàn)在需要讓Django認(rèn)為已經(jīng)應(yīng)用了遷移。

如何偽造一個(gè)遷移

Django提供了一種內(nèi)置的方法，可以將遷移標(biāo)記為已執(zhí)行，而不需要實(shí)際執(zhí)行它們。要使用這個(gè)選項(xiàng)，你需要在應(yīng)用遷移時(shí)設(shè)置—fake標(biāo)志：

這一次Django沒(méi)有拋出錯(cuò)誤。實(shí)際上，Django并沒(méi)有真正應(yīng)用任何遷移。它只是將其標(biāo)記為已執(zhí)行(或FAKED)。

以下是在偽造遷移時(shí)需要考慮的一些問(wèn)題：

手動(dòng)命令必須與Django生成的SQL等價(jià): 你需要確保所執(zhí)行的命令與Django生成的SQL等價(jià)。使用sqlmigrate來(lái)生成SQL命令。如果命令不匹配，則可能導(dǎo)致數(shù)據(jù)庫(kù)和模型狀態(tài)之間的不一致。

其他未應(yīng)用的遷移也將被偽造：當(dāng)你有多個(gè)未應(yīng)用的遷移時(shí)，它們都將被偽造。在應(yīng)用遷移之前，重要的是確保只有你想要偽造的遷移沒(méi)有應(yīng)用。否則，你可能會(huì)得到不一致的結(jié)果。另一個(gè)選項(xiàng)是指定要偽造的確切遷移。

需要直接訪問(wèn)數(shù)據(jù)庫(kù)：你需要在數(shù)據(jù)庫(kù)中運(yùn)行SQL命令，這有時(shí)也不是必需的。此外，在生產(chǎn)數(shù)據(jù)庫(kù)中直接執(zhí)行命令是危險(xiǎn)的，應(yīng)該盡可能避免。

自動(dòng)化部署流程可能需要調(diào)整:如果你自動(dòng)化了部署流程(使用CI、CD或其他自動(dòng)化工具)，那么你可能需要將流程更改為偽遷移。這并不總是可取的。

清理

在繼續(xù)下一節(jié)之前，你需要將數(shù)據(jù)庫(kù)恢復(fù)到它在初始遷移之后的狀態(tài)。要做到這一點(diǎn)，請(qǐng)遷移回初始遷移：

Django沒(méi)有應(yīng)用在第二次遷移中所做的更改，所以現(xiàn)在可以安全地刪除文件：

為了確保你做的一切都是正確的，檢查一下遷移：

應(yīng)用了初始遷移之后，就沒(méi)有未應(yīng)用的遷移了。

在遷移（Migration）中執(zhí)行原始SQL

在上一節(jié)中，你直接在數(shù)據(jù)庫(kù)中執(zhí)行SQL并偽造遷移。這樣就完成了任務(wù)，但是還有一個(gè)更好的解決方案。

Django提供了一種使用RunSQL在遷移中執(zhí)行原始SQL的方法。我們來(lái)嘗試使用它代替直接在數(shù)據(jù)庫(kù)中執(zhí)行命令。

首先，生成一個(gè)新的空遷移：

接下來(lái)，編輯遷移文件并添加RunSQL操作：

當(dāng)你運(yùn)行遷移時(shí)，你將獲得以下輸出：

這看起來(lái)不錯(cuò)，但有一個(gè)問(wèn)題。我們?cè)俅蝸?lái)嘗試生成遷移：

Django再次生成了相同的遷移。為什么會(huì)這樣？

清理

在回答這個(gè)問(wèn)題之前，你需要清理并撤消對(duì)數(shù)據(jù)庫(kù)所做的更改。首先刪除最后一次遷移。它沒(méi)有被應(yīng)用，所以可以安全刪除：

接下來(lái)，列出app應(yīng)用程序的遷移：

第三次遷移已經(jīng)結(jié)束，但是只應(yīng)用了第二次遷移。你希望回到初始遷移之后的狀態(tài)。試著像你在上一節(jié)所做的那樣遷移回初始遷移狀態(tài)：

Django無(wú)法進(jìn)行逆向遷移。

逆向遷移操作

要進(jìn)行一次逆向遷移，Django會(huì)對(duì)每個(gè)操作執(zhí)行相反的操作。在本例中，添加索引的反面是刪除索引。正如你已經(jīng)看到的，當(dāng)一個(gè)遷移是可逆的時(shí)，你可以取消應(yīng)用它。就像你可以在Git中使用checkout一樣，如果你對(duì)較早的遷移執(zhí)行了migrate命令，你可以進(jìn)行逆向遷移。

許多內(nèi)置遷移操作已經(jīng)定義了反向操作。例如，添加字段的反向操作是刪除對(duì)應(yīng)的列，創(chuàng)建模型的反向操作是刪除相應(yīng)的表。

有些遷移操作是不可逆的。例如，刪除字段或刪除模型沒(méi)有反向操作，因?yàn)橐坏?yīng)用了遷移，數(shù)據(jù)就會(huì)消失。

在上一節(jié)中，你使用了RunSQL操作。當(dāng)你試圖進(jìn)行反向遷移時(shí)，遇到了一個(gè)錯(cuò)誤。根據(jù)錯(cuò)誤提示，遷移中的一個(gè)操作不能逆轉(zhuǎn)。Django默認(rèn)情況下無(wú)法反轉(zhuǎn)原始SQL。因?yàn)镈jango不知道該操作執(zhí)行了什么，所以它不能自動(dòng)生成相反的操作。

如何使遷移可逆

要使一個(gè)遷移是可逆的，遷移中的所有操作都必須是可逆的。只逆轉(zhuǎn)遷移的一部分是不可能的，因此一個(gè)單一的不可逆操作將使整個(gè)遷移不可逆。

要使RunSQL操作可逆，你必須提供在操作反轉(zhuǎn)時(shí)執(zhí)行的SQL。反向SQL在reverse_sql參數(shù)中提供。

添加索引的相反操作是刪除索引。要使你的遷移可逆，請(qǐng)?zhí)峁﹔everse_sql參數(shù)來(lái)刪除索引：

現(xiàn)在試著反轉(zhuǎn)遷移：

我們對(duì)第二次遷移進(jìn)行了反轉(zhuǎn)，Django刪除了索引。現(xiàn)在可以安全地刪除遷移文件了：

提供reverse_sql總是一個(gè)好主意。在反轉(zhuǎn)原始SQL操作而不需要其他任何操作的情況下，你可以使用特殊的哨兵語(yǔ)句migrations.

RunSQL.noop將該操作標(biāo)記為可逆操作。

理解模型狀態(tài)和數(shù)據(jù)庫(kù)狀態(tài)

在你之前嘗試使用RunSQL手動(dòng)創(chuàng)建索引時(shí)，Django一次又一次地生成了相同的遷移，盡管索引是在數(shù)據(jù)庫(kù)中創(chuàng)建的。要理解Django為什么這樣做，你首先需要理解Django如何決定何時(shí)生成新的遷移。

當(dāng)Django生成一個(gè)新的遷移時(shí)

在生成和應(yīng)用遷移的過(guò)程中，Django同步數(shù)據(jù)庫(kù)狀態(tài)和模型狀態(tài)。例如，當(dāng)你向模型添加字段時(shí)，Django會(huì)向表添加一列。當(dāng)你從模型中刪除字段時(shí)，Django將從表中刪除列。

為了在模型和數(shù)據(jù)庫(kù)之間同步，Django擁有一個(gè)表示模型的狀態(tài)。為了使數(shù)據(jù)庫(kù)與模型同步，Django會(huì)生成遷移操作。遷移操作轉(zhuǎn)換為可以在數(shù)據(jù)庫(kù)中執(zhí)行的特定供應(yīng)商的SQL。當(dāng)所有遷移操作都執(zhí)行后，數(shù)據(jù)庫(kù)和模型應(yīng)該是一致的。

為了獲得數(shù)據(jù)庫(kù)的狀態(tài)，Django聚合了所有過(guò)去遷移的操作。當(dāng)遷移的聚合狀態(tài)與模型的狀態(tài)不一致時(shí)，Django會(huì)生成一個(gè)新的遷移。

在前面的例子中，你使用原始SQL創(chuàng)建了索引。Django不知道你創(chuàng)建了索引，因?yàn)槟銢](méi)有使用熟悉的遷移操作。

當(dāng)Django聚合所有遷移并將它們與模型的狀態(tài)進(jìn)行比較時(shí)，它發(fā)現(xiàn)缺少一個(gè)索引。這就是為什么即使你手動(dòng)創(chuàng)建了索引，Django仍然認(rèn)為它是缺失的，并為它生成了一個(gè)新的遷移。

如何在遷移中分離數(shù)據(jù)庫(kù)和狀態(tài)

由于Django無(wú)法按照你希望的方式創(chuàng)建索引，所以你希望提供自己的SQL，但仍然要讓Django知道你已經(jīng)創(chuàng)建了索引。

換句話說(shuō)，你需要在數(shù)據(jù)庫(kù)中執(zhí)行一些操作，并為Django提供遷移操作來(lái)同步其內(nèi)部狀態(tài)。為此，Django為我們提供了一個(gè)名為 SeparateDatabaseAndState的特殊遷移操作。這項(xiàng)操作并不為人所知，應(yīng)該留到像這種特殊情況下使用。

編輯遷移要比從頭開(kāi)始寫(xiě)容易的多，因此，首先以通常的方式生成一個(gè)遷移：

這是Django生成的遷移內(nèi)容，和之前一樣：

Django在字段sold_at上生成了一個(gè)AlterField操作。該操作會(huì)創(chuàng)建一個(gè)索引并更新?tīng)顟B(tài)。我們希望保留這個(gè)操作，但是在數(shù)據(jù)庫(kù)中提供一個(gè)不同的命令來(lái)執(zhí)行。

同樣，要獲得該命令，請(qǐng)使用Django生成的SQL：

在合適的地方添加CONCURRENTKY關(guān)鍵字：

接著，編輯該遷移文件，并使用SeparateDatabaseAndState來(lái)提供你修改過(guò)的SQL命令并執(zhí)行：

遷移操作separate atabaseandstate接受2個(gè)操作列表：

1.state_operations是應(yīng)用于內(nèi)部模型狀態(tài)的操作。它們不會(huì)影響數(shù)據(jù)庫(kù)。

2.database_operations是應(yīng)用于數(shù)據(jù)庫(kù)的操作。

你在state_operations中保留了Django生成的原始操作。當(dāng)使用SeparateDatabaseAndState時(shí)，這是你通常想要做的，注意向字段提供db_index=True參數(shù)。這個(gè)遷移操作將讓Django知道字段上有一個(gè)索引。

你使用了Django生成的SQL并添加了CONCURRENTLY關(guān)鍵字。你使用特殊的操作RunSQL來(lái)在遷移中執(zhí)行原始SQL。

如果你試圖運(yùn)行此遷移，你將獲得以下輸出：

非原子遷移

在SQL中，CREATE、DROP、ALTER和TRUNCATE操作稱為數(shù)據(jù)定義語(yǔ)言(Data Definition Language, DDL)。在支持事務(wù)性DDL的數(shù)據(jù)庫(kù)中，比如PostgreSQL，Django默認(rèn)會(huì)在數(shù)據(jù)庫(kù)事務(wù)中執(zhí)行遷移。然而，根據(jù)上面的錯(cuò)誤，PostgreSQL不能在事務(wù)塊中并發(fā)地創(chuàng)建索引。

為了能夠在遷移中并發(fā)地創(chuàng)建索引，你需要告訴Django不要在數(shù)據(jù)庫(kù)事務(wù)中執(zhí)行遷移。為此，通過(guò)將atomic設(shè)置為False，將遷移標(biāo)記為非原子（non-atomic）:

將遷移標(biāo)記為非原子之后，你可以運(yùn)行遷移了：

你只是執(zhí)行了遷移，并沒(méi)有引起任何停機(jī)。

下面是使用SeparateDatabaseAndState時(shí)需要考慮的一些問(wèn)題

數(shù)據(jù)庫(kù)操作必須與狀態(tài)操作等價(jià)：數(shù)據(jù)庫(kù)和模型狀態(tài)之間的不一致可能會(huì)造成很多麻煩。一個(gè)好的開(kāi)始是保留Django在 state_operations中生成的操作和編輯sqlmigrate的輸出并在database_operations中使用。

非原子遷移在發(fā)生錯(cuò)誤時(shí)不能回滾：如果在遷移過(guò)程中出現(xiàn)錯(cuò)誤，則無(wú)法回滾。你必須要么回滾遷移，要么手動(dòng)完成它。將在非原子遷移中執(zhí)行的操作保持在最少是一個(gè)好主意。如果你在遷移中有其他操作，請(qǐng)將它們移到新的遷移中。

遷移可能是特定于供應(yīng)商的：Django生成的SQL特定于項(xiàng)目中使用的數(shù)據(jù)庫(kù)后端。它可能會(huì)在其他數(shù)據(jù)庫(kù)后端運(yùn)行，但這并不能保證。如果你需要支持多個(gè)數(shù)據(jù)庫(kù)后端，則需要對(duì)這種方法進(jìn)行一些調(diào)整。

結(jié)論：

你從一個(gè)大型的數(shù)據(jù)表和一個(gè)問(wèn)題開(kāi)始了本教程。你想讓你的應(yīng)用程序?qū)τ脩魜?lái)說(shuō)更快，你想在不引起應(yīng)用程序任何停機(jī)的情況下做到這一點(diǎn)。

在本教程的最后，你嘗試生成并安全地修改了一個(gè)Django遷移來(lái)實(shí)現(xiàn)這一目標(biāo)。在此過(guò)程中，你遇到了不同的問(wèn)題，并使用migration 框架提供的內(nèi)置工具設(shè)法解決了這些問(wèn)題。

在本教程中，你學(xué)習(xí)了以下內(nèi)容：

• Django遷移在內(nèi)部如何使用模型和數(shù)據(jù)庫(kù)狀態(tài)進(jìn)行工作，以及何時(shí)生成新的遷移；
• 如何使用RunSQL操作在遷移中執(zhí)行自定義的SQL；
• 什么是可逆遷移，以及如何使RunSQL操作可逆；
• 什么是原子遷移，以及如何根據(jù)需要更改默認(rèn)行為；
• 如何安全地在Django中執(zhí)行復(fù)雜的遷移。

模型與數(shù)據(jù)庫(kù)狀態(tài)的分離是一個(gè)重要的概念。一旦你理解了它，以及知道如何使用它，你就可以突破內(nèi)置遷移操作的許多限制。我想到的一些用例包括添加已經(jīng)在數(shù)據(jù)庫(kù)中創(chuàng)建的索引，以及為DDL命令提供特定的服務(wù)商參數(shù)。

到此這篇關(guān)于Django如何在不停機(jī)的情況下創(chuàng)建索引的文章就介紹到這了,更多相關(guān)不停機(jī)狀態(tài)下使用Django創(chuàng)建索引內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！