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

通常，Tortoise基準可以評估各種ORM的查詢執行速度。但是，這種測試方法存在一個缺陷：大多數ORM被選擇用于Web應用程序。在這種情況下，多個用戶經常將所有形式的查詢發送到數據庫。因為在這種情況下沒有評估的基準測試工具能夠評估Python ORM的性能，所以我決定編寫自己的PonyORM和SQLAlchemy進行比較。作為基礎，我采用了TPC-C基準。

自1988年以來，TPC一直在數據處理領域開發測試。它們早已成為行業標準，幾乎所有設備供應商都在各種硬件和軟件樣本上使用它們。這些測試的主要特征是它們專注于在盡可能接近真實條件的巨大負載下進行測試。

TPC-C模擬倉庫網絡。它包括五個同時執行的各種類型和復雜性的事務的組合。該測試的目的是評估多個虛擬用戶同時訪問數據庫時事務處理的速度。

我決定使用適合此任務的TPC-C測試方法測試兩個Python ORM（SQLALchemy和PonyORM）。該測試的目的是評估多個虛擬用戶同時訪問數據庫時事務處理的速度。

　　測試說明

第一步是創建并填充倉庫網絡的數據庫。

該數據庫包含八個關系：

1. 倉庫

2. 區

3. 訂購

4. 訂單行

5. 股票

6. 項目

7. 顧客

8. 歷史

Pony和SQLAlchemy的數據庫是相同的。僅索引主鍵和外鍵。小A會自動創建這些索引。在SQLAlchemy中，我手動創建了它。

在測試過程中，幾種虛擬用戶將不同類型的事務發送到數據庫。每個事務包含幾個請求。總共有五種類型的交易以不同的發生概率提交處理：

　　交易：

1. 新訂單-45%

2. 付款-43%

3. order_status-4%

4. 交付-4%

5. 股票水平-4%

發生交易的可能性與原始TPC-C測試中的相同。

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

　　與TPC-C測試的主要區別如下：

1. 該測試運行的虛擬用戶少于原始測試。

2. 我的測試的表條目較少。例如：原始測試中“庫存”關系中的條目數是使用公式100,000 * W計算的，其中W是倉庫數。在此測試中為100 *W。

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

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

接下來，我將簡要描述每個事務的作用。

　　交易次數

　　新命令

1. 將兩個參數傳遞給事務：倉庫ID和客戶ID

2. 使用傳遞的ID從數據庫中選擇倉庫和客戶

3. 從數據庫中隨機選擇一個倉庫區域

4. 生成指示訂單行數的隨機數。

5. 創建一個Order對象

6. 循環創建OrderLine對象。在循環的每次迭代中，從項目表中選擇一個隨機項目

7. 更改訂單中每個項目的庫存

付款

1. 將兩個參數傳遞給事務：倉庫ID和客戶ID

2. 通過傳遞的ID從數據庫中選擇倉庫和客戶

3. 從數據庫中隨機選擇一個倉庫區域

4. 生成一個指示付款金額的隨機數

5. 按付款金額增加倉庫和區域的余額

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

7. 遞增客戶付款柜臺

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

9. 創建歷史記錄對象

　　訂單狀態

1. 傳遞客戶ID作為交易的參數

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

3. 從訂單中獲取訂單狀態和訂單行

　　交貨

1. 傳遞倉庫ID作為交易參數

2. 從數據庫中選擇倉庫及其所有區域

3. 為每個地區選擇最舊的未交付訂單

4. 對于每個將交貨狀態更改為True的訂單

5. 對于每個訂單數量遞增的客戶

　　庫存水平

1. 傳遞倉庫ID作為交易參數

2. 通過ID從數據庫中選擇倉庫

3. 選擇該倉庫的最后20個訂單

4. 對于訂單中的每個項目，評估項目的庫存水平

　　檢測結果

有兩個ORM參與測試：

1. SQLAlchemy

2. PonyORM

　   通過2個并行進程訪問數據庫運行測試10分鐘的結果。使用“多重處理”模塊啟動流程。

X軸-時間（以分鐘為單位）

Y軸-已完成的交易數

作為DBMS，我使用PostgreSQL

　　所有交易

首先，按照TPC-C測試中的預期，我對所有五個事務進行了測試。這項測試的結果是，小A的速度大約是以前的兩倍。

　　平均速度：

· 小A-2543筆交易/分鐘

· SQLAlchemy-1353.4事務/分鐘

之后，我決定分別評估五筆交易中ORM的性能。以下是每筆交易的結果。

　　新命令

平均速度：

· 小A-3349.2交易/分鐘

· SQLAlchemy-1415.3事務/分鐘

　　付款

平均速度：

· 小A-7175.3事務/分鐘

· SQLAlchemy-4110.6事務/分鐘

　　訂單狀態

平均速度：

· 小A-16645.6交易/分鐘

· SQLAlchemy-4820.8事務/分鐘

　　交貨

平均速度：

· SQLAlchemy-716.9事務/分鐘

· 小A-323.5交易/分鐘

　　庫存水平

平均速度：

· 小A-677.3交易/分鐘

· SQLAlchemy-167.9事務/分鐘

　　測試結果分析

收到結果后，我分析了為什么會這樣，并得出以下結論：

在5分之4的事務中，PonyORM的速度更快，因為在生成SQL代碼時，PonyORM會記住將Python表達式轉換為SQL的結果。因此，Pony不會在重復查詢時再次轉換該表達式，而SQLAlchemy在每次需要執行查詢時都被強制生成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可以更快地執行交付類型事務，因為它可以將應用于不同對象的多個UPDATE操作組合到一個命令中。

例：

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會為每個更新發送單獨的查詢。

　　結論

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

以上就是關于基于TPC-C基準的Python ORM的性能測試的全部內容，想了解更多關于Python信息，請繼續關注中培偉業。