了解 Cortex Search 服务的成本¶

成本类别¶

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

类别	描述
虚拟仓库计算	Cortex Search 服务需要虚拟仓库来刷新服务：在基础对象初始化和刷新对其运行查询，包括编排文本嵌入作业和构建搜索索引。这些操作使用计算资源，而计算资源会消耗 Credit。如果在刷新期间未发现任何更改，则不会消耗虚拟仓库 Credit，因为没有新数据可以刷新。
EMBED_TEXT 词元计算	Cortex Search 服务会自动将 `ON` 参数指定的搜索列中的每个文本行嵌入向量空间中，以启用语义搜索，这会产生每个嵌入词元的 Credit 成本。这涉及调用 EMBED_TEXT_768 或 EMBED_TEXT_1024，将每个文档转换为一系列编码其含义的数字。每次插入或更新行时都会计算嵌入。嵌入是在源查询计算过程中递增处理的，因此只在添加或更改文档时才会产生嵌入成本。有关矢量嵌入成本的详细信息，请参阅向量嵌入。
提供计算服务	Cortex Search 服务使用多租户服务计算（独立于用户提供的虚拟仓库），建立低延迟、高吞吐量的服务。此组件的计算成本是按每月每 GB（GB/月）的未压缩索引数据收取的，其中索引数据是 Cortex Search 源查询中用户提供的数据，加上代表用户计算的向量嵌入。即使在给定时间段内没有提供任何查询，在服务可以响应查询的同时，您也会承担这些成本。有关每月每 GB 索引数据的 Cortex Search 服务 Credit 费率，请参阅 Snowflake 服务使用量表。
存储	Cortex Search 服务将源查询物化为存储在账户户中的表。此表将转换为针对低延迟服务进行优化的数据结构，也存储在账户中。表和中间数据结构的存储基于每 TB 的统一费率 (TB)。
云服务计算	Cortex Search 服务使用云服务计算，以识别底层基本对象的变化以及是否需要调用虚拟仓库。云服务计算成本受到限制，Snowflake 仅在每日云服务成本大于账户每日仓库成本的 10% 时才计费。

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

管理索引成本¶

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

尽量减小仓库规模: 除 LARGE 仓库外，大多数服务的索引性能都没有改善，许多服务只需要 MEDIUM 即可。构建索引所用的大部分计算时间都由文本嵌入函数使用，当它已经有足够的资源时，文本嵌入函数无法从更多内核或额外内存中受益。
当新鲜度不重要时暂停索引: 当您不需要将文档中的更改立即传播到搜索服务时（即在一段时间内新鲜度不那么重要时），请 :doc:`暂停索引 </sql-reference/sql/alter-cortex-search>`（或增加目标延迟）。
根据业务需求设置目标延迟: 并非每个搜索应用程序都需要实时索引。目标延迟过低可能会导致索引刷新频率超出必要的频率。例如，如果您的源数据每五分钟更新一次，但数据的使用者每小时仅查询一次搜索服务，则将目标延迟设置为一小时，而不是五分钟。
将更改捆绑在一起: 更新成本有一个固定的组成部分，因此，高频率、更小的更新相比，低频率、更大的更新的成本更低。同样，行中任何值的任何更改都会触发该行中重新嵌入的搜索列，即使该搜索列中的数据没有变化，因此最好将一行的所有更改累积到一次更新中。
尽量减少源数据的更改: 源查询架构的任何更改都会导致服务的全面刷新，包括向量嵌入和索引。创建大型服务时，考虑添加额外的负载列以备将来使用，这样在需要添加列时无需更改架构即可触发完全刷新。额外列的成本很低。

小技巧

使用 CREATE OR REPLACE 命令在源查询的表中物化数据，这样会导致服务完全刷新并重新嵌入所有向量。最好逐步更新源表（例如，使用 MERGE INTO）。
尽可能确保源查询简单: 联接或其他复杂操作可能会增加索引成本（最好在 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 管理界面中提供这些信息。

估算成本¶

EMBED_TEXT 词元计算¶

EMBED_TEXT 词元计算按每个文档搜索列中的文本词元收费，按所选嵌入模型的 Credit 率成本收费。此计算成本是针对插入或更新的每一行产生，包括服务初始化期间 ON 列中的每一行以及此后的每次插入或更新。有关每种嵌入模型的每词元成本的信息，请参阅 Cortex Search 嵌入模型：

例如，如果您在包含 1000 万行且每行有 500 个词元的源查询上创建服务，并且所选的嵌入模型每 100 万个词元产生 0.05 个 Credit，则您需要为初始刷新支付以下费用：

（每 100 万个词元 0.05 个 Credit）*（10,000,000 行）*（每行 500 个 Credit）/（1,000,000 个词元）

= 250 个 Credit

对于此后插入或更新的每一行，每 100 万个词元将产生 0.05 个 Credit 的费用。

小技巧

作为近似值，一个词元约等于一个英语单词的 3/4，或约 4 个字符。要获得每行词元的准确估计值，请将 COUNT_TOKENS 函数与实际数据的代表性样本一起使用。

提供计算服务¶

服务计算是按每月每 GB 的索引数据收取，其中索引数据是 Cortex Search 源查询中用户提供的数据，加上代表用户计算的向量嵌入。这是一项持续的成本，只要服务恢复服务状态，就会产生这种成本。该成本基于索引的行数、总索引数据的大小以及所选向量嵌入模型的维度。有关每个嵌入模型的维度的信息，请参阅 Cortex Search 嵌入模型：

例如，如果您的服务包含 1000 万行，所选嵌入模型的维度为 768，源查询中的每行约为 1,000 个字节（包括搜索列），并且索引数据每月每 GB 的 Credit 成本为 6.3，则您每月需要支付以下费用：

（每 GB 6.3 个 Credit）*（10,000,000 行）*（768 个维度 * 每个维度 4 字节 + 每行 1,000 字节）/（每行 1,000,000,000 字节）/（每 GB 1,000,000,000 字节）

= 每月 256.5 个 Credit

备注

无论列被指定为搜索列还是属性列，每行数据的大小都因用例而异，并且会随着服务索引的数据量（行数和列数）的增加而增加。

仓库计算¶

Cortex Search 服务的虚拟仓库计算成本可能会根据您的数据变化率、目标延迟和仓库大小而有所不同。通常，目标延迟值较低且基础数据变化率较高的 Cortex Search 服务将产生更高的仓库相关计算成本。

小技巧

要清楚地了解与您的 Cortex Search 管道相关的仓库成本，请使用专用仓库测试 Cortex Search，这样您就可以隔离因 Cortex Search 刷新而产生的虚拟仓库使用量。在建立成本基准后，您可以将 Cortex Search 服务移至共享仓库。

存储¶

Cortex Search 服务需要存储空间，以存储源查询的物化结果以及搜索索引。使用 CORTEX_SEARCH_DATA_SCAN 表函数将源查询物化到一个表中，然后检查该表的大小，从而估算存储数据的大小。

有关此存储如何产生成本的详细信息，请参阅了解存储成本。

云服务¶

当底层基础对象发生更改时，Cortex Search 服务使用云服务计算来触发刷新。这些成本可能会根据您的数据变化率、目标延迟和仓库大小而有所不同。对于变化率低的用例，Cortex Search 中变更跟踪的云服务成本往往较低。云服务计算成本受到限制，Snowflake 仅在每日云服务成本大于账户每日仓库成本的 10% 时才计费。