最佳化查詢效能

Amazon QLDB 旨在滿足高效能線上交易處理 (OLTP) 工作負載需要達成效能線上交易處理 (OLTP) 工作負載 這表示 QLDB 已針對一組特定的查詢模式進行最佳化，即使它支援類似 SQL 的查詢功能。設計應用程式及其資料模型以使用這些查詢模式至關重要。否則，隨著資料表的成長，您將會遇到重大的效能問題，包括查詢延遲、交易逾時和並行衝突。

本節說明 QLDB 中的查詢條件約束，並針對這些限制提供撰寫最佳查詢的指引。

交易逾時上限

在 QLDB 中，每個 PartiQL 陳述式 (包括每個SELECT查詢) 都會在交易中處理，並受到交易逾時限制的限制。在認可之前，交易最多可以執行 30 秒。在此限制之後，QLDB 會拒絕在交易上完成的任何工作，並捨棄執行交易的工作階段。此限制可透過啟動交易而不提交或取消工作階段來保護服務的用戶端不會洩漏工作階段。

并发冲突

QLDB 通過使用樂觀並發控制（OCC）實現並發控制。次優查詢也可能導致更多的 OCC 衝突。如需 OCC 的相關資訊，請參閱Amazon QLLDB 並行模型。

最佳查詢模式

最佳做法是，您應該執行含有WHERE述詞子句的陳述式，以篩選索引欄位或文件 ID。QLDB 需要在索引欄位上使用相等運算子 (=或IN)，才能有效率地查詢文件。

以下是使用者檢視中最佳化查詢模式的範例。

--Indexed field (VIN) lookup using the = operator
SELECT * FROM VehicleRegistration
WHERE VIN = '1N4AL11D75C109151'

--Indexed field (VIN) AND non-indexed field (City) lookup
SELECT * FROM VehicleRegistration
WHERE VIN = '1N4AL11D75C109151' AND City = 'Seattle'

--Indexed field (VIN) lookup using the IN operator
SELECT * FROM VehicleRegistration
WHERE VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')

--Document ID (r_id) lookup using the BY clause
SELECT * FROM VehicleRegistration BY r_id
WHERE r_id = '3Qv67yjXEwB9SjmvkuG6Cp'

任何不遵循這些模式的查詢都會叫用完整資料表掃描。對於大型資料表或傳回大型結果集的查詢，資料表掃描可能會造成交易逾時。它們還可能導致 OCC 與競爭交易衝突。

高基數索引

我們建議您對包含高基數值的欄位進行索引。例如，資VehicleRegistration料表中的VIN和LicensePlateNumber欄位都是唯一的索引欄位。

避免索引低基數欄位，例如狀態碼、地址州或省和郵遞區號。如果您為這類欄位建立索引，您的查詢可能會產生較大的結果集，這些結果集較有可能導致交易逾時或造成意外的 OCC 衝突。

已提交檢視查詢

您在已提交檢視中執行的查詢遵循與使用者檢視查詢相同的最佳化準則。您在資料表上建立的索引也會用於已提交檢視中的查詢。

歷史函數查詢

歷史記錄函數查詢不使用您在表上創建的索引。QLDB 歷史記錄僅由文件 ID 編製索引，而且您目前無法建立其他歷史記錄索引。

最佳做法是使用日期範圍 (開始時間和結束時間) 和文件 ID (metadata.id) 來限定歷史記錄查詢。包含開始時間和結束時間的歷史查詢可獲得日期範圍限定的好處。

內部聯結查詢

對於內部聯結查詢，請使用聯結準則，其中至少包含聯結右側資料表的索引欄位。如果沒有聯結索引，聯結查詢會叫用多個資料表掃描 — 對於聯結左側資料表中的每個文件，查詢會完全掃描右側資料表。最佳做法是加入每個您要加入的資料表索引的欄位，以及為至少一個資料表指定WHERE相等述詞。

例如，下列查詢會聯結各自VIN欄位上的VehicleRegistration和Vehicle資料表，這兩個欄位都會建立索引。這個查詢也有一個相等謂詞VehicleRegistration.VIN。

SELECT * FROM VehicleRegistration AS r INNER JOIN Vehicle AS v
ON r.VIN = v.VIN
WHERE r.VIN IN ('1N4AL11D75C109151', 'KM8SRDHF6EU074761')

為聯結準則和聯結查詢中的相等述詞選擇高基數索引。

需要避免的查詢模式

以下是一些次優陳述式的範例，這些陳述式對於 QLDB 中較大的資料表而言無法很好地擴充。我們強烈建議您不要依賴這些類型的查詢，因為您的查詢最終會導致交易逾時。由於表格包含大小不同的文件，因此很難定義非索引查詢的精確限制。

--No predicate clause
SELECT * FROM Vehicle

--COUNT() is not an optimized function
SELECT COUNT(*) FROM Vehicle

--Low-cardinality predicate
SELECT * FROM Vehicle WHERE Color = 'Silver'

--Inequality (>) does not qualify for indexed lookup
SELECT * FROM Vehicle WHERE "Year" > 2019

--Inequality (LIKE)
SELECT * FROM Vehicle WHERE VIN LIKE '1N4AL%'

--Inequality (BETWEEN)
SELECT SUM(PendingPenaltyTicketAmount) FROM VehicleRegistration
WHERE ValidToDate BETWEEN `2020-01-01T` AND `2020-07-01T`

--No predicate clause
DELETE FROM Vehicle

--No document id, and no date range for the history() function
SELECT * FROM history(Vehicle)

一般而言，我們不建議在 QLDB 中針對生產使用案例執行下列類型的查詢模式：

• 線上分析處理 (OLAP) 查詢

• 沒有謂詞子句的探索性查詢

• 報告查詢

• 文字搜尋

相反地，我們建議您將資料串流至針對分析使用案例進行最佳化的專用資料庫服務。例如，您可以將 QLDB 資料串流至亞馬遜 OpenSearch 服務，以便在文件上提供全文搜尋功能。如需示範此使用案例的範例應用程式，請參閱 GitHub 儲存庫 aws-Samples/amazon-qldb-streaming-amazon-opensearch-service-sample-python。如需 QLDB 串流的相關資訊，請參閱從 Amazon QLDB 串流日誌資料。

監控效能

QLDB 驅動程式會在陳述式的結果物件中提供耗用的 I/O 使用和計時資訊。您可以使用這些指標來識別效率低下的 PartiQL 陳述式。要了解更多信息，請繼續取得 PartiQL 陳述式統計。

您也可以使用 Amazon CloudWatch 追蹤分類帳的資料操作效能。監督CommandLatency指定的LedgerName和的測量結果CommandType。如需詳細資訊，請參閱使用 Amazon 監控 CloudWatch。若要瞭解 QLDB 如何使用指令來管理資料作業，請參閱驅動程式的工作階段管理。