Die Kosten für Cortex Search Services verstehen¶

Kostenkategorien¶

Bei den Cortex Search Services fallen die folgenden Kostenarten an:

Kategorie	Beschreibung
Computing von virtuellen Warehouses	Ein Cortex Search Service benötigt ein virtuelles Warehouse, um den Service zu aktualisieren: um Abfragen gegen Basisobjekte durchzuführen, wenn diese initialisiert und aktualisiert werden, einschließlich der Orchestrierung von Texteinbettungsaufträgen und dem Aufbau des Suchindexes. Diese Operationen nutzen Computeressourcen, die Credits verbrauchen. Wenn bei einer Aktualisierung keine Änderungen festgestellt werden, werden keine Credits für das virtuelle Warehouse verbraucht, da es keine neuen Daten zu aktualisieren gibt.
EMBED_TEXT-Token berechnen	Ein Cortex Search Service bettet automatisch jede Textzeile in der im Parameter `ON` angegebenen Suchspalte in den Vektorraum ein, um eine semantische Suche zu ermöglichen, wobei pro eingebettetem Token Kosten von einem Credit anfallen. Dazu müssen Sie EMBED_TEXT_768 oder EMBED_TEXT_1024 aufrufen, um jedes Dokument in eine Reihe von Zahlen zu konvertieren, die seine Bedeutung kodieren. Die Einbettungen werden jedes Mal berechnet, wenn eine Zeile eingefügt oder aktualisiert wird. Die Einbettungen werden bei der Auswertung der Abfrage inkrementell verarbeitet, sodass die Einbettungskosten nur für hinzugefügte oder geänderte Dokumente anfallen. Weitere Informationen zu den Kosten der Vektoreinbettung finden Sie unter Vektoreinbettungen.
Rechenleistung	Ein Cortex Search Service nutzt mandantenfähige Rechenleistung, die von einem vom Benutzer bereitgestellten Warehouse getrennt ist, um einen Dienst mit niedriger Latenz und hohem Durchsatz einzurichten. Die Rechenkosten für diese Komponente fallen pro GB pro Monat (GB/mo) unkomprimierter indizierter Daten an, wobei indizierte Daten die vom Benutzer in der Cortex Search-Quellabfrage bereitgestellten Daten plus die im Namen des Benutzers berechneten Vektoreinbettungen sind. Diese Kosten fallen an, solange der Dienst zur Beantwortung von Abfragen zur Verfügung steht, auch wenn in einem bestimmten Zeitraum keine Abfragen gestellt werden. Die Credit-Rate für Cortex Search-Bereitstellung pro GB/mo indizierter Daten finden Sie in der Snowflake Service Consumption Table.
Speicher	Cortex Search Services materialisiert die Abfrage in einer Tabelle, die in Ihrem Konto gespeichert ist. Diese Tabelle wird in Datenstrukturen umgewandelt, die für eine niedrige Latenzzeit optimiert sind und ebenfalls in Ihrem Konto gespeichert werden. Der Speicher für die Tabelle und die dazwischen liegenden Strukturen basiert auf einer Pauschale pro Terabyte (TB).
Cloud Services Compute	Cortex Search Services verwenden Cloud Services-Berechnung um Änderungen in den zugrunde liegenden Basisobjekten zu erkennen und um festzustellen, ob das Warehouse aufgerufen werden muss. Die Computekosten für Clouddienste-Computing unterliegen der Einschränkung, dass Snowflake diese nur abrechnet, wenn die täglichen Kosten der Clouddienste mehr als 10 % der täglichen Warehouse-Kosten für das Konto betragen.

In diesem Thema finden Sie Informationen zu diesen Kosten sowie Empfehlungen für eine effektive Verwaltung dieser Kosten.

Verwaltung der Indizierungskosten¶

Die folgenden Tipps können Ihnen bei der Verwaltung der Indizierungskosten eines Cortex Search Service helfen:

Größe des Warehouses minimieren: Bei den meisten Diensten wird die Indizierungsleistung nicht über ein LARGE Warehouse hinaus verbessert und viele benötigen nur MEDIUM. Die meiste Rechenzeit bei der Erstellung eines Index wird von der Texteinbettungsfunktion verbraucht, die nicht von mehr Kernen oder zusätzlichem Speicher profitiert, wenn sie bereits über genügend Ressourcen verfügt.
Unterbrechen Sie die Indizierung, wenn die Aktualität nicht wichtig ist: Unterbrechen Sie die Indizierung (oder erhöhen Sie die Zielverzögerung), wenn Änderungen an Ihren Dokumenten nicht sofort an den Suchdienst weitergegeben werden müssen (d. h. wenn die Aktualität während eines bestimmten Zeitraums nicht so wichtig ist).
Legen Sie die Zielverzögerung entsprechend den geschäftlichen Anforderungen fest: Nicht jede Suchanwendung erfordert eine Indizierung in Echtzeit. Eine zu geringe Zielverzögerung kann dazu führen, dass Ihr Index häufiger als nötig aktualisiert wird. Wenn Ihre Quelldaten beispielsweise alle fünf Minuten aktualisiert werden, der Verbraucher der Daten den Suchdienst aber nur einmal pro Stunde abfragt, setzen Sie die Zielverzögerung auf eine Stunde, nicht auf fünf Minuten.
Änderungen bündeln: Die Kosten für eine Aktualisierung haben eine feste Komponente, so dass weniger und größere Aktualisierungen kostengünstiger sind als häufigere und kleinere Aktualisierungen. Ebenso löst jede Änderung eines Wertes in einer Zeile aus, dass die Suchspalte in dieser Zeile neu eingebettet wird, selbst wenn die Daten in dieser Suchspalte unverändert sind. Es ist also besser, alle Änderungen an einer Zeile in einer einzigen Aktualisierung zusammenzufassen.
Minimieren Sie Änderungen an den Quelldaten: Jede Änderung des Schemas der Quellabfrage führt zu einer vollständigen Aktualisierung des Dienstes, einschließlich der Vektoreinbettungen und Indizes. Wenn Sie einen großen Dienst erstellen, sollten Sie zusätzliche Nutzlast-Spalten für die spätere Verwendung einbeziehen, damit Sie nicht eine vollständige Aktualisierung durch Änderung des Schemas auslösen müssen, wenn Sie eine Spalte hinzufügen möchten. Die Kosten für die zusätzlichen Spalten sind gering.

Tipp

Die Materialisierung von Daten in einer Tabelle in der Quellabfrage mit dem Befehl CREATE OR REPLACE bewirkt, dass der Dienst alle Vektoren vollständig aktualisiert und neu einbettet. Es ist besser, die Quelltabelle schrittweise zu aktualisieren (zum Beispiel mit MERGE INTO).
Halten Sie die Quellabfrage so einfach wie möglich: Verknüpfungen oder andere komplexe Operationen können die Indizierungskosten in die Höhe treiben (und sollten besser während ETL oder in einem anderen Stagingbereich angewendet werden). Weitere Informationen zur Optimierung von Pipelines finden Sie in den Best Practices für dynamische Tabellen.

Verwaltung der Bereitstellungskosten¶

Die folgenden Tipps können Ihnen bei der Verwaltung der Bereitstellungskosten eines Cortex Search Service helfen:

Bereitstellung aussetzen, wenn keine Abfragen bedient werden: Ein laufender Suchdienst verursacht Kosten, auch wenn er keine Abfragen bedient. Schalten Sie den Dienst aus, wenn er nicht benötigt wird, z. B. während der Entwicklung. In der Regel dauert es nur wenige Minuten, bis ein ausgesetzter Dienst wieder aufgenommen wird.

Kosten beobachten¶

Um mehr über die Kosten Ihrer Cortex Search Services zu erfahren, nutzen Sie die folgenden Ansichten zu Account Usage.

Ansicht CORTEX_SEARCH_DAILY_USAGE_HISTORY enthält die täglichen Gesamtwerte der Nutzung von EMBED_TEXT-Tokenberechnung und Berechnung von Bereitstellungs-Credits pro Dienst. Snowflake beabsichtigt, in Zukunft auch die Nutzung von Warehouses in dieser Ansicht anzubieten.
Ansicht CORTEX_SEARCH_SERVING_USAGE_HISTORY beinhaltet stündliche Credits pro Dienst.

Snowflake beabsichtigt, diese Informationen in Zukunft in der Verwaltungs-Weboberfläche von Cortex Search zur Verfügung zu stellen.

Abschätzen der Kosten¶

EMBED_TEXT-Token berechnen¶

EMBED_TEXT-Tokenberechnung wird pro Token Text in der Suchspalte, pro Dokument berechnet, auf Kosten des Credit-Satzes des gewählten Einbettungsmodells abgerechnet. Diese Rechenkosten fallen für jede Zeile an, die eingefügt oder aktualisiert wird, einschließlich für jede Zeile in der Spalte ON während der Initialisierung des Dienstes und für jede Einfügung oder Aktualisierung danach. Informationen zu den Kosten pro Token der einzelnen Einbettungsmodelle finden Sie unter Cortex Search Einbettungsmodelle:

Wenn Sie beispielsweise einen Dienst für eine Quellabfrage mit 10 Millionen Zeilen mit jeweils 500 Token erstellen und das gewählte Einbettungsmodell 0,05 Credits pro 1 Million Token kostet, würden Sie für die erste Aktualisierung voraussichtlich Folgendes bezahlen:

(0,05 Credits pro 1 Million Token) * (10.000.000 Zeilen) * (500 Token pro Zeile) / (1.000.000 Token)

= 250 Credits

Für jede Zeile, die Sie danach einfügen oder aktualisieren, entstehen Ihnen Kosten in Höhe von 0,05 Credits pro 1 Million Token.

Tipp

Ein Token entspricht ungefähr 3/4 eines englischen Wortes, also etwa 4 Zeichen. Um eine genaue Schätzung der Token pro Zeile zu erhalten, verwenden Sie die Funktion COUNT_TOKENS mit einer repräsentativen Stichprobe Ihrer tatsächlichen Daten.

Rechenleistung¶

Bereitstellungsberechung wird pro Gigabyte-Monat indizierter Daten berechnet, wobei indizierte Daten die vom Benutzer bereitgestellten Daten in der Cortex Search-Quellabfrage plus die im Namen des Benutzers berechneten Vektoreinbettungen sind. Dabei handelt es sich um laufende Kosten, die anfallen, solange der Dienst wieder in Betrieb ist. Diese Kosten basieren auf der Anzahl der indizierten Zeilen, der Größe der gesamten indizierten Daten und der Dimensionalität des gewählten Vektoreinbettungsmodells. Informationen über die Dimensionalität der einzelnen Einbettungsmodelle finden Sie unter Cortex Search Einbettungsmodelle:

Wenn Sie beispielsweise einen Dienst mit 10 Millionen Zeilen haben, das ausgewählte Einbettungsmodell eine Dimension von 768 hat, jede Zeile in der Quellabfrage etwa 1.000 Byte groß ist (einschließlich der Suchspalte) und die Credit-Kosten pro GB/mo indizierter Daten 6,3 betragen, würden Sie mit den folgenden Kosten pro Monat rechnen:

(6,3 Credits pro GB) * (10.000.000 Zeilen) * (768 Dimensionen * 4 Bytes pro Dimension + 1.000 Bytes pro Zeile) / (1.000.000.000 Bytes pro GB)

= 256,5 Credits monatlich

Bemerkung

Die Größe der Daten pro Zeile variiert je nach Anwendungsfall und steigt mit der Menge der vom Dienst indizierten Daten (Anzahl der Zeilen und Spalten), unabhängig von der Bezeichnung einer Spalte als Such- oder Attributspalte.

Warehouse-Berechnung¶

Die Warehouse Rechenkosten für Cortex Search Services können je nach Änderungsrate Ihrer Daten, Zielverzögerung und Warehouse-Größe variieren. Im Allgemeinen verursachen Cortex Search Services mit niedrigeren Zielverzögerungswerten und höheren Änderungsraten der zugrunde liegenden Daten höhere Warehouse-bezogene Rechenkosten.

Tipp

Um ein klares Verständnis der Warehouse-Kosten im Zusammenhang mit Ihren Cortex Search-Pipelines zu erhalten, testen Sie Cortex Search mit dedizierten Warehouses, damit der Verbrauch des virtuellen Warehouses, der auf die Aktualisierungen von Cortex Search zurückzuführen ist, isoliert werden kann. Sie können Ihren Cortex Search Service in ein gemeinsames Warehouse verlagern, nachdem Sie eine Kostenbasis festgelegt haben.

Speicher¶

Cortex Search Services benötigen Speicherplatz, um die materialisierten Ergebnisse der Quellabfrage sowie den Suchindex zu speichern. Die Größe der gespeicherten Daten kann geschätzt werden, indem Sie die Quellabfrage mit der Tabellenfunktion CORTEX_SEARCH_DATA_SCAN in eine Tabelle materialisieren und dann die Größe dieser Tabelle untersuchen.

Ausführliche Informationen darüber, wie diese Speicherung Kosten verursacht, finden Sie unter Erläuterungen zu den Speicherkosten.

Clouddienste¶

Cortex Search Services verwenden Cloud Services-Berechnung, um Aktualisierungen auszulösen, wenn sich ein zugrunde liegendes Basisobjekt geändert hat. Diese Kosten können je nach der Änderungsrate Ihrer Daten, der Zielverzögerung und der Größe des Warehouse variieren. Die Kosten für Cloud-Services zur Änderungsverfolgung in Cortex Search sind bei Anwendungsfällen mit geringen Änderungsraten tendenziell niedriger. Die Computekosten für Clouddienste-Computing unterliegen der Einschränkung, dass Snowflake diese nur abrechnet, wenn die täglichen Kosten der Clouddienste mehr als 10 % der täglichen Warehouse-Kosten für das Konto betragen.