了解 Cortex Search 服务的成本¶

成本类别¶

Cortex Search 服务会产生以下类型的成本：

本主题提供有关这些成本的信息，以及有效管理这些成本的建议。

管理索引成本¶

您可能会发现以下提示有助于管理 Cortex Search 服务的索引成本：

尽量减小仓库规模

除 LARGE 仓库外，大多数服务的索引性能都没有改善，许多服务只需要 MEDIUM 即可。构建索引所用的大部分计算时间都由文本嵌入函数使用，当它已经有足够的资源时，文本嵌入函数无法从更多内核或额外内存中受益。

当新鲜度不重要时暂停索引

当您不需要将文档中的更改立即传播到搜索服务时（即在一段时间内新鲜度不那么重要时），请 :doc:`暂停索引 </sql-reference/sql/alter-cortex-search>`（或增加目标延迟）。

根据业务需求设置目标延迟

并非每个搜索应用程序都需要实时索引。目标延迟过低可能会导致索引刷新频率超出必要的频率。例如，如果您的源数据每五分钟更新一次，但数据的使用者每小时仅查询一次搜索服务，则将目标延迟设置为一小时，而不是五分钟。

定义主键

在 Cortex Search Service 上定义主键可以显著降低索引的成本和延迟。具有主键的服务在底层数据发生变化时，可以利用优化的刷新路径，尤其是在自上次刷新以来的数据变更量较少且上次刷新发生在上一周内的情况下。有关定义主键的更多信息，请参阅 主键。

将更改捆绑在一起

There is a fixed component to the cost of an update, so fewer, bigger updates are less expensive than more frequent, smaller updates. Likewise, any change to any value within a row triggers the search column in that row to be embedded again, even if the data within that search column is unchanged, so it is better to accumulate all the changes to a row into a single update. For more information about vector embedding costs, see 向量嵌入.

尽量减少源数据的更改

源查询架构的任何更改都会导致服务的全面刷新，包括向量嵌入和索引。创建大型服务时，考虑添加额外的负载列以备将来使用，这样在需要添加列时无需更改架构即可触发完全刷新。额外列的成本很低。

小技巧

Materializing data in a table in the source query with a CREATE OR REPLACE command causes the service to fully refresh and embed all vectors again. It's better to update the source table incrementally (for example, with MERGE INTO). For more information about vector embedding costs, see 向量嵌入.

尽可能确保源查询简单

联接或其他复杂操作可能会增加索引成本（最好在 ETL 期间或在其他暂存区应用）。有关优化管道的更多信息，请参阅动态表最佳实践。

管理服务成本¶

您可能会发现以下提示有助于管理 Cortex Search 服务的服务成本：

当服务不提供查询时将其暂停

即使不提供查询，正在运行的搜索服务也会产生成本。:doc:`在不需要服务时 </sql-reference/sql/alter-cortex-search>`（例如在开发期间）暂停服务。恢复暂停的服务通常只需要几分钟。

观察成本¶

要详细了解您的 Cortex Search 服务成本，请使用以下 Account Usage 视图。

• CORTEX_SEARCH_DAILY_USAGE_HISTORY 视图 包含每项服务的 EMBED_TEXT 词元计算和服务 Credit 计算使用量的每日总计。Snowflake 还打算将来在此视图中提供虚拟仓库的使用情况。

• CORTEX_SEARCH_SERVING_USAGE_HISTORY 视图 包含每项服务的每小时服务 Credit。

Snowflake 打算将来在 Cortex Search 管理界面中提供这些信息。

估算成本¶