Kostenkontrolle von Snowflake Connector for SharePoint¶

Bemerkung

Der Snowflake Connector for SharePoint unterliegt den `Nutzungsbedingungen für Konnektoren<https://www.snowflake.com/legal/snowflake-connector-terms/>`_.

Wichtig

Vielen Dank für Ihr Interesse an Snowflake Connector für SharePoint. Wir konzentrieren uns momentan auf eine Lösung der nächsten Generation, die ein deutlich verbessertes Benutzererlebnis bieten wird. Daher ist die Veröffentlichung dieses Konnektors mit dem Status „Allgemeine Verfügbarkeit“ derzeit nicht teil unserer Produkt-Roadmap. Sie können diesen Konnektor weiterhin als Vorschau-Feature verwenden. Beachten Sie aber, dass die Unterstützung von zukünftigen Fehlerkorrekturen und Verbesserungen nicht garantiert ist. Die neue Lösung ist als Openflow-Konnektor für SharePoint verfügbar und umfasst bessere Performance, Anpassbarkeit und erweiterte Bereitstellungsoptionen.

Unter diesem Thema werden Best Practices für die Kostenkontrolle und die Ermittlung der optimalen Warehouse-Größe für den Snowflake Connector for SharePoint erörtert.

Ermitteln der Kosten des Konnektors¶

Wenn der Konnektor ein separates Konto nur für die Datenerfassung und Datenspeicherung verwendet und das Konto keine anderen Aktivitäten aufweist (wie z. B. die Ausführung von Abfragen durch Benutzer auf den erfassten Daten), können Sie die Gesamtkosten auf der Ebene des Kontos ablesen. Weitere Informationen dazu finden Sie unter Untersuchen der Gesamtkosten.

Wenn das Konto nicht nur dem Konnektor gewidmet ist oder Sie die Kosten noch genauer untersuchen müssen, sollten Sie die berechneten Kosten für die folgenden drei Komponenten getrennt analysieren:

Computekosten
Speicherkosten
`Kosten des Cortex Search Service `_
Datentransferkosten

Eine Einführung in diese drei Kostenbestandteile finden Sie unter Erläuterungen zu den Gesamtkosten.

Allgemeine Empfehlungen¶

Um die durch den Konnektor erzeugten Kosten zu erhalten, empfehlen wir Ihnen, ein separates Konto ausschließlich für die Verwendung des Konnektors einzurichten. Auf diese Weise können Sie den genauen Datentransfer verfolgen, der durch den Konnektor generiert wird.

Wenn Sie kein separates Konto für den Konnektor verwenden können, versuchen Sie Folgendes:

Erstellen Sie eine separate Datenbank für die Speicherung der erfassten Daten, um die Speicherkosten besser verfolgen zu können.
Weisen Sie ein Warehouse nur für den Konnektor zu, um die genauen Computekosten zu erhalten.
Verwenden Sie Objekt-Tags auf Datenbanken und ein Warehouse, um benutzerdefinierte Kostenberichte zu erstellen.

Computekosten¶

Wir empfehlen Ihnen, ein separates Warehouse nur für den Konnektor zu erstellen. Mit diesem Setup haben Sie die Möglichkeit, Ressourcenmonitore auf dem Warehouse zu erstellen. Sie können die Monitore verwenden, um E-Mail-Alerts zu versenden und das Warehouse zu unterbrechen, d. h. den Konnektor zu stoppen, wenn das festgelegte Credit-Kontingent überschritten wird. Der Konnektor wird automatisch wieder aktiviert, wenn das Credit-Kontingent erneuert wird. Beachten Sie, dass beim einem zu niedrig eingestellten Credit-Kontingent in Konfigurationen, in denen große Datenmengen aufgenommen werden, dazu führen kann, dass der Konnektor nicht alle Daten aufnimmt.

Weitere Informationen zum Prüfen der vom Warehouse verbrauchten Credits finden Sie unter Untersuchen der Computekosten. Sie können dem Warehouse auch Objekt-Tags zuweisen und die Tags dann zum Erstellen von Kostenberichten verwenden.

Wenn das vom Konnektor verwendete Warehouse auch von anderen Workflows genutzt wird, können Sie die Kosten nach Rollen aufteilen. Weitere Informationen zur Aufteilung der Nutzung nach Rollen finden Sie unter Zuordnen von Kosten. Fügen Sie die folgende WHERE-Klausel für die Ansicht QUERY_HISTORY hinzu:

warehouse_name = '<connector warehouse name>' AND role_name = 'APP_PRIMARY'

Copy

Die Abfrage liefert nur einen ungefähren Wert für die Kosten.

Bemerkung

Das Warehouse darf nur von genau einer systemeigenen Anwendung verwendet werden, andernfalls sind die Kosten verschiedener Anwendungen nicht trennbar, da jede systemeigene Anwendung denselben Rollennamen verwendet (APP_PRIMARY).

Kosten für die Dokumentenanalysefunktion¶

Hinweise zu Kosten im Zusammenhang mit der Dokumentenanalysefunktion finden Sie unter Hinweise zu Kosten.

Kosten des Cortex Search Service¶

Informationen zu den Kosten im Zusammenhang mit dem Cortex Search Service finden Sie unter Hinweise zu Kosten.

Speicherkosten¶

Der Snowflake Connector for SharePoint speichert Daten an zwei Stellen:

In der Konnektor-Datenbank, die aus dem Freigabeangebot erstellt wird und die den internen Status des Konnektors enthält.
In dem vom Benutzer angegebenen Schema, in dem die erfassten Daten gespeichert werden.

Außerdem wird Datenspeicher vom Snowflake-Feature Fail-safe verbraucht. Die Menge der gespeicherten Fail-safe-Daten hängt von den Tabellenaktualisierungen ab, die der Konnektor vornimmt. Die Datenmenge erhöht sich, wenn die von SharePoint erfassten Tabellenzeilen häufig aktualisiert werden oder die gesamte Tabelle neu geladen wird. In der Regel stabilisiert sich die Menge der Fail-safe-Daten sieben bis zehn Tage nach der Einrichtung des Konnektors (unter der Annahme, dass keine Reloads durchgeführt werden und der Strom an aufgenommenen Daten konstant ist).

Wenn Sie die Speichernutzung in Snowsight überprüfen möchten, empfehlen wir Ihnen, eine separate Datenbank zum Speichern der aufgenommenen Daten zu verwenden. Auf diese Weise können Sie die Grafiken für die Speichernutzung nach Objekt filtern, sodass die Nutzung nach einzelnen Datenbanken angezeigt wird. Sie können dies auch tun, indem Sie Ansicht DATABASE_STORAGE_USAGE_HISTORY abfragen und nach beiden vom Konnektor verwendeten Datenbanken filtern.

Wenn die Datenbank andere Schemas enthält, die nicht mit dem Konnektor in Beziehung stehen, können Sie die Speichernutzung eines bestimmten Schemas abfragen, das für die vom Konnektor aufgenommenen Daten bestimmt ist. Sie können die Informationen aus Ansicht TABLE_STORAGE_METRICS abrufen, sobald Sie nach Datenbank- und Schemanamen gefiltert und die Spalten mit Speichernutzung aggregiert haben.

Datentransferkosten¶

Der Konnektor verwendet externe Zugriff, um Daten von SharePoint abzurufen. Snowflake erhebt nur Gebühren für den vom Konnektor generierten Datenverkehr, basierend auf der Größe der Anforderungen vom Konnektor an SharePoint. Die Antworten von SharePoint verursachen keine Kosten auf Seiten von Snowflake.

Informationen zur Datentransfernutzung sind nur in aggregierter Form für alle Integrationen für den externen Zugriff auf Kontoebene verfügbar. Um auf die Anzahl der übertragenen Bytes zuzugreifen, verwenden Sie Ansicht DATA_TRANSFER_HISTORY und filtern nach dem Transfertyp EXTERNAL_ACCESS.

Kosten für Healthcheck-Aufgabe¶

Der Konnektor erstellt eine serverlose Aufgabe, die regelmäßig den Healthcheck-Status Ihrer App-Instanz überprüft und nur das zusammengefasste Ergebnis (ob Instanz ok ist oder nicht) an Snowflake sendet. Die Aufgabe wird nach Ausführung des Installationsassistenten (oder durch Aufruf von FINALIZE_CONNECTOR_CONFIGURATION in Arbeitsblättern) erstellt. Sie wird im Hintergrund ausgeführt und verursacht feste Kosten von bis zu 0,5 Credits/Tag, auch wenn keinSharePoint-Ordner für die Replikation aktiviert ist.

Die Aufgabe kann nicht manuell gestoppt oder gelöscht werden. Um diese Kosten zu reduzieren, können Sie jedoch die Prozedur PAUSE_CONNECTOR aufrufen, die die Aufgabe deaktiviert und keine Kosten verursacht, wenn der Konnektor nicht benutzt wird.

Kostenoptimierung¶

Bestimmen der optimalen Warehouse-Größe für die Konnektor-Instanz¶

Um die optimale Warehouse-Größe für den Konnektor zu finden, müssen Sie die Faktoren berücksichtigen, die sich auf die Performance des Konnektors auswirken, z. B. die Größe der Instanz, die Anzahl der aktivierten Tabellen und der Zeitplan für das Synchronisieren der einzelnen Tabellen. Wenn zum Beispiel nur einige wenige Tabellen aktiviert sind, profitiert der Konnektor möglicherweise nicht von einer erhöhten Parallelisierung.

Wir empfehlen Ihnen, eine Reihe von messbaren Anforderungen zu definieren, wie z. B. Zeitintervalle, in denen alle Tabellen synchronisiert werden sollten, und dann die kleinste Warehouse-Größe zu wählen, die diese Anforderungen erfüllt. Für große Datenmengen mit Dutzenden von synchronisierten Tabellen wird standardmäßig ein Warehouse der Größe „Large“ empfohlen. Wenn Sie hingegen nur den Konnektor ausprobieren und eine einzelne Tabelle für die Datenaufnahme aktivieren möchten, sollte ein Warehouse der Größe „X-Small“ ausreichen. Um herauszufinden, ob Sie das Warehouse verkleinern können, lesen Sie Überwachen des Warehouse-Workloads.