為協助您進一步瞭解、改善及診斷交易問題,Spanner 提供交易提交統計資料。目前您可以擷取交易的變動總數。
何時使用提交統計資料
在下列情境中,瞭解交易的修改作業計數很有幫助。
最佳化往返行程
如要提升應用程式效能,請盡可能在每個交易中完成更多工作,減少資料庫的來回次數。在這種情況下,您希望盡可能增加每筆交易的變異次數,同時維持在系統限制內。
如要判斷每筆交易可提交的資料列數量上限,請先在交易中提交一列資料。這樣就能取得每列的突變計數基準。然後將系統限制除以基準值,即可取得每筆交易的資料列數。如要進一步瞭解突變的計算方式,請參閱這則附註。
使用 DML 時,80,000 個的限制 (包括索引) 是套用至每個陳述式,而非每筆交易。您可以在單一交易中執行多個 DML 陳述式,提交超過 80,000 個變異,但交易大小不得超過 100 MiB。在這種情況下,提交統計資料中傳回的 mutation_count 會反映所有陳述式的累計異動總數 (包括索引),且可能超過 80,000。
請注意,針對來回行程進行最佳化不一定有益,尤其是如果導致更多鎖定爭用時。您可以使用鎖定統計資料,排解資料庫中的鎖定衝突問題。
監控交易,避免達到系統限制
隨著應用程式用量增加,交易中的變動次數也可能隨之增加。為避免達到系統上限,導致交易最終失敗,您可以主動監控一段時間內的修改作業計數提交統計資料。如果發現同一筆交易的這項值增加,可能需要按照前一節的說明,重新最佳化交易。
如何存取提交統計資料
預設不會傳回提交統計資料。您必須在每個 CommitRequest 上將 return_commit_stats 旗標設為 true。如果您使用 Mutation API,且嘗試提交的變動 (包括索引) 超過允許的最大變動數,提交作業就會失敗,並傳回 INVALID_ARGUMENT 錯誤。如果是 DML,超出修改作業限制 (包括索引) 會導致個別 DML 陳述式在執行期間失敗並顯示 BadUsage 錯誤,而不是在提交時失敗。
以下範例說明如何使用 Spanner 用戶端程式庫傳回提交統計資料。
擷取提交統計資料
以下範例顯示如何使用 Spanner 用戶端程式庫取得提交統計資料。
C++
下列程式碼會在 CommitOptions 上呼叫 set_return_stats(),並傳回 6 的修改作業計數,因為我們要在每個資料列中插入或更新 2 個資料列和 3 個資料欄。
C#
在 C# 中,API 不會直接傳回提交統計資料。而是由預設記錄器以「資訊」記錄層級記錄。
下列程式碼會將 SpannerConnectionStringBuilder 上的 LogCommitStats 屬性設為 true,為所有交易啟用提交統計資料記錄。程式碼也會實作範例記錄器,保留對上次所見提交回應的參照。接著,系統會從這個回應中擷取 MutationCount 並顯示。
Go
下列程式碼會設定 ReturnCommitStats 旗標,並在交易成功提交時顯示修改作業次數。
Java
Node.js
下列程式碼會設定 returnCommitStats 旗標,並傳回 6 個修改作業計數,因為我們要在每個資料列中插入或更新 2 個資料列和 3 個資料欄。
PHP
Python
Python 用戶端程式庫不會透過 API 直接傳回提交統計資料,而是使用 stdout 以 Info 層級記錄這些資料。
下列程式碼會設定 database.log_commit_stats = True,為所有交易啟用提交統計資料記錄。程式碼也會實作範例記錄器,保留對上次所見修訂回應的參照。接著,系統會從這項回應中擷取 mutation_count 並顯示。
小茹
下列程式碼會設定 return_commit_stats 旗標,並傳回 6 個修改作業計數,因為我們要在每個資料列中插入或更新 2 個資料列和 3 個資料欄。