Django 和 SQL：數(shù)據(jù)庫擴(kuò)展好幫手
有多少人曾為應(yīng)用程序數(shù)據(jù)庫的擴(kuò)展和優(yōu)化而頭疼？如果你還沒有閱讀過《如何用 Django 搞定 SQL 的 “臟活累活”》，強(qiáng)烈建議先看看那篇文章。簡單來說，SQL 是專為 SQL 數(shù)據(jù)庫優(yōu)化的，Python 則不是，而 Django 可以充當(dāng)一個(gè)中介，幫助我們構(gòu)建更有效的應(yīng)用程序，同時(shí)在配合使用這兩種語言時(shí)減少摩擦，降低復(fù)雜性和代碼量。
然而，盡管 Django 承擔(dān)了創(chuàng)建數(shù)據(jù)庫應(yīng)用的重任，我們依然需要承擔(dān)數(shù)據(jù)庫的日常管理和監(jiān)控工作。好在只要使用諸如 Linode Managed Databases 這樣的托管數(shù)據(jù)庫服務(wù)，很多管理任務(wù)都可以委托給云提供商，但我們可能依然會在應(yīng)用擴(kuò)展的過程中遇到新問題，例如：
- 數(shù)據(jù)庫遷移。將現(xiàn)有數(shù)據(jù)庫切換為新的所需狀態(tài)，并以可控的方式更改數(shù)據(jù)庫 Schema。
- 多數(shù)據(jù)庫部署。為了優(yōu)化性能，開發(fā)者可以設(shè)計(jì)應(yīng)用程序中的不同功能使用獨(dú)立的數(shù)據(jù)庫。例如，一個(gè)主要的讀 / 寫數(shù)據(jù)庫和一個(gè)為通用查詢提供服務(wù)的可讀副本數(shù)據(jù)庫。
如果其中一個(gè)數(shù)據(jù)庫使用了 SQL，我們可以按照《如何用 Django 搞定 SQL 的 “臟活累活”》一文的介紹，大幅簡化海量數(shù)據(jù)的處理工作。
本文將介紹數(shù)據(jù)庫管理工作中的兩個(gè)重要概念，并通過循序漸進(jìn)的指南告訴大家該如何構(gòu)建面向生產(chǎn)環(huán)境的 Django 應(yīng)用程序。
延伸閱讀，了解Akamai cloud-computing
出海云服務(wù)，選擇Akamai Linode！
數(shù)據(jù)庫遷移
在剛上手時(shí)，為數(shù)據(jù)庫中不同列的內(nèi)容確定適合的數(shù)據(jù)類型，這可能是個(gè)有點(diǎn)棘手的任務(wù)，如果有關(guān)數(shù)據(jù)的需求會隨著時(shí)間推移不可避免產(chǎn)生變化，感覺就更棘手了。如果希望標(biāo)題字段只能包含 80 個(gè)字符該怎么辦？如果需要添加一個(gè)時(shí)間戳字段以便準(zhǔn)確追蹤每個(gè)內(nèi)容是在什么時(shí)候加入數(shù)據(jù)庫的又該怎么辦？
在創(chuàng)建好一個(gè)表之后再更改其內(nèi)容，可能會產(chǎn)生一些非常混亂的后果，原因主要在于：
- 該如何處理已經(jīng)存在的值？
- 如果原有的行缺少新增列 / 字段對應(yīng)的數(shù)據(jù)該怎么辦？
- 如果刪除了某個(gè)列 / 字段該怎么辦？數(shù)據(jù)會發(fā)生什么變化？
- 如果添加了一個(gè)之前不存在的關(guān)系（例如外鍵）又該如何處理？
好在對于 Django 開發(fā)者來說，可以使用 makemigrations 和 migrate。一起看看它們是如何生效的。
以如下的 Django 數(shù)據(jù)模型為例：
class BlogArticle(models.Model):
user = models.ForeignKey(User, default=1, on_delete=models.SET_DEFAULT)
title = models.CharField(max_length=120)
slug = models.SlugField(blank=True, null=True)
content = models.TextField(blank=True, null=True)
publish_timestamp = models.DateTimeField(
auto_now_add=False,
auto_now=False,
blank=True,
null=True,
)先來添加一個(gè)字段：
updated_by = models.ForeignKey(
User, related_name="editor", null=True, blank=True, on_delete=models.SET_NULL
)該字段可供我們追蹤修改了模型的最后一個(gè)用戶。
接著更新一下這個(gè)模型：
class BlogArticle(models.Model):
user = models.ForeignKey(User, default=1, on_delete=models.SET_DEFAULT)
title = models.CharField(max_length=120)
slug = models.SlugField(blank=True, null=True)
content = models.TextField(blank=True, null=True)
publish_timestamp = models.DateTimeField(
auto_now_add=False,
auto_now=False,
blank=True,
null=True,
)
# our new field
updated_by = models.ForeignKey(
User, related_name="editor", null=True, blank=True, on_delete=models.SET_NULL
)當(dāng)我們保存了 BlogArticle 類所聲明的文件（models.py）后，如何讓數(shù)據(jù)庫知道發(fā)生了這個(gè)改動？有兩種方法：
- python manage.py makemigrations
- python manage.py migrate
一起看看這兩個(gè)命令的作用吧。
1.python manage.py makemigrations
python manage.py makemigrations 可以在我們的 Django 項(xiàng)目中尋找對 models.py 文件進(jìn)行的所有改動。如果找到改動，將創(chuàng)建一個(gè)全新的 Python 文件，其中包含 SQL 數(shù)據(jù)庫需要進(jìn)行的提議變更（Proposed change）。這種提議變更看起來類似這樣：
from django.conf import settings
from django.db import migrations, models
import django.db.models.deletion
class Migration(migrations.Migration):
dependencies = [
migrations.swappable_dependency(settings.AUTH_USER_MODEL),
('articles', '0001_initial'),
]
operations = [
migrations.AddField(
model_name='article',
name='updated_by',
field=models.ForeignKey(blank=True, null=True, on_delete=django.db.models.deletion.SET_NULL, related_name='editor', to=settings.AUTH_USER_MODEL),
),
]這當(dāng)然也是另一個(gè) Python 文件。開發(fā)者可以通過該文件了解數(shù)據(jù)庫中應(yīng)該發(fā)生的事情。為了維持一致并利用 Django ORM 的內(nèi)置功能，該文件會使用 Python 編寫（而非 SQL）。
但為什么這個(gè)文件中記錄了應(yīng)該發(fā)生的事情？主要原因在于：
- 如果我們希望在實(shí)際發(fā)生前檢查應(yīng)該發(fā)生的事情，可以直接通過該文件了解。
- Makemigrations 命令并不會通過檢查數(shù)據(jù)庫來判斷這些變化是否可以真正發(fā)生。
- 為了使用這些要求，數(shù)據(jù)庫可能已經(jīng)發(fā)生了改變（取決于誰在管理數(shù)據(jù)庫等一系列因素）。
- 如果希望在更改生產(chǎn)數(shù)據(jù)庫前進(jìn)行測試，那么此時(shí)就是最佳時(shí)機(jī)。
假設(shè)這些變更是有效的（只要我們可以正確判斷），隨后就可以通過下列方法提交這些變更了。
2.python manage.py migrate
python manage.py migrate 將嘗試著為我們更改數(shù)據(jù)庫（所有字段、列、表、外鍵等），Django 會代替我們做這些工作，以確保數(shù)據(jù)庫能按照我們希望的方式更新。
需要注意的是，Django 可能會因?yàn)橐恍┰蚨?/span>無法執(zhí)行這些變更。對于新接觸 Django 的開發(fā)者，最主要的原因往往是添加或刪除了字段 / 列，但未能正確進(jìn)行遷移。
如果操作正確無誤，python manage.py migrate 可以保證產(chǎn)生穩(wěn)定的系統(tǒng)，并且各方面均與我們的 Python 代碼和 SQL 表保持匹配，從而確保可以正確發(fā)揮出 Django 和 SQL 數(shù)據(jù)庫提供的強(qiáng)大功能。
這種做法如何為我們帶來更高靈活性？
Python 有著廣泛的應(yīng)用，但 SQL 就未必了。顧名思義，結(jié)構(gòu)化查詢語言（Structured Query Language）存在一些固有的局限。誰能只使用 SQL 就創(chuàng)建出精彩的動畫電影呢？
這樣說的意圖在于，Python 的簡潔性有助于開發(fā)者發(fā)揮出 SQL 的真正威力，甚至可能是在不知不覺中發(fā)揮出來的。
為何使用托管數(shù)據(jù)庫和 Django 是合理的做法
在創(chuàng)建包括 Django 在內(nèi)的 Web 應(yīng)用程序時(shí)，我們需要決定一些事情，例如：
- 需要怎樣的一種或多種數(shù)據(jù)存儲解決方案？MySQL、Postgres、MongoDB、Redis、Object Storage……
- 如何運(yùn)行以及與數(shù)據(jù)存儲解決方案進(jìn)行集成？
- 如何從中斷或停機(jī)中恢復(fù)？
- 如何維護(hù)存儲解決方案？
- 如何保護(hù)存儲解決方案？
- 如何備份存儲解決方案？
上述這些問題的答案可能會隨著項(xiàng)目復(fù)雜性的提高而改變，但所有答案都始于同一個(gè)地方：決定到底是使用自管理的還是第三方托管的存儲解決方案。
自管理數(shù)據(jù)庫：
- 優(yōu)勢：控制能力和更低的成本
- （巨大的）不足：一切都由我們自行負(fù)責(zé)
托管服務(wù)往往從一開始就需要付出更多成本，而自行管理意味著我們可以使用自己喜歡，并且以某種方式（或在某種程度上）針對我們的需求進(jìn)行了優(yōu)化的 Linux 發(fā)行版。例如我們可以用自己團(tuán)隊(duì)創(chuàng)建并修改的 MySQL 分支版本。自行運(yùn)行的服務(wù)往往更省錢，但需要付出更多的時(shí)間和精力來維護(hù)。
第三方托管數(shù)據(jù)庫服務(wù)：
沒錯(cuò)，這類服務(wù)往往成本更高一些，但可以大幅減少我們需要投入的維護(hù)時(shí)間。這種方式以及托管式的數(shù)據(jù)存儲解決方案已經(jīng)成為很多 Web 應(yīng)用程序的首選。本例中，我們已經(jīng)在使用 Django 來管理數(shù)據(jù)庫事務(wù)，SQLAlchemy 也具備類似優(yōu)勢，因?yàn)樗梢耘浜?FastAPI、Flask 等框架一起使用。如果你已經(jīng)將 SQL 的相關(guān)開發(fā)工作通過 Python 包來實(shí)現(xiàn)，那么為何不把 SQL 服務(wù)器的運(yùn)行也照此處理？
考慮到 Python ORM（例如 Django ORM 和 SQLAlchemy）的效果，建議盡可能使用托管數(shù)據(jù)庫和 / 或托管的數(shù)據(jù)存儲服務(wù)，從而可以獲得下列這些收益：
- 縮短開發(fā)時(shí)間
- 縮短管理時(shí)間
- 縮短恢復(fù)時(shí)間
- 減少服務(wù)中斷
- 降低部署和開發(fā)工作的復(fù)雜度
- 減少（從其他服務(wù)）遷移數(shù)據(jù)庫的復(fù)雜度
- 減少 SQL 開發(fā)者的重復(fù) / 無效 / 低效活動
- 降低 DevOps/Ops 復(fù)雜度
- 提高 non-SQL 開發(fā)者的效率
- 加快部署和開發(fā)速度
- 提高可靠性（托管服務(wù)通常有服務(wù)級別協(xié)議作為保證）
- 增強(qiáng)安全性
- 增強(qiáng)可維護(hù)性
- 增加備份和冗余
- 成本略微增加
實(shí)現(xiàn)上述好處的前提是：在 Linode 平臺上使用托管的 MySQL 數(shù)據(jù)庫集群，并使用 Linode 的 Object Storage（存儲 CSS、JavaScript、圖像、視頻等文件）。實(shí)際上，使用這些服務(wù)還有助于我們將更多精力專注于通過 Django、 FastAPI、Flask、Node.js 等技術(shù)構(gòu)建卓越的 Web 應(yīng)用程序。換句話說，我們可以將工作的重心放在構(gòu)建用戶實(shí)際需要的工具和軟件上，畢竟對用戶而言，這些才是真正的價(jià)值所在。
MySQL、PostgreSQL、Redis 和 Django
很長一段時(shí)間以來，配合 Django 使用最廣泛的數(shù)據(jù)庫都是 PostgreSQL，這在很大程度上可能因?yàn)橹荒茉?Postgres 中使用 JSONField。然而隨著 Django 3.2 + 和 MySQL 5.7.8 + 的推出，JSONField 也已經(jīng)可用于 MySQL 了。
這一點(diǎn)為何重要？
在處理用戶生成的內(nèi)容或存儲來自其他 API 服務(wù)的數(shù)據(jù)時(shí)，通常需要存儲非結(jié)構(gòu)化的數(shù)據(jù)，例如 JSON。一起來看看具體是怎么做的：
from django.db import models
class Pet(models.Model):
name = models.CharField(max_length=200)
data = models.JSONField(null=True)
def __str__(self):
return self.name我們可能想要存儲與“Pet” 有關(guān)的如下數(shù)據(jù)：
pet1 = {
"name": "Bruno",
"type": "Rat",
"nickname": "We don't talk about it",
"age": 2,
"age_interval": "months"
}
pet2 = {
"name": "Tom",
"type": "Cat",
"breed": "Mixed"
"age": 4,
"age_interval: "years",
"favorite_food": [{"brand": "Acme", "flavor": "Tuna" }]
}
pet3 = {
"name": "Stewey",
"type": "Dog",
"breed": "unknown"
"age": 34,
"age_interval: "dog years",
"nickname": "Football"
}從上述數(shù)據(jù)中我們可以知道什么時(shí)候可能需要一個(gè) JSONField。我們可以存儲所有寵物的名字（使用 name 鍵）并將其他信息存儲在 JSONField 中。JSONField 最酷的地方在于，可以像其他標(biāo)準(zhǔn) Django 字段那樣查詢，哪怕它們使用了不同的 Schema。
Django 開發(fā)者之間一直在爭論要使用哪種數(shù)據(jù)庫：MySQL 或是 PostgreSQL。以前，很多人會堅(jiān)持選擇 PostgreSQL，因?yàn)?JSONField 只能在 PostgreSQL 中使用，但現(xiàn)在情況不同了。因此我們完全可以任選一個(gè)并一直使用，直到所選數(shù)據(jù)庫已經(jīng)無法滿足自己的需求。
但為何又要使用 Redis？
Redis 是一種速度驚人的內(nèi)存中數(shù)據(jù)存儲技術(shù)，因此通常被用作臨時(shí)數(shù)據(jù)庫（稍后將詳細(xì)介紹這一點(diǎn)）、緩存服務(wù)以及 / 或消息隊(duì)列。之所以將其稱之為 “臨時(shí)數(shù)據(jù)庫” 是因?yàn)樵摷夹g(shù)將數(shù)據(jù)保存在內(nèi)存中，內(nèi)存通常比磁盤存儲更貴，因此將數(shù)據(jù)長期存儲在內(nèi)存中往往并不是可行的做法。
本例中的 Redis 和 Django 主要用于緩存和隊(duì)列。
緩存：假設(shè)用戶需要頻繁訪問某幾個(gè)網(wǎng)頁，我們希望能盡可能快速地向用戶展示這些頁面的數(shù)據(jù)。如果配合 Django 使用 Redis 作為緩存系統(tǒng)，就可以輕松實(shí)現(xiàn)這一點(diǎn)。這些頁面上的數(shù)據(jù)可能是從一個(gè) SQL 數(shù)據(jù)庫中渲染出來的，但 Redis 依然可以將渲染出的數(shù)據(jù)存儲在緩存中。換句話說，將 Redis 與 SQL 配合使用通常可以加快響應(yīng)速度，同時(shí)減少對 SQL 數(shù)據(jù)庫發(fā)出的查詢數(shù)量。
隊(duì)列：Redis 的另一個(gè)流行用例是將長時(shí)間運(yùn)行的任務(wù)分載（Offload）到另一個(gè)進(jìn)程（這通常可借助一個(gè)名為 Celery 的 Python 包實(shí)現(xiàn)）。如果需要這樣做，即可使用 Redis 作為隊(duì)列，保存需要在另一個(gè)時(shí)間完成的任務(wù)。
舉例來說，如果有用戶需要一份有關(guān)過去五年來所有交易的報(bào)表，軟件可能需要花費(fèi)幾小時(shí)才能生成這樣的報(bào)表。很明顯，沒人愿意盯著計(jì)算機(jī)等待數(shù)小時(shí)之久。因此我們可以把這種請求從用戶那里分載到一個(gè) Redis 隊(duì)列中。一旦放入 Redis，就可以運(yùn)行工作進(jìn)程（例如將 Celery 與 Django 配合使用）來生成報(bào)表。報(bào)表創(chuàng)建完成后，無論該過程花費(fèi)了多長時(shí)間，用戶都能收到通知。和其他通知一樣，這種通知也可以通過 Redis 隊(duì)列與 Celery/Django 工作進(jìn)程配合實(shí)現(xiàn)。
上述內(nèi)容都是為了說明：Redis 和 MySQL 可以實(shí)現(xiàn)非常美妙的互補(bǔ)。我們可以通過 Linode Marketplace 部署自行管理的 Redis 數(shù)據(jù)庫服務(wù)器。
對象存儲
我們推薦的最后一個(gè)與數(shù)據(jù)有關(guān)的托管服務(wù)是 Linode Object Storage。Object Storage 負(fù)責(zé)保存我們需要存儲的所有其他類型的數(shù)據(jù)，畢竟肯定沒人會希望將一個(gè)視頻文件的所有數(shù)據(jù)都存儲在 MySQL 中。數(shù)據(jù)庫可以只用來存儲與視頻有關(guān)的元數(shù)據(jù)，而視頻文件本身，可以存儲在 Object Storage 中。
我們可以使用對象存儲服務(wù)來存儲類似下面這些數(shù)據(jù)：
- 層疊樣式表（CSS）
- JavaScript（例如 React.js、Vue.js、Vanilla.js 等）
- 視頻
- 圖像（原始圖像和壓縮后的圖像）
- CSV、XLSX
- 數(shù)據(jù)庫備份
- Docker 容器鏡像層（如果自行管理）
- 訓(xùn)練后的機(jī)器學(xué)習(xí)算法和后續(xù)迭代
- Terraform State File
- PDF（無論大小）
- 任何需要頻繁下載（或上傳）的演示文稿
總結(jié)
按照本文推薦的思路，任何開發(fā)者都可以在自己的 Web 應(yīng)用程序項(xiàng)目中充分發(fā)揮托管服務(wù)的力量。Django 是一種在 SQL 數(shù)據(jù)庫基礎(chǔ)上構(gòu)建 Web 應(yīng)用的出色解決方案，但它并非唯一。如果希望深入探尋 SQL 和 SQL 服務(wù)器的內(nèi)部原理，我們認(rèn)為有必要通過不斷的研究來了解到底有多少成功的應(yīng)用程序在使用 Django 來處理各種工作。
將 Django 與 Linode 的托管 MySQL 配合使用，可以獲得包括但不限于下面列舉的這些好處：
- Django 代替用戶執(zhí)行繁重的 SQL 任務(wù)（適用于 Flask/FastAPI 的 SQLAlchemy 等工具也是如此）
- Django 可以實(shí)現(xiàn)原始 SQL 命令（SQLAlchemy 之類的工具也可以支持）
- Django 可以幫助新手學(xué)習(xí) SQL 命令
- Django 內(nèi)建了對 MySQL 和 PostgreSQL 的支持（還提供了一個(gè)針對 db 的 Python 客戶端）
- 可提高生產(chǎn)環(huán)境的部署速度
- 可提高可靠性與可恢復(fù)性
- 有助于為開發(fā)和生產(chǎn)環(huán)境提供幾乎完全一致的數(shù)據(jù)庫技術(shù)
- 讓基于容器的 Django 更易用、更可靠
- 實(shí)現(xiàn)了從單節(jié)點(diǎn)部署到多節(jié)點(diǎn)的擴(kuò)展，甚至可全面過渡至 Kubernetes
- 幫助 Django/Python 新手更容易地使用生產(chǎn)級系統(tǒng)
- 更易于跨多個(gè) Python 應(yīng)用共享數(shù)據(jù)庫，并且更安全（例如 FastAPI 應(yīng)用讀 / 寫基于 Django 的 MySQL 數(shù)據(jù)庫）
- Django 的 JSONField 現(xiàn)已支持使用 MySQL（以前只支持 PostgreSQL）
- 更易于測試（在 CI/CD 期間，或在本地開發(fā)環(huán)境中）
- 規(guī)模完全可滿足 Django 的需求
- 支持在一個(gè) Django 項(xiàng)目中使用多個(gè)數(shù)據(jù)庫，例如使用 MySQL 作為主要的讀 / 寫數(shù)據(jù)庫，并用另一個(gè) MySQL 為常用查詢提供可讀副本數(shù)據(jù)庫
- 嚴(yán)格的訪問控制（Linode Private IP、本地開發(fā)）
- 要求通過 SSL 證書進(jìn)行連接（增加了部署復(fù)雜度，但也增強(qiáng)了安全性）
- 實(shí)現(xiàn)私有連接（同一區(qū)域內(nèi)部，降低連接成本）
這篇文章的內(nèi)容感覺還行吧？有沒有想要立即在 Linode 平臺上親自嘗試一下？別忘了，現(xiàn)在注冊可以免費(fèi)獲得價(jià)值 100 美元的使用額度，快點(diǎn)自己動手體驗(yàn)本文介紹的功能和服務(wù)吧↓↓↓
出海云服務(wù)，選擇Akamai Linode！
歡迎關(guān)注 Akamai，我們將定期分享各種實(shí)用技巧，幫助大家了解如何通過現(xiàn)代方法在 Linode 上部署 Django 應(yīng)用程序，如何更好地使用托管的 MySQL 數(shù)據(jù)庫，如何通過 GitHub Actions 實(shí)現(xiàn) CI/CD，以及與 Terraform、Ansible 等技術(shù)有關(guān)的各類實(shí)用技巧。
