當(dāng)開發(fā)與數(shù)據(jù)庫(kù)需要在一起使用的應(yīng)用程序時(shí)，對(duì)象關(guān)系映射器（ORM）通常用于Python編程中。Python ORM的示例是SQLAlchemy，Peewee，Pony-ORM和Django。選擇ORM性能起著至關(guān)重要的作用。但是如何比較這些工具集？ORM性能基準(zhǔn)提供了明確的度量，但仍有很大的改進(jìn)空間。我研究并擴(kuò)展了定性的ORM基準(zhǔn)，以幫助有需要開發(fā)需要的。定性的Python ORM基準(zhǔn)Tortoise ORM（鏈接到存儲(chǔ)庫(kù)）分析了11種SQL查詢的六個(gè)ORM的速度。

通常，Tortoise基準(zhǔn)可以評(píng)估各種ORM的查詢執(zhí)行速度。但是，這種測(cè)試方法存在一個(gè)缺陷：大多數(shù)ORM被選擇用于Web應(yīng)用程序。在這種情況下，多個(gè)用戶經(jīng)常將所有形式的查詢發(fā)送到數(shù)據(jù)庫(kù)。因?yàn)樵谶@種情況下沒有評(píng)估的基準(zhǔn)測(cè)試工具能夠評(píng)估Python ORM的性能，所以我決定編寫自己的PonyORM和SQLAlchemy進(jìn)行比較。作為基礎(chǔ)，我采用了TPC-C基準(zhǔn)。

自1988年以來(lái)，TPC一直在數(shù)據(jù)處理領(lǐng)域開發(fā)測(cè)試。它們?cè)缫殉蔀樾袠I(yè)標(biāo)準(zhǔn)，幾乎所有設(shè)備供應(yīng)商都在各種硬件和軟件樣本上使用它們。這些測(cè)試的主要特征是它們專注于在盡可能接近真實(shí)條件的巨大負(fù)載下進(jìn)行測(cè)試。

TPC-C模擬倉(cāng)庫(kù)網(wǎng)絡(luò)。它包括五個(gè)同時(shí)執(zhí)行的各種類型和復(fù)雜性的事務(wù)的組合。該測(cè)試的目的是評(píng)估多個(gè)虛擬用戶同時(shí)訪問數(shù)據(jù)庫(kù)時(shí)事務(wù)處理的速度。

我決定使用適合此任務(wù)的TPC-C測(cè)試方法測(cè)試兩個(gè)Python ORM（SQLALchemy和PonyORM）。該測(cè)試的目的是評(píng)估多個(gè)虛擬用戶同時(shí)訪問數(shù)據(jù)庫(kù)時(shí)事務(wù)處理的速度。

　　測(cè)試說明

第一步是創(chuàng)建并填充倉(cāng)庫(kù)網(wǎng)絡(luò)的數(shù)據(jù)庫(kù)。

該數(shù)據(jù)庫(kù)包含八個(gè)關(guān)系：

1. 倉(cāng)庫(kù)

2. 區(qū)

3. 訂購(gòu)

4. 訂單行

5. 股票

6. 項(xiàng)目

7. 顧客

8. 歷史

Pony和SQLAlchemy的數(shù)據(jù)庫(kù)是相同的。僅索引主鍵和外鍵。小A會(huì)自動(dòng)創(chuàng)建這些索引。在SQLAlchemy中，我手動(dòng)創(chuàng)建了它。

在測(cè)試過程中，幾種虛擬用戶將不同類型的事務(wù)發(fā)送到數(shù)據(jù)庫(kù)。每個(gè)事務(wù)包含幾個(gè)請(qǐng)求。總共有五種類型的交易以不同的發(fā)生概率提交處理：

　　交易：

1. 新訂單-45%

2. 付款-43%

3. order_status-4%

4. 交付-4%

5. 股票水平-4%

發(fā)生交易的可能性與原始TPC-C測(cè)試中的相同。

但是，請(qǐng)記住，由于技術(shù)上的限制以及我想測(cè)試以下處理器的性能，因此在具有64 GB以上RAM(需要大量處理器和巨大磁盤空間)的服務(wù)器上進(jìn)行了原始TPC-C測(cè)試。 ORM而不是硬件抵抗巨大負(fù)載的能力，因此此測(cè)試有所簡(jiǎn)化。

　　與TPC-C測(cè)試的主要區(qū)別如下：

1. 該測(cè)試運(yùn)行的虛擬用戶少于原始測(cè)試。

2. 我的測(cè)試的表?xiàng)l目較少。例如：原始測(cè)試中“庫(kù)存”關(guān)系中的條目數(shù)是使用公式100,000 * W計(jì)算的，其中W是倉(cāng)庫(kù)數(shù)。在此測(cè)試中為100 *W。

3. 在TPC-C中，某些事務(wù)具有從數(shù)據(jù)庫(kù)查詢數(shù)據(jù)的多個(gè)選項(xiàng)。例如，在支付交易中，有一種可能性，將通過ID從數(shù)據(jù)庫(kù)中請(qǐng)求客戶，而另一種則是由姓和名。目前，我的測(cè)試僅按ID撥打電話。

4. 我的測(cè)試數(shù)據(jù)庫(kù)比TPC-C少一個(gè)表。在TPC-C測(cè)試中，創(chuàng)建訂單后，會(huì)將其添加到Order表和NewOrder表中。訂單交付后，便從NewOrder表中將其刪除。每分鐘應(yīng)用大量事務(wù)時(shí)，這可以加快工作速度；但是由于我訪問數(shù)據(jù)庫(kù)的用戶較少，所以這是不必要的。相反，在Order表中，我添加了bool屬性“ is_o_delivered”，該屬性將為False，直到交付訂單為止。

接下來(lái)，我將簡(jiǎn)要描述每個(gè)事務(wù)的作用。

　　交易次數(shù)

　　新命令

1. 將兩個(gè)參數(shù)傳遞給事務(wù)：倉(cāng)庫(kù)ID和客戶ID

2. 使用傳遞的ID從數(shù)據(jù)庫(kù)中選擇倉(cāng)庫(kù)和客戶

3. 從數(shù)據(jù)庫(kù)中隨機(jī)選擇一個(gè)倉(cāng)庫(kù)區(qū)域

4. 生成指示訂單行數(shù)的隨機(jī)數(shù)。

5. 創(chuàng)建一個(gè)Order對(duì)象

6. 循環(huán)創(chuàng)建OrderLine對(duì)象。在循環(huán)的每次迭代中，從項(xiàng)目表中選擇一個(gè)隨機(jī)項(xiàng)目

7. 更改訂單中每個(gè)項(xiàng)目的庫(kù)存

付款

1. 將兩個(gè)參數(shù)傳遞給事務(wù)：倉(cāng)庫(kù)ID和客戶ID

2. 通過傳遞的ID從數(shù)據(jù)庫(kù)中選擇倉(cāng)庫(kù)和客戶

3. 從數(shù)據(jù)庫(kù)中隨機(jī)選擇一個(gè)倉(cāng)庫(kù)區(qū)域

4. 生成一個(gè)指示付款金額的隨機(jī)數(shù)

5. 按付款金額增加倉(cāng)庫(kù)和區(qū)域的余額

6. 客戶余額減少付款金額

7. 遞增客戶付款柜臺(tái)

8. 客戶付款金額的總和增加

9. 創(chuàng)建歷史記錄對(duì)象

　　訂單狀態(tài)

1. 傳遞客戶ID作為交易的參數(shù)

2. 通過ID和該客戶的最后訂單選擇客戶

3. 從訂單中獲取訂單狀態(tài)和訂單行

　　交貨

1. 傳遞倉(cāng)庫(kù)ID作為交易參數(shù)

2. 從數(shù)據(jù)庫(kù)中選擇倉(cāng)庫(kù)及其所有區(qū)域

3. 為每個(gè)地區(qū)選擇最舊的未交付訂單

4. 對(duì)于每個(gè)將交貨狀態(tài)更改為True的訂單

5. 對(duì)于每個(gè)訂單數(shù)量遞增的客戶

　　庫(kù)存水平

1. 傳遞倉(cāng)庫(kù)ID作為交易參數(shù)

2. 通過ID從數(shù)據(jù)庫(kù)中選擇倉(cāng)庫(kù)

3. 選擇該倉(cāng)庫(kù)的最后20個(gè)訂單

4. 對(duì)于訂單中的每個(gè)項(xiàng)目，評(píng)估項(xiàng)目的庫(kù)存水平

　　檢測(cè)結(jié)果

有兩個(gè)ORM參與測(cè)試：

1. SQLAlchemy

2. PonyORM

　   通過2個(gè)并行進(jìn)程訪問數(shù)據(jù)庫(kù)運(yùn)行測(cè)試10分鐘的結(jié)果。使用“多重處理”模塊啟動(dòng)流程。

X軸-時(shí)間（以分鐘為單位）

Y軸-已完成的交易數(shù)

作為DBMS，我使用PostgreSQL

　　所有交易

首先，按照TPC-C測(cè)試中的預(yù)期，我對(duì)所有五個(gè)事務(wù)進(jìn)行了測(cè)試。這項(xiàng)測(cè)試的結(jié)果是，小A的速度大約是以前的兩倍。

　　平均速度：

· 小A-2543筆交易/分鐘

· SQLAlchemy-1353.4事務(wù)/分鐘

之后，我決定分別評(píng)估五筆交易中ORM的性能。以下是每筆交易的結(jié)果。

　　新命令

平均速度：

· 小A-3349.2交易/分鐘

· SQLAlchemy-1415.3事務(wù)/分鐘

　　付款

平均速度：

· 小A-7175.3事務(wù)/分鐘

· SQLAlchemy-4110.6事務(wù)/分鐘

　　訂單狀態(tài)

平均速度：

· 小A-16645.6交易/分鐘

· SQLAlchemy-4820.8事務(wù)/分鐘

　　交貨

平均速度：

· SQLAlchemy-716.9事務(wù)/分鐘

· 小A-323.5交易/分鐘

　　庫(kù)存水平

平均速度：

· 小A-677.3交易/分鐘

· SQLAlchemy-167.9事務(wù)/分鐘

　　測(cè)試結(jié)果分析

收到結(jié)果后，我分析了為什么會(huì)這樣，并得出以下結(jié)論：

在5分之4的事務(wù)中，PonyORM的速度更快，因?yàn)樵谏蒘QL代碼時(shí)，PonyORM會(huì)記住將Python表達(dá)式轉(zhuǎn)換為SQL的結(jié)果。因此，Pony不會(huì)在重復(fù)查詢時(shí)再次轉(zhuǎn)換該表達(dá)式，而SQLAlchemy在每次需要執(zhí)行查詢時(shí)都被強(qiáng)制生成SQL代碼。

Pony中此類查詢的示例：

stocks = select(stock for stock in Stock

if stock.warehouse == whouse

and stock.item in items).order_by(Stock.id).for_update()

　　生成的SQL：

SELECT "stock"."id", "stock"."warehouse", "stock"."item",

"stock"."quantity", "stock"."ytd", "stock"."order_cnt",

"stock"."remote_cnt", "stock"."data"FROM "stock" "stock"WHERE "stock"."warehouse" = %(p1)s

AND "stock"."item" IN (%(p2)s, %(p3)s)ORDER BY "stock"."id"FOR UPDATE

{'p1':7, 'p2':7, 'p3':37}

　　SQLAlchemy：

stocks = session.query(Stock).filter(

Stock.warehouse == whouse, Stock.item.in_(

items)).order_by(text("id")).with_for_update()

　　生成的SQL：

SELECT stock.id AS stock_id, stock.warehouse_id AS stock_warehouse_id,

stock.item_id AS stock_item_id, stock.quantity AS stock_quantity,

stock.ytd AS stock_ytd, stock.order_cnt AS stock_order_cnt,

stock.remote_cnt AS stock_remote_cnt, stock.data AS stock_dataFROM stockWHERE stock.warehouse_id = %(warehouse_id_1)s AND stock.item_id IN

(%(item_id_1)s, %(item_id_2)s) ORDER BY id FOR UPDATE

{'warehouse_id_1': 7, 'item_id_1': 53, 'item_id_2': 54}

但是，顯然，SQLAlchemy可以更快地執(zhí)行交付類型事務(wù)，因?yàn)樗梢詫?yīng)用于不同對(duì)象的多個(gè)UPDATE操作組合到一個(gè)命令中。

例：

INFO:sqlalchemy.engine.base.Engine:UPDATE order_line SET delivery_d=%

(delivery_d)s WHERE order_line.id = %(order_line_id)s

INFO:sqlalchemy.engine.base.Engine:(

{'delivery_d': datetime.datetime(2020, 4, 6, 14, 33, 6, 922281),

'order_line_id': 316},

{'delivery_d': datetime.datetime(2020, 4, 6, 14, 33, 6, 922272),

'order_line_id': 317},

{'delivery_d': datetime.datetime(2020, 4, 6, 14, 33, 6, 922261))

在這種情況下，小A會(huì)為每個(gè)更新發(fā)送單獨(dú)的查詢。

　　結(jié)論

根據(jù)測(cè)試的結(jié)果，我可以說Pony從數(shù)據(jù)庫(kù)中選擇的速度更快。另一方面，在某些情況下，SQLAlchemy可以以更高的速度生成Update類型的查詢。

以上就是關(guān)于基于TPC-C基準(zhǔn)的Python ORM的性能測(cè)試的全部?jī)?nèi)容，想了解更多關(guān)于Python信息，請(qǐng)繼續(xù)關(guān)注中培偉業(yè)。