通過業務鍵彙總加速查詢 - Simple Log Service

同一業務鍵的日誌會分散寫入 LogStore 的所有 Shard，例如trace_id、session_id 這類業務鍵的等值查詢每次都要掃描全部 Shard，資料規模越大響應越慢。業務鍵彙總儲存（business key aggregated storage）是Log Service SLS 提供的 LogStore 儲存增強能力：按配置的業務鍵欄位，將相同業務鍵或同一業務鏈路的資料穩定寫入同一組 ShardGroup，查詢時按業務鍵自動裁剪無關 Shard。開啟後無需改變寫入方式和查詢文法，即可降低單次查詢的掃描量，提升高頻定向查詢的效率。

適用範圍

業務鍵彙總儲存對地區和儲存物件有以下要求，不滿足時無法使用該能力。

發行地區：當前僅 ap-southeast-8 地區支援業務鍵彙總儲存，其他地區暫不可用。
支援的儲存物件：僅 LogStore 支援業務鍵彙總儲存。

適用情境與業務鍵選型

查詢條件中穩定包含固定的業務鍵欄位時，業務鍵彙總儲存可以顯著減少查詢需要掃描的 Shard 數量。命中裁剪的前提是查詢條件同時包含全部業務鍵欄位的等值匹配，因此配置兩個欄位的組合時，只帶其中一個欄位的查詢會回退為全 Shard 掃描，完整規則參見查詢加速的命中與回退條件。

下表列出典型情境與推薦的業務鍵組合。其中“+”表示將兩個欄位同時配置為一組業務鍵，“、”分隔的是可選其一的多個候選，每組業務鍵最多包含 2 個欄位。

情境	推薦業務鍵	使用者價值
Trace 鏈路排障	`trace_id`、`service` + `trace_id`	查詢某條調用鏈時減少 Shard 掃描範圍，提升鏈路日誌檢索速度。
Agent 應用觀測	`trace_id`、`agent_run_id`、`session_id`	將一次 Agent Run 的模型調用、工具調用、檢索、記憶和例外狀況事件聚集儲存，提升 Trace 查詢效率。
使用者會話分析	`tenant_id` + `session_id`、`tenant_id` + `user_id`	快速查詢某個使用者或某次會話的完整行為日誌。
訂單或交易排障	`tenant_id` + `order_id`、`transaction_id`	快速定位訂單異常、支付失敗、交易鏈路問題。
主機或用戶端訪問日誌	`__source__` + `remote_addr`、`host`	聚集同一來源、用戶端或網域名稱的訪問日誌，便於排障。
IoT 或裝置日誌	`tenant_id` + `device_id`	快速查詢單個裝置的運行、警示和串連日誌。
安全審計或攻擊溯源	`src_ip`、`account_id`、`ak_id`、`user_id`	針對某個 IP、帳號、密鑰或使用者追蹤行為日誌。

收益有限或需先評估的情境

以下情境開啟業務鍵彙總儲存的收益有限，或者可能帶來寫入熱點。開啟前需從三個維度評估：查詢條件是否穩定包含業務鍵欄位、業務鍵欄位值的分布是否集中、業務鍵欄位在日誌中的覆蓋率。

情境	原因
查詢條件很少包含固定業務鍵	查詢時無法按業務鍵裁剪 Shard，收益有限。
業務鍵傾斜嚴重	同一業務索引值的日誌固定寫入同一個 ShardGroup，該索引值的日誌佔比即該 ShardGroup 的寫入佔比，因此欄位值的分布頻率差異過大會導致寫入傾斜。例如單個 `user_id` 的日誌量佔總日誌量超過 20%，則約 20% 的日誌會集中寫入同一個 ShardGroup。
業務鍵欄位缺失率較高	欄位不存在或欄位值為空白時按Null 字元串參與 hash 計算，這些日誌會集中寫入同一個 ShardGroup，造成寫入傾斜，同時聚集效果不明顯。
可寫 Shard 數量過少	每個 ShardGroup 內的可寫 Shard 過少，容災能力有限。可寫 Shard 數量的取值口徑參見“規劃 ShardGroup 數量”。

使用限制

業務鍵欄位最少配置 1 個，最多配置 2 個。
欄位順序參與路由計算，調整欄位順序視為策略變更。
欄位不存在或欄位值為空白時，按Null 字元串參與 hash 計算。
ShardGroup 數量必須為 2 的冪，例如 4、8、16、32、64。
修改策略後，新策略會在短暫延遲後生效；查詢策略變更之前的歷史時間段時，可能回退為全 Shard 掃描。

規劃 ShardGroup 數量

ShardGroup 數量決定查詢裁剪的粒度：分組越多，單次查詢掃描的 Shard 越少，但每個分組內的可寫 Shard 也越少，容災能力和抗熱點能力隨之下降。可寫 Shard 數量與 ShardGroup 數量按以下口徑規劃：

建議至少 8 個可寫 Shard，使每個 ShardGroup 保留 2 個左右的可寫 Shard，具備較好的容災能力。
4 個可寫 Shard 也可以開啟，但每個 ShardGroup 僅約 1 個可寫 Shard，容災能力有限。
控制台根據當前 LogStore 的可寫 Shard 數量給出推薦值，用於在查詢裁剪效果、容災能力和熱點風險之間取得平衡。

當前可寫 Shard 數	推薦 ShardGroup 數	說明
4	4	每組約 1 個可寫 Shard，查詢可以裁剪，但容災能力有限。
8	4	每組約 2 個可寫 Shard，適合開始使用。
16	4 或 8	可根據查詢加速需求選擇。
32	8 或 16	適合高頻定向查詢情境。
64	16 或 32	適合大規模點查、鏈路排障和會話分析。

推薦值給出兩個取值時，取較大值裁剪更細，取較小值則每個 ShardGroup 保留的可寫 Shard 更多。

配置業務鍵彙總儲存

建立 LogStore 時可以直接開啟業務鍵彙總儲存；對已有 LogStore，則在 LogStore 屬性頁面開啟、修改或關閉。兩種方式配置的業務鍵欄位和 ShardGroup 數量含義完全一致。

配置前需完成以下準備：

已在管理Project 中完成 Project 建立，並已按管理LogStore 建立目標 LogStore。
已規劃用於彙總的業務鍵欄位，例如 trace_id、session_id、user_id、order_id。欄位需要在日誌中穩定存在、常用於查詢過濾，且區分度較高。
目標 LogStore 具有足夠的可寫 Shard 數量，取值口徑參見“規劃 ShardGroup 數量”。當前可寫 Shard 數量可以通過管理Shard 描述的 Shard 管理入口查看和調整。

建立 LogStore 時開啟

登入Log Service控制台。
在 Project 列表地區，單擊目標 Project。
在日誌存儲 > 日誌庫頁簽中，單擊 + 表徵圖。
在建立 LogStore 頁面，找到業務鍵彙總儲存配置項。
開啟業務鍵彙總儲存開關，配置業務鍵欄位和分區分組（ShardGroup）數量。ShardGroup 數量建議單擊使用推薦值，由控制台根據當前可寫 Shard 數量給出，取值依據參見“規劃 ShardGroup 數量”。
單擊確定。

修改已有 LogStore 的配置

登入Log Service控制台。
在 Project 列表地區，單擊目標 Project。
在日誌存儲 > 日誌庫頁簽中，將滑鼠懸浮在目標 LogStore 上，選擇修改。
在 LogStore 屬性頁面左側導覽列，單擊業務鍵彙總儲存。
尚未開啟時，開啟業務鍵彙總儲存開關並配置業務鍵欄位和分區分組（ShardGroup）數量；已開啟時，按需修改業務鍵欄位（包括欄位順序）或分區分組（ShardGroup）數量。
單擊儲存。

說明

修改業務鍵欄位、欄位順序或 ShardGroup 數量屬於策略變更，僅對變更生效後新寫入的資料生效，歷史資料不會重新分配。

關閉業務鍵彙總儲存

關閉業務鍵彙總儲存後，後續新寫入的資料不再按業務鍵彙總，按業務鍵的查詢裁剪隨之失效。已寫入的歷史資料仍保留在原有 Shard 中，不會被自動遷移或重新分配，因此關閉操作不會造成資料丟失，也不會觸發資料重寫。

登入Log Service控制台，在 Project 列表地區單擊目標 Project。
在日誌存儲 > 日誌庫頁簽中，將滑鼠懸浮在目標 LogStore 上，選擇修改，進入 LogStore 屬性頁面。
在左側導覽列，單擊業務鍵彙總儲存。
關閉業務鍵彙總儲存開關。
單擊儲存。

參數說明

建立 LogStore 和修改 LogStore 屬性時，業務鍵彙總儲存相關配置項的含義如下。

參數	說明
業務鍵彙總儲存	是否開啟業務鍵彙總儲存。開啟後，Log Service按業務鍵將相關日誌寫入同一組 ShardGroup。
業務鍵欄位	用於決定日誌落入哪個 ShardGroup 的欄位，最少 1 個，最多 2 個。欄位順序參與路由計算。
分區分組（ShardGroup）數量	用於業務鍵彙總的邏輯分組數量。必須為 2 的冪，建議使用系統推薦值。
使用推薦值	根據當前可寫 Shard 數自動計算並填入推薦的 ShardGroup 數量。
Shard 分區資料均衡狀態	展示當前 LogStore 的 Shard 資料範圍是否均衡，用於判斷是否需要執行資料 Rerange。
資料 Rerange	重新分配 Shard 資料範圍，改善 Shard 資料範圍不均衡問題。執行前需確認業務側是否已通過 SDK 指定 Hash 寫入。

查詢加速的命中與回退條件

開啟業務鍵彙總儲存後，如果查詢條件包含全部業務鍵欄位的等值匹配，Log Service會根據業務鍵計算出目標 ShardGroup，只掃描該分組對應的 Shard，而不是掃描 LogStore 的全部 Shard，從而減少參與計算的資料規模。例如業務鍵配置為 tenant_id 和 agent_run_id 兩個欄位，查詢條件為：

tenant_id = 'tenant-a' AND agent_run_id = 'run-001'

此時Log Service可以定位到唯一的目標 ShardGroup，僅掃描該分組內的資料。以下情況無法命中業務鍵彙總儲存，查詢會回退為全 Shard 掃描：

查詢條件缺少任一業務鍵欄位。
業務鍵欄位不是等值匹配，例如模糊查詢、範圍查詢或正則查詢。
查詢時間範圍跨越策略變更時間，無法按單一策略裁剪。
查詢運算式無法確定唯一的業務索引值。
當前 LogStore 未開啟業務鍵彙總儲存。

計費說明

業務鍵彙總儲存本身不改變 LogStore 的計費模式，開啟後日誌的寫入、儲存、查詢和分析費用仍按當前 LogStore 的計費模式收取。

如果查詢命中業務鍵裁剪，掃描的資料量和查詢耗時會下降，相關的查詢分析費用也可能隨之降低。實際效果取決於查詢條件是否包含完整業務鍵、ShardGroup 數量配置、資料分布以及查詢的時間範圍。

常見問題

為什麼開啟後查詢沒有明顯變快？

首先按查詢加速的命中與回退條件核對查詢是否命中裁剪，重點確認查詢條件是否包含全部業務鍵欄位的等值匹配、查詢時間範圍是否包含策略生效之前的資料。若查詢本身滿足命中條件，則排查兩類資料側原因：日誌中業務鍵欄位的缺失率較高，聚集效果不明顯；ShardGroup 數量過少，掃描裁剪比例有限。

什麼情況下需要資料 Rerange？

當Shard 分區資料均衡狀態顯示 Shard 資料範圍不均衡時，可以考慮執行資料 Rerange。執行前需確認業務側是否通過 SDK 等方式指定了 Hash 寫入：如果業務側持續指定 Hash 寫入，Rerange 之後仍可能繼續產生熱點。