資料欄引擎總覽

本文件說明如何使用 AlloyDB Omni 資料欄引擎，並假設您熟悉 PostgreSQL。

AlloyDB Omni 資料欄引擎提供下列元件，可加快掃描、聯結和匯總的 SQL 查詢處理速度：

您可以在主要執行個體、讀取集區執行個體或唯讀副本上使用資料欄引擎，也可以同時在兩者上使用。您也可以使用自動欄狀化功能分析工作負載，並自動在資料欄存放區中填入可提供最佳效能增益的資料欄。

如要透過特定查詢使用資料欄引擎，查詢中參照的所有資料欄 (例如聯結和掃描) 都必須位於資料欄存放區。

根據預設，資料欄引擎會使用 1 GB 的執行個體記憶體。視工作負載、記憶體用量，以及是否設定讀取集區執行個體或唯讀副本而定，您可以選擇減少主要執行個體的資料欄引擎記憶體配置，並為讀取集區執行個體或唯讀副本分配更多記憶體。

如要查看及監控直欄引擎的記憶體用量，請參閱「查看直欄儲存空間記憶體用量」。如要修改資料欄儲存庫使用的記憶體大小，請參閱「設定資料欄儲存庫的大小」。如要查看執行個體的建議資料欄引擎記憶體大小，請參閱「建議的資料欄儲存庫記憶體大小」。

適合使用資料欄引擎的查詢類型

資料欄引擎可提升特定查詢的效能。以下列出最能受惠於資料欄引擎的作業和查詢模式：

作業	查詢模式
掃描資料表	選擇性篩選器，例如 `WHERE` 子句。大型資料表或 materialized view 中的少數資料欄。 `LIKE`、`SUBSTR` 或 `TRIM` 等運算式。
匯總函式	僅限 `SUM`、`MIN`、`MAX`、`AVG` 和 `COUNT` 等運算式。在資料欄掃描查詢的開頭。未分組或按欄分組。
`ORDER BY`	只有在資料欄掃描的查詢開頭使用運算子時，才需要這麼做。
`SORT`	只有在運算子位於資料行掃描查詢的開頭，且只依資料表或 materialized view 的基本資料行排序時，才會發生這種情況。
`LIMIT`	只有在運算子位於資料欄掃描的查詢開頭，且位於任何 `SORT` 或 `GROUP BY` 運算子之前，才適用這項規則。
`INNER HASH JOIN`	只有在使用的鍵是資料欄，且未使用 join 限定詞時，才適用這項規則。
選擇性彙整	只有在資料欄掃描查詢的開頭進行 join 時，才會發生這種情況。

如要進一步瞭解哪些查詢最適合搭配資料欄引擎、查詢是否使用資料欄引擎，以及使用方式，請參閱「使用 EXPLAIN 驗證資料欄引擎的使用情形」。

如要在 AlloyDB Omni 執行個體中使用資料欄引擎，請按照下列高階步驟操作：

在執行個體上啟用引擎。

啟用引擎是一次性作業，需要重新啟動資料庫。
在資料欄商店中新增資料欄。

如要將資料欄新增至資料欄儲存庫，請使用下列其中一種方法：
- 使用自動分欄，分析工作負載並自動新增資料欄。
- 根據您對執行個體中資料庫工作負載的瞭解，手動新增資料欄。
您可以使用 g_columnar_relations 檢視畫面追蹤資料欄儲存庫中的內容，並在新增資料欄後，使用 EXPLAIN 陳述式驗證 SQL 查詢中的資料欄引擎用量。

如需使用資料欄引擎的詳細操作說明，請參閱「設定資料欄引擎」。

在資料欄儲存庫中新增資料欄時，可使用的資料類型和資料來源有一些限制。

資料欄引擎僅支援具有下列內建資料類型的資料欄：

如果嘗試手動將資料類型不受支援的資料欄新增至資料欄儲存庫，資料欄引擎會忽略這類嘗試。

資料欄引擎不支援具有下列屬性的資料表或 materialized view 做為資料來源：

如果對有索引的資料欄執行分析查詢，AlloyDB Omni 最佳化工具可能會選擇使用資料列儲存庫。
手動新增至資料欄儲存庫的資料欄不會自動移除。如要強制移除手動新增的資料欄，請在執行個體上使用 google_columnar_engine_drop。
自動分欄功能可能會根據查詢用量，動態新增及移除資料欄。
資料欄引擎不支援部分資料類型。如要查看支援的資料類型，請參閱「支援的資料類型」。
頻繁更新資料列會導致資料欄資料失效。如要驗證資料欄商店中的資料表或具體化檢視區塊，您可以降低更新頻率，或更頻繁地排定資料欄引擎重新整理作業。

您可以比較 g_columnar_relations 中的 invalid_block_count 和 total_block_count 和 total_block_count 欄，確認表格或檢視畫面是否受到影響。如果表格或檢視畫面經常或大量變更，invalid_block_count就會偏高。