Externen Tabellencache verwenden, um die Performance für externe Tabellen zu verbessern

Mit dem externen Tabellencache in Oracle Autonomous AI Database können Sie Daten, auf die häufig zugegriffen wird, aus externen Tabellen in der Datenbank cachen.

Hinweis

Externer Tabellencache wird nur für Oracle AI Database 26ai unterstützt.

Externen Tabellencache in autonomer KI-Datenbank

Ein externer Tabellencache ist ein Speicherbereich in Ihrer autonomen KI-Datenbank, in dem die Daten aus einer externen Tabelle gespeichert werden.

Externe Daten werden nicht von der Datenbank verwaltet. Sie können jedoch die externen Tabellen verwenden, um Daten außerhalb der Datenbank abzufragen. Abfragen für externe Tabellen sind nicht so schnell wie Abfragen für Datenbanktabellen, da sie jedes Mal, wenn Sie auf die Daten zugreifen, aus den externen Dateien abgerufen werden müssen, die im Objektspeicher gespeichert sind.

Mit dem externen Tabellencache können Sie häufig besuchte externe Daten lokal speichern. Wenn Sie den Cache verwenden, können Abfragen externer Tabellen Daten direkt aus der autonomen KI-Datenbank abrufen, wodurch sie wesentlich schneller werden. Sie müssen vorhandene SQL-Anweisungen oder Workflows nicht ändern, um von einem schnelleren Zugriff zu profitieren, da dieser Caching-Mechanismus für Anwendungen vollständig transparent ist. Sie können einen externen Tabellencache für partitionierte und nicht partitionierte externe Tabellen erstellen, die in Parquet-, ORC-, AVRO-, CSV- und Iceberg-Tabellen erstellt wurden.

Die Verwendung des Cache für externe Tabellen bietet folgende Vorteile:
  • Verbesserte Performance für Analysen: Abfragen sind für Ihre häufig aufgerufenen externen Daten um ein Vielfaches schneller – ideal für Dashboards, Berichte und Analysetools, die regelmäßig auf dieselben Daten zugreifen.

  • 100% transparent: Der Caching-Mechanismus ist vollständig transparent. Anwendungen können von einer verbesserten Geschwindigkeit profitieren, ohne dass Änderungen an ihren Abfragen, Dashboards oder Anwendungen erforderlich sind.

  • Niedrigere Cloud-Kosten: In einer Multi-Cloud-Anwendung reduziert das Caching den Bedarf an wiederholten externen Datenabrufen aus dem Remotespeicher und reduziert so die Gebühren für den Datenausgang, die mit dem Zugriff auf Daten über Regionen oder Clouds verbunden sind.

  • Fein granuliertes, flexibles Caching-Steuerelement: Sie können alle Dateien, einen Prozentsatz der Dateien oder nur die zuletzt aktualisierten Daten cachen. Sie können die gecachten Daten, die Cachegröße und die Speicherlimits für externe Tabellencaches steuern.

Externe Tabellencaches in der Datenbank können automatisch oder über richtlinienbasierte Einstellungen verwaltet werden. Mit Policy-basiertem Cache-Management können Sie einfache Policys definieren, mit denen Dateien aus dem Cache gefüllt, aktualisiert und als veraltet eingestuft werden. So erhalten Sie genaue Kontrolle über Cache-Inhalte und -Wartung.

Weitere Informationen finden Sie unter Externe Daten abfragen.

Schnellstart mit externen Tabellencaches

Enthält Beispiele für die ersten Schritte beim Erstellen und Auffüllen externer Tabellencaches.

Erstellen Sie einen Policy-basierten externen Tabellencache für das SALES-Schema.

Wenn Sie einen Cache erstellen, ist er zunächst leer und für die Population aktiviert. Die Cachegröße erhöht sich jedes Mal, wenn eine Datei hinzugefügt wird, abhängig von den definierten Speicherplatz-Quota-Grenzwerten für das Schema, bis sie die zugewiesenen Grenzwerte erreicht.

Verwenden Sie DBMS_EXT_TABLE_CACHE.CREATE_CACHE, um einen externen Tabellencache für Ihr Schema zu erstellen. Beispiel:
BEGIN
    DBMS_EXT_TABLE_CACHE.CREATE_CACHE (      
      owner          => 'SALES',
      table_name     => 'STORE_SALES',
      partition_type => 'PATH');                                                                 
END;                                                                 
/

Dadurch wird ein Cache für die Tabelle STORE_SALES im Schema SALES erstellt. Die STORE_SALES ist eine externe Tabelle, die auf im Objektspeicher gespeicherte Daten verweist.

Der Parameter owner gibt den Schemanamen an. In diesem Beispiel wird ein externer Tabellencache für den Benutzer SALES erstellt.

partition_type steuert, wie der Cache aufgeteilt wird. Bei 'PATH' wird der Cache nach dem Ordnerpfad jeder Quelldatei partitioniert. FILE$PATH ist eine ausgeblendete Spalte, in der dieser Ordnerpfad (alles vor dem Dateinamen) gespeichert wird.

Beispiel: Wenn eine Datei …/n/<ns>/b/<bucket>/o/sales/2024/09/data1.parquet ist, wird FILE$PATH = 'sales/2024/09/' (der Ordner) verwendet.

Wenn Sie zum ersten Mal einen externen Tabellencache erstellen, werden dessen Metadaten im Data Dictionary gespeichert. Für die Cachedaten wird jedoch kein Speicherplatz zugewiesen. Sie können die Ansicht USER_EXTERNAL_TAB_CACHES abfragen, um die Cacheerstellung zu prüfen. Beispiel:
SELECT external_table_name, cached, disabled 
  FROM user_external_tab_caches;

Verwenden Sie die Prozedur DBMS_EXT_TABLE_CACHE.VALIDATE, um einen externen Tabellencache zu validieren. Ein Fehler wird gemeldet, wenn die referenzierte externe Tabelle nicht in der Datenbank gefunden wurde. Beispiel:
BEGIN
  DBMS_EXT_TABLE_CACHE.VALIDATE (
    owner         => 'SALES', 
    table_name    => 'STORE_SALES',
    raise_errors  => TRUE);
END;
/

Führen Sie DBMS_EXT_TABLE_CACHE.ADD_TABLE aus, um eine gesamte Tabelle in den Cache zu füllen. Beispiel:

BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_TABLE (
    owner         => 'SALES', 
    table_name    => 'STORE_SALES');
END;
/

In diesem Beispiel wird versucht, die Tabelle STORE_SALES in den Cache zu füllen.

Automatisch verwaltete externe Tabellencaches erstellen

Standardmäßig ist das automatische Caching deaktiviert. AUTO-Caches werden automatisch erstellt, wenn Sie das automatische Caching aktivieren.

Führen Sie DBMS_CACHE.SET_USER_PROPERTY aus, um das automatische Caching der externen Tabelle für das HR-Schema zu aktivieren. Beispiel:
BEGIN
 DBMS_CACHE.SET_USER_PROPERTY (
 property_name      => 'max_cache_size', 
 property_value_num => 10737418240); 
END; 
/

In diesem Beispiel wird das automatische Caching für das HR-Schema aktiviert, und der Parameter MAX_CACHE_SIZE wird auf 10737418240 Byte gesetzt. Dabei wird eine maximale Cachezuweisung von 10 GB für externe Tabellen im HR-Schema angegeben. Außerdem werden die erforderlichen Caches für externe Tabellen erstellt und gefüllt.

Beispiel für die Aktivierung des automatischen Caches für alle Datenbankbenutzer:
BEGIN
 DBMS_CACHE.SET_GLOBAL_PROPERTY (
 property_name       => 'max_cache_percent',
 property_value_num  => 20);
END; 
/

Verwenden Sie die globale Eigenschaft MAX_CACHE_PERCENT, um das Standardcachelimit für alle Benutzer festzulegen. Wenn Sie MAX_CACHE_PERCENT auf 20 setzen, kann das automatische Caching externer Tabellen bis zu 20% der zugewiesenen Tablespace-Quota jedes Benutzers belegen (Beispiel: Ein Benutzer mit einer Quota von 100 GB kann bis zu 20 GB cachen, ein Benutzer mit einer Quota von 10 GB bis zu 2 GB). Diese globale Einstellung gilt nur für das automatische Caching und gilt pro Benutzer und nicht für alle Benutzer. Sie können diesen Standardwert für einzelne Benutzer außer Kraft setzen, indem Sie die Prozedur DBMS_CACHE.SET_USER_PROPERTY ausführen.

Führen Sie die folgende Abfrage aus, um zu prüfen, ob die Caches erstellt und aktiviert wurden:
SELECT external_table_name, cached, auto
  FROM all_external_tab_caches;

Die AUTO-Caches werden automatisch nach einem regulären Zeitplan aktualisiert. Optional können Sie auch die Prozedur DBMS_CACHE.REFRESH verwenden, um eine On-Demand-Aktualisierung für alle Caches eines angegebenen Benutzers auszuführen. Beispiel:
BEGIN
    DBMS_CACHE.REFRESH (      
      owner          => 'HR',
      refresh_type   => 'ALL');                                                                 
END;                                                                 
/

In diesem Beispiel werden vorhandene Caches aktualisiert und bei Bedarf neue externe Tabellencaches für das Schema HR erstellt. Die Eigenschaft refresh_type gibt den Geltungsbereich an, in dem die Aktualisierung ausgeführt wird.

Wählen Sie Ihre Caching-Voreinstellung

Beschreibt, wie Sie die entsprechende Caching-Voreinstellung auswählen, einschließlich Cacheverhalten und Größenzuweisung für externe Tabellen.

Der externe Tabellencache wird als Schemaobjekt in der Datenbank erstellt. Dabei wird physischer Speicherplatz zugewiesen, ähnlich wie Tabellen und Indizes in Datendateien gespeichert werden. Wenn Sie einen externen Tabellencache erstellen, wird eine neue Tabelle in Ihrem Schema erstellt, und alle für Ihr Schema festgelegten Speicherplatz-Quota-Grenzwerte gelten auch für den externen Tabellencache.

Die Cache-Verwaltung für externe Tabellen kann zwei Typen aufweisen:
  • Policy-basierte Cacheverwaltung

    • Sie definieren explizit, wie Caches erstellt, gefüllt, aktualisiert und eingestellt werden.

    • Bietet feingranulierte Kontrolle über Cache-Inhalte und -Lebenszyklus.

    • Geeignet, wenn vorhersehbares oder angepasstes Caching-Verhalten erforderlich ist.

  • Automatische Cache-Verwaltung

    • Die Datenbank erstellt, füllt, aktualisiert und löscht automatisch Caches.

    • Aktionen werden durch externe Tabellenabfragemuster und Workload-Nutzung gesteuert.

    • Ideal für Umgebungen, in denen sich das Caching-Verhalten ohne manuelle Eingriffe dynamisch anpassen muss.

Voraussetzungen zum Erstellen des Cache für externe Tabellen

Listet die Voraussetzungen für die Erstellung des Cache für externe Tabellen auf.

  • Sie können nur einen externen Tabellencache in Ihrem eigenen Schema und für die externen Tabellen erstellen, deren Eigentümer Sie sind.

  • Sie müssen eine geeignete Speicherplatz-Quota für Ihr Schema zugewiesen haben, um sicherzustellen, dass genügend Speicherkapazität für die Cachedaten vorhanden ist.

  • Sie benötigen Zugangsdaten für den Zugriff auf externe Tabellendateien, die im Objektspeicher gespeichert sind. Sie müssen keine Zugangsdaten erstellen, wenn Sie Resource Principal-Zugangsdaten für den Zugriff auf den Oracle Cloud Infrastructure-Objektspeicher aktivieren.

Policy-basiertes Caching für externe Tabellen verwenden

Beschreibt, wie Sie Policy-basiertes Caching für externe Tabellen in Autonomous AI Database verwenden.

Policy-basiertes Caching bietet Ihnen explizite Kontrolle darüber, wie externe Daten in der Datenbank gecacht, aktualisiert und verwaltet werden. In diesem Ansatz definieren Sie Caching-Policys und verwalten den gesamten Cachelebenszyklus mit PL/SQL-Prozeduren, die im Package DBMS_EXT_TABLE_CACHE verfügbar sind. Mit diesen Prozeduren können Sie verschiedene Cache-Lebenszyklusvorgänge explizit ausführen, wie das Erstellen und Füllen von Caches, das Löschen von Dateien aus dem Cache und das Aktivieren oder Deaktivieren der Caches.

Mit diesem Ansatz können Sie das Cache-Verhalten fein granuliert steuern. Sie können angeben, welche externen Tabellendateien oder welcher Prozentsatz der Daten einer externen Tabelle gecacht werden sollen, um eine optimale Nutzung des Cachespeichers basierend auf den Workload-Anforderungen sicherzustellen. Mit Prozeduren wie ADD_BY_LIKE und ADD_LATEST_FILES können Sie Dateien basierend auf verschiedenen Parametern filtern und in den Cache füllen, wie z.B. Dateinamensmustern, Änderungszeiten oder Kriterien zur Datenaktualität. Ebenso können Sie Prozeduren wie CLEAR, RETIRE_FILES oder DROP_BY_LIKE verwenden, um Dateien aus dem Cache zu entfernen.

Da Policy-basierte Caches nicht von einem automatischen Löschalgorithmus verwaltet werden, lässt die Datenbank sie nicht automatisch unter Speicherplatzdruck fallen. Wenn der Cachespeicher nicht mehr verfügbar ist, können neue Dateien möglicherweise erst aufgefüllt werden, wenn zusätzlicher Speicherplatz freigegeben wird. Dieser Ansatz bietet mehr Flexibilität und ist ideal für Workloads geeignet, bei denen Sie mehr Kontrolle über Cacheinhalte benötigen.

Weitere Informationen finden Sie unter DBMS_EXT_TABLE_CACHE Package.

Im folgenden Flussdiagramm werden die Schritte zum Verwalten Policy-basierter Caches mit dem Package DBMS_EXT_TABLE_CACHE beschrieben. Es umfasst wichtige Schritte wie die Erstellung von Caches, die Auffüllung und das Löschen.


Beschreibung von adb_external_table_cache.png folgt
Beschreibung der Abbildung adb_external_table_cache.png

Themen

Dateien in externen Tabellencache auffüllen

Beschreibt, wie der zuvor erstellte Policy-basierte Cache gefüllt wird.

Nachdem Sie einen Cache erstellt haben, können Sie Dateien in den Cache füllen. Beim Auffüllen von Dateien wird der Inhalt der angegebenen externen Tabellendateien in den Cache geladen. Sie können wählen, ob Sie alle Dateien aus einer Tabelle oder einen bestimmten Prozentsatz der Tabelle auffüllen oder eine Filterbedingung angeben, um die Dateien zu begrenzen, die Sie auffüllen möchten. Beispiel: Sie können die Dateien nach ihren Namen oder einem Datumsbereich filtern.

Hinweis

  • Je nachdem, welche Speicherplatz-Quota dem Schema zugewiesen ist, versucht Oracle, Dateien in den Cache zu füllen. Wenn der zugewiesene Quota-Grenzwert erreicht ist, füllt Oracle keine Dateien mehr auf, es sei denn, der erforderliche Speicherplatz wird zugewiesen.

  • Der Cache der externen Tabelle wird nicht automatisch aktualisiert. Um den Cache zu aktualisieren, wenn eine Datei im Objektspeicher geändert wird, müssen Sie die Datei erneut auffüllen.

  • Wenn eine Datei aus dem Objektspeicher gelöscht wird, werden die entsprechenden gecachten Daten sofort ungültig und können nicht abgerufen werden.

Tabelle zu externem Tabellencache hinzufügen

Verwenden Sie DBMS_EXT_TABLE_CACHE.ADD_TABLE, um eine gesamte Tabelle oder einen bestimmten Prozentsatz der externen Tabelle in den Cache zu füllen.

Beispiele

BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_TABLE (
    owner         => 'SALES', 
    table_name    => 'STORE_SALES');
END;
/

In diesem Beispiel wird versucht, die Tabelle STORE_SALES in den Cache aufzufüllen. Dabei werden alle vorhandenen Dateien übersprungen, die bereits aufgefüllt wurden.

BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_TABLE (
    owner         => 'SALES', 
    table_name    => 'STORE_SALES',
    percent_files => 80);
END;
/

In diesem Beispiel wird versucht, 80% der Tabelle STORE_SALES in den Cache aufzufüllen. Alle vorhandenen Dateien, die bereits aufgefüllt wurden, werden übersprungen.

Der Parameter percent_files ist optional. Wenn Sie diesen Parameter nicht angeben, wird die gesamte Tabelle in den Cache gefüllt.

Weitere Informationen finden Sie unter Prozedur ADD_TABLE.

Dateien zu externem Tabellencache hinzufügen

Mit den folgenden Verfahren können Sie eine oder mehrere Dateien zum externen Tabellencache hinzufügen:
  • ADD_FILE: Zum Hinzufügen einer einzelnen Datei in den Cache.

  • ADD_BY_LIKE: Zum Hinzufügen einer oder mehrerer angegebener Dateien basierend auf den angegebenen Pfadfiltern.

  • ADD_LATEST_FILES: Zum Hinzufügen einer oder mehrerer Dateien basierend auf dem angegebenen Zeitintervall.

Beispiele

Verwenden Sie die Prozedur DBMS_EXT_TABLE_CACHE.ADD_FILE, um eine einzelne Datei in den externen Tabellencache zu füllen. Beispiel:
BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_FILE (
    owner        => 'SALES', 
    table_name   => 'STORE_SALES',
    file_url     => 'https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/salesdata.parquet'
);
END;
/

In diesem Beispiel werden Daten aus der Datei salesdata.parquet in den Cache gefüllt.

In diesem Beispiel wird das Auffüllen der Datei in den Cache übersprungen, wenn die angegebene Datei im Cache vorhanden ist und seit dem letzten Zwischenspeichern der Datei nicht mehr geändert wurde.

Weitere Informationen finden Sie unter Prozedur ADD_FILE.

Verwenden Sie die Prozedur DBMS_EXT_TABLE_CACHE.ADD_BY_LIKE, um eine oder mehrere Dateien in den externen Tabellencache zu füllen. Beispiel:
BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_BY_LIKE (
    owner        => 'SALES', 
    table_name   => 'STORE_SALES',
    path_filters => '["https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/sales%.parquet",
                      "https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/customer%.parquet"]'
);
END;
/

In diesem Beispiel werden alle Dateien mit Namen gefüllt, die mit sales oder customer beginnen, während Dateien ausgeschlossen werden, die bereits aufgefüllt wurden.

BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_BY_LIKE (
    owner        => 'SALES', 
    table_name   => 'STORE_SALES',
    path_filters => '["https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/sales#_data1.parquet",
                      "https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/sales#_data2.parquet"]',
    esc_char     => '#',
    force        => TRUE);
END;
/

In diesem Beispiel werden die Dateien sales_data1.parquet und sales_data2.parquet in den Cache gefüllt.

In diesem Beispiel wird das Zeichen "#" als Escapezeichen definiert. Das Zeichen "_" nach "#" wird als literaler Unterstrich und nicht als Platzhalter behandelt, der mit einem einzelnen Zeichen übereinstimmt.

Weitere Informationen finden Sie unter Prozedur ADD_BY_LIKE.

Verwenden Sie die Prozedur DBMS_EXT_TABLE_CACHE.ADD_LATEST_FILES, um eine oder mehrere Dateien basierend auf dem letzten Änderungsdatum in den externen Tabellencache zu füllen. Beispiel:
BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_LATEST_FILES (
    owner        => 'SALES', 
    table_name   => 'STORE_SALES',
    since        => INTERVAL '7' DAY,
    max_files    => 5,
    force        => TRUE);
END;
/

Der Parameter since gibt das Zeitintervall an. Nur Dateien, die innerhalb der letzten sieben (7) Tage geändert wurden, können in den Cache aufgefüllt werden.

Der Parameter max_files begrenzt die Anzahl der Dateien, die in den Cache aufgefüllt werden können. In diesem Beispiel werden nur fünf (5) Dateien aufgefüllt.

Der Parameter force erzwingt, dass die angegebenen Dateien im Cache überschrieben werden, selbst wenn die Dateien nicht geändert wurden.

Weitere Informationen finden Sie unter Prozedur ADD_LATEST_FILES.

Fragen Sie die folgenden Data Dictionary Views ab, um die im Cache der externen Tabelle gecachten Dateien aufzulisten:

Dateien aus externem Tabellencache löschen

Zeigt Beispiele zum Löschen von Dateien aus dem externen Tabellencache.

Sie können alle Dateien aus dem Cache entfernen oder Filterbedingungen angeben, um eine oder mehrere Dateien aus dem Cache zu löschen. Beispiel: Sie können die Dateien nach ihrem Namen oder basierend auf einem bestimmten Zeitintervall filtern.

Cache für externe Tabelle löschen

Verwenden Sie DBMS_EXT_TABLE_CACHE.CLEAR, um alle Dateien aus dem externen Tabellencache zu löschen. Beispiel:

BEGIN
  DBMS_EXT_TABLE_CACHE.CLEAR (
    owner         => 'SALES', 
    table_name    => 'STORE_SALES');
END;
/

In diesem Beispiel werden alle Dateien aus dem STORE_SALES-Cache gelöscht, und der gesamte Speicherplatz, der von den entfernten Dateien belegt wird, wird aufgehoben.

Weitere Informationen finden Sie unter CLEAR-Prozedur.

Dateien aus externem Tabellencache löschen

Mit den folgenden Verfahren können Sie eine oder mehrere Dateien aus dem externen Tabellencache löschen:
  • DROP_FILE: zum Löschen einer einzelnen Datei aus dem Cache.

  • DROP_BY_LIKE: Zum Löschen einer oder mehrerer Dateien aus dem Cache basierend auf den angegebenen Pfadfiltern.

  • RETIRE_FILES: Zum Löschen einer oder mehrerer Dateien aus dem Cache basierend auf dem angegebenen Intervall.

Beispiele

Verwenden Sie DBMS_EXT_TABLE_CACHE.DROP_FILE, um eine Datei aus dem externen Tabellencache zu löschen. Beispiel:

BEGIN
  DBMS_EXT_TABLE_CACHE.DROP_FILE (
    owner        => 'SALES', 
    table_name   => 'STORE_SALES',
    file_url     => 'https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/salesdata.parquet'
);
END;
/

In diesem Beispiel wird die Datei salesdata.parquet aus dem Cache gelöscht, und der gesamte Speicherplatz, der von der entfernten Datei belegt wird, wird aufgehoben.

Weitere Informationen finden Sie unter Prozedur DROP_FILE.

Verwenden Sie DBMS_EXT_TABLE_CACHE.DROP_BY_LIKE, um eine oder mehrere Dateien basierend auf dem Parameter path_filters zu löschen. Beispiel:

BEGIN
  DBMS_EXT_TABLE_CACHE.DROP_BY_LIKE (
    owner        => 'SALES', 
    table_name   => 'STORE_SALES',
    path_filters => '["https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/salesdata.parquet",
                      "https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/salesdata1.parquet"]'
);
END;
/

In diesem Beispiel werden die Dateien salesdata.parquet und salesdata1.parquet aus dem Cache gelöscht, und der gesamte Speicherplatz, der von den entfernten Dateien belegt wird, wird aufgehoben.

BEGIN
  DBMS_EXT_TABLE_CACHE.DROP_BY_LIKE (
    owner        => 'SALES', 
    table_name   => 'STORE_SALES',
    path_filters => '["https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/sales#_data1.parquet",
                      "https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/sales#_data2.parquet"]'
);
END;
/

In diesem Beispiel werden die Dateien sales#_data1 und sales#_data2 aus dem Cache gelöscht, und der gesamte Speicherplatz, der von den entfernten Dateien belegt wird, wird aufgehoben.

In diesem Beispiel wird das Zeichen "#" als Escapezeichen definiert. Das Zeichen "_" nach "#" wird als literaler Unterstrich und nicht als Platzhalter behandelt, der mit einem einzelnen Zeichen übereinstimmt.

Weitere Informationen finden Sie unter Prozedur DROP_BY_LIKE.

Verwenden Sie DBMS_EXT_TABLE_CACHE.RETIRE_FILES, um eine oder mehrere Dateien basierend auf dem angegebenen Intervall zu löschen. Beispiel:

BEGIN
 DBMS_EXT_TABLE_CACHE.RETIRE_FILES (
    owner        => 'SALES', 
    table_name   => 'STORE_SALES',
    before       => INTERVAL '30' DAY);
END;
/

In diesem Beispiel werden Dateien, die älter als dreißig (30) Tage sind, aus dem Cache gelöscht und der gesamte von den entfernten Dateien belegte Speicherplatz freigegeben.

Weitere Informationen finden Sie unter Prozedur RETIRE_FILES.

In den obigen Beispielen werden eine oder mehrere Dateien aus dem Cache entfernt, während der Cache beibehalten wird. Sie können Dateien bei Bedarf erneut in den Cache laden. Weitere Informationen finden Sie unter Dateien in externen Tabellencache füllen.

Externen Tabellencache deaktivieren und aktivieren

Zeigt Beispiele zum Deaktivieren und Aktivieren des Cache für externe Tabellen.

Führen Sie DBMS_EXT_TABLE_CACHE.DISABLE aus, um den externen Tabellencache aus der Datenbank zu deaktivieren. Wenn Sie einen Cache deaktivieren, werden keine Daten aus dem Cache gelöscht. Stattdessen wird der Cache als DISABLED gekennzeichnet, und der Optimizer kann den Cache nicht für Query Rewrites verwenden.

Beispiel

BEGIN
    DBMS_EXT_TABLE_CACHE.DISABLE (      
      owner          => 'SALES',
      table_name     => 'STORE_SALES');                                                                 
END;                                                                 
/

In diesem Beispiel wird der STORE_SALES-Cache deaktiviert.

Weitere Informationen finden Sie unter DISABLE-Prozedur.

Nachdem Sie einen externen Tabellencache deaktiviert haben, aktivieren Sie den Cache mit DBMS_EXT_TABLE_CACHE.ENABLE.

Beispiel:
BEGIN
  DBMS_EXT_TABLE_CACHE.ENABLE (
    owner        => 'SALES', 
    table_name   => 'STORE_SALES'
 );
END;
/

In diesem Beispiel wird der STORE_SALES-Cache aktiviert.

Weitere Informationen finden Sie unter ENABLE - Prozedur.

Cache für externe Tabelle löschen

Zeigt ein Beispiel zum Löschen des Cache für externe Tabellen.

Führen Sie DBMS_EXT_TABLE_CACHE.DROP_CACHE aus, um einen externen Tabellencache zu löschen. Die Prozedur DBMS_EXT_TABLE_CACHE.DROP_CACHE entfernt den angegebenen externen Tabellencache aus der Datenbank und gibt den mit dem Cache verknüpften Speicherplatz frei.

Beispiel:

BEGIN
    DBMS_EXT_TABLE_CACHE.DROP_CACHE (      
      owner          => 'SALES',
      table_name     => 'STORE_SALES');                                                             
END;                                                                 
/

In diesem Beispiel wird der STORE_SALES-Cache aus dem Schema SALES gelöscht.

Wenn Sie einen Cache löschen, werden seine Metadaten aus dem Data Dictionary entfernt, und alle gecachten Daten werden gelöscht.

Weitere Informationen finden Sie unter Prozedur DROP_CACHE.

Fragen Sie die Ansicht USER_EXTERNAL_TAB_CACHES ab, um zu prüfen, ob der Cache gelöscht wurde. Beispiel:
SELECT external_table_name, cached
  FROM user_external_tab_caches;

Weitere Informationen finden Sie unter Views DBA_EXTERNAL_TAB_CACHES und USER_EXTERNAL_TAB_CACHES.

Optionale Größenvoreinstellungen für Policy-basierte Caches festlegen

Beschreibt, wie Sie Größenvoreinstellungen für Policy-basierte externe Tabellencaches in Autonomous AI Database festlegen.

Standardmäßig ist der externe Tabellencache für einen Benutzer deaktiviert. Um den externen Tabellencache zu aktivieren und zu erstellen, verwenden Sie die Prozedur DBMS_EXT_TABLE_CACHE.CREATE_CACHE. Der Cache wird in Ihrem Standardschema erstellt und erbt alle für Ihr Schema definierten Speicherplatz-Quota-Grenzwerte. Sie können jedoch auch die Prozedur DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTY verwenden, um Speicherplatzkontingente für den externen Tabellencache zu definieren. Sie verwenden die Parameter PROPERTY_NAME und PROPERTY_VALUE der Prozedur DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTY, um die Grenzwerte für die Speicherplatz-Quota festzulegen.

Der Parameter PROPERTY_NAME akzeptiert die Werte MAX_CACHE_SIZE und MAX_CACHE_PERCENT. Die Eigenschaft MAX_CACHE_SIZE gibt die gesamte externe Cachegröße in Byte an. Die Eigenschaft MAX_CACHE_PERCENT gibt die gesamte externe Cachegröße als Prozentsatz der Quota des angegebenen Benutzers an.

Beispiele

BEGIN
    DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTY (
    property_name  => 'MAX_CACHE_PERCENT',          
    property_value => 50,                   
    owner          => 'SALES');                                                                
END;                                                                 
/

In diesem Beispiel wird die Caching-Voreinstellung für das Schema SALES auf MAX_CACHE_PERCENT gesetzt.

property_value ist 50%, was angibt, dass die Cachespeicher-Quota für das Schema SALES maximal 50% der gesamten für SALES definierten Speicherplatz-Quota beträgt.

BEGIN
    DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTY (
    owner          => 'SALES',   
    property_name  => 'MAX_CACHE_SIZE',          
    property_value => 5368709120);                                                                
END;                                                                 
/

In diesem Beispiel wird die Caching-Voreinstellung für das Schema SALES auf MAX_CACHE_SIZE gesetzt.

Die property_value ist 5368709120, was angibt, dass die maximale Cachegröße für das Schema SALES bis zu 5 GB beträgt.

Weitere Informationen finden Sie unter Prozedur SET_USER_PROPERTY und Prozedur CREATE_CACHE.

Verwenden Sie DBMS_EXT_TABLE_CACHE.GET_USER_PROPERTY, um die Eigenschaften der Cachegröße abzurufen.

Beispiel:

SET SERVEROUTPUT ON
    DECLARE
    max_cache_sz NUMBER,
    BEGIN
    max_cache_sz := DBMS_EXT_TABLE_CACHE.GET_USER_PROPERTY (
        property_name       => 'MAX_CACHE_SIZE',         
        owner               => 'SALES');                                                                
END;                                                                 
/

Weitere Informationen finden Sie unter Funktion GET_USER_PROPERTY.

Beachten Sie die folgende Prioritätsreihenfolge zum Festlegen der Cachegrößeneigenschaften:

  • Wenn MAX_CACHE_SIZE, MAX_CACHE_PERCENT und die Speicherplatz-Quota definiert sind, hat MAX_CACHE_PERCENT Vorrang vor MAX_CACHE_SIZE.

  • Wenn nur MAX_CACHE_SIZE definiert ist und MAX_CACHE_PERCENT oder das Speicherplatz-Quota nicht definiert ist, hat MAX_CACHE_SIZE Vorrang.

  • Wenn nur die Speicherplatz-Quota definiert ist und MAX_CACHE_SIZE und MAX_CACHE_PERCENT nicht definiert sind, entspricht die Quota für die Cachegröße standardmäßig 10% der gesamten Schema-Quota.

  • Wenn MAX_CACHE_SIZE, MAX_CACHE_PERCENT oder die Speicherplatz-Quota nicht definiert ist, wird die Cache-Speicher-Quota standardmäßig auf UNLIMITED gesetzt.

Hinweis

Um die Nutzung des Cachespeichers zu überwachen, fragen Sie die Spalte CACHE_CUR_SIZE in den Ansichten ALL_EXTERNAL_TAB_CACHES ab. Weitere Informationen finden Sie unter Views DBA_EXTERNAL_TAB_CACHES und USER_EXTERNAL_TAB_CACHES.

Automatisches Caching für externe Tabelle verwenden

Beschreibt, wie Sie automatisches Caching für externe Tabellen in Autonomous AI Database verwenden.

Wenn Sie das automatische Caching für Ihre Datenbank aktivieren, verwaltet die Datenbank automatisch den gesamten Cache-Lebenszyklus, einschließlich Erstellung, Auffüllung, Aktualisierung und Löschen, ohne dass Ihr Eingreifen erforderlich ist. Oracle verwendet interne Mechanismen, um zu bestimmen, welche externen Tabellen vom Caching profitieren können, wann die Caches aktualisiert werden und wann sie basierend auf Nutzungsmustern und verfügbarem Speicherplatz gelöscht werden sollen. Dieser Ansatz reduziert den Overhead für die Cache-Verwaltung, da die Cache-Nutzung kontinuierlich überwacht wird. Dadurch wird sichergestellt, dass häufig auf externe Tabellendaten zugegriffen wird, die im Cache verfügbar bleiben, um die Antwortzeiten der Abfrage zu verbessern.

Standardmäßig ist das automatische Caching in der Datenbank nicht aktiviert. Um sie zu aktivieren, müssen Sie die Cachegröße mit Prozeduren wie DBMS_CACHE.SET_USER_PROPERTY im Package DBMS_CACHE auf einen Wert ungleich Null setzen. Sie können das automatische Caching entweder für einen bestimmten Benutzer oder als Standardeinstellung für alle Datenbankbenutzer konfigurieren, je nach Ihren Anforderungen.

Wenn das automatische Caching externer Tabellen aktiviert ist, erstellt Oracle externe Tabellencaches, die als AUTO markiert sind, und füllt alle entsprechenden Daten aus einer externen Tabelle in den Cache auf, wenn die Quota dies zulässt. Die AUTO-Caches werden automatisch nach einem regulären Zeitplan aktualisiert. Sie können jedoch auch die Prozeduren DBMS_CACHE.REFRESH oder DBMS_CACHE.CLEAR verwenden, um Ihre Caches zu aktualisieren oder zu löschen.

Oracle verwaltet die AUTO-Caches mit einem Räumungsalgorithmus ähnlich dem LRU (Least Recently Used). Unter Speicherplatzdruck werden Caches, auf die zuletzt zugegriffen wurde, während des Aktualisierungszyklus automatisch gelöscht, um den Speicherplatz freizugeben.

In den folgenden Themen finden Sie weitere Informationen:

Themen

Automatisches Caching für externe Tabellen aktivieren

Beschreibt, wie automatische Caching-Eigenschaften konfiguriert werden.

Standardmäßig ist das automatische Caching deaktiviert. Sie können das automatische Caching für Ihre externen Tabellen entweder global für alle Datenbankbenutzer oder für einen bestimmten Benutzer aktivieren. Nachdem das automatische Caching aktiviert wurde, erstellt die Datenbank automatisch externe Tabellencaches. Alle neu erstellten Caches werden als AUTO markiert. Vorhandene Caches folgen weiterhin den richtlinienbasierten Cache-Management-Einstellungen.

Mit DBMS_CACHE.SET_GLOBAL_PROPERTY oder DBMS_CACHE.SET_USER_PROPERTY legen Sie AUTO-Caching-Eigenschaften fest, einschließlich Eigenschaften, mit denen das automatische Caching global oder für einen bestimmten Benutzer aktiviert wird. Voreinstellungen für das Caching auf Benutzerebene haben Vorrang vor globalen Caching-Voreinstellungen. Verwenden Sie die Parameter PROPERTY_NAME und PROPERTY_VALUE dieser Prozeduren, um Speicherplatzquota-Grenzwerte für externe Tabellencaches festzulegen.

Je nach angegebener Speicherplatz-Quota erstellt Oracle die Caches und versucht, die gesamten externen Tabellendaten in den Cache zu füllen. Der Populationsprozess ist nicht erfolgreich, wenn die Cachegröße nicht ausreicht, um die gesamten Daten der externen Tabelle aufzunehmen.

  1. Verwenden Sie DBMS_CACHE.SET_GLOBAL_PROPERTY, um das automatische Caching für alle Datenbankbenutzer zu aktivieren.

    Beispiele:

    Beispiel für die Aktivierung des automatischen Caches für alle Datenbankbenutzer:

    BEGIN
     DBMS_CACHE.SET_GLOBAL_PROPERTY (
        property_name       => 'MAX_CACHE_PERCENT', 
        property_value_num  => 20);                                                                
    END;                                                                 
    /

    In diesem Beispiel wird die Caching-Voreinstellung auf MAX_CACHE_PERCENT als Standard für alle Datenbankbenutzer gesetzt, und die Cache-Quota für externe Tabellen wird auf maximal 20% der insgesamt zugewiesenen Benutzer-Quota gesetzt. Sie können diese Standardeinstellung für einzelne Benutzer mit der Prozedur DBMS_CACHE.SET_USER_PROPERTY außer Kraft setzen.

    Wenn Sie das automatische Caching aktivieren, können Sie optional den Geltungsbereich der Cacheaktualisierung angeben, d.h. welche Caches während jedes Aktualisierungszyklus aktualisiert werden können, und das Zeitfenster definieren, in dem der Aktualisierungsprozess abgeschlossen werden kann.

    Beispiel zum Festlegen des Modus für die automatische Aktualisierung für alle Datenbankbenutzer:
    BEGIN
     DBMS_CACHE.SET_GLOBAL_PROPERTY (
        property_name       => 'AUTO_REFRESH_MODE', 
        property_value_str  => 'NEW');                                                              
    END;                                                                 
    /

    Gibt den Geltungsbereich an, in dem AUTO-Caches während jedes Aktualisierungszyklus aktualisiert werden. Der Wert property_value_str kann mit der Prozedur DBMS_CACHE.SET_USER_PROPERTY auf Schemaebene überschrieben werden.

    Beispiel für das maximal zulässige Zeitfenster für den Abschluss der Aktualisierung:
    BEGIN
     DBMS_CACHE.SET_GLOBAL_PROPERTY (
        property_name       => 'MAX_REFRESH_WINDOW', 
        property_value_num  => 20);                                                              
    END;                                                                 
    /

    In diesem Beispiel wird MAX_REFRESH_WINDOW auf zwanzig (20) Sekunden gesetzt.

    Weitere Informationen finden Sie unter Prozedur SET_GLOBAL_PROPERTY.

    Hinweis

    Die Eigenschaft MAX_REFRESH_WINDOW kann nur auf Datenbankebene definiert werden. Diese Eigenschaft kann nicht auf Schemaebene festgelegt werden.

    Führen Sie DBMS_CACHE.GET_GLOBAL_PROPERTY aus, um die standardmäßigen automatischen Caching-Voreinstellungen für externe Tabellen abzurufen. Beispiel:

    SET SERVEROUTPUT ON;
    DECLARE
       cache_property NUMBER;
    BEGIN
       DBMS_CACHE.GET_GLOBAL_PROPERTY (
          property_name  => 'MAX_CACHE_SIZE',
          property_value => cache_property
       );
     DBMS_OUTPUT.PUT_LINE('MAX_CACHE_SIZE = ' || cache_property);
    END;
    /

    Weitere Informationen finden Sie unter Prozedur GET_GLOBAL_PROPERTY.

  2. Mit DBMS_CACHE.SET_USER_PROPERTY aktivieren Sie das automatische Caching der externen Tabelle für einen bestimmten Benutzer. Beispiel:
    BEGIN
     DBMS_CACHE.SET_USER_PROPERTY (
            property_name       => 'MAX_CACHE_PERCENT', 
            property_value_num  => 50,
            owner               => 'HR');                                                                
    END;                                                                 
    /

    In diesem Beispiel werden die globalen Caching-Voreinstellungen mit den in DBMS_CACHE.SET_USER_PROPERTY angegebenen Werten überschrieben.

    Weitere Informationen finden Sie unter Prozedur SET_USER_PROPERTY.

    Verwenden Sie DBMS_CACHE.GET_USER_PROPERTY, um automatische Caching-Voreinstellungen für externe Tabellen für einen angegebenen Benutzer abzurufen. Beispiel:

    SET SERVEROUTPUT ON;
    DECLARE
       cache_property NUMBER;
    BEGIN
       DBMS_CACHE.GET_USER_PROPERTY (
          property_name  => 'MAX_CACHE_SIZE',
          owner          => 'HR',
          property_value => cache_property
       );
     DBMS_OUTPUT.PUT_LINE('MAX_CACHE_SIZE = ' || cache_property);
    END;
    /

    Weitere Informationen finden Sie unter Prozedur GET_USER_PROPERTY.

Hinweis

Um die Nutzung des Cachespeichers zu überwachen, fragen Sie die Spalte CACHE_CUR_SIZE in den Ansichten ALL_EXTERNAL_TAB_CACHES ab. Weitere Informationen finden Sie unter Views DBA_EXTERNAL_TAB_CACHES und USER_EXTERNAL_TAB_CACHES.

Caches für externe Tabellen werden aktualisiert

Zeigt ein Beispiel zum Aktualisieren von AUTO-Caches für das angegebene Schema an.

Die AUTO-Caches werden automatisch nach einem regulären Zeitplan aktualisiert. Abhängig vom angegebenen Aktualisierungstyp kann die Datenbank:
  • Neue Caches hinzufügen

  • Löschen Sie alle ungültigen Caches (die Caches, auf die nicht mehr zugegriffen werden kann, werden als ungültig markiert und im nachfolgenden Aktualisierungszyklus gelöscht).

  • Aktualisieren oder füllen Sie vorhandene Caches erneut.

  • Löschen Sie die zuletzt aufgerufenen Caches, wenn der Speicherplatz unter Druck steht.

Alternativ können Sie auch die Prozedur DBMS_CACHE.REFRESH verwenden, um eine On-Demand-Aktualisierung für alle Caches des HR-Benutzers auszuführen.

  1. Mit DBMS_CACHE.REFRESH aktualisieren Sie alle externen Tabellencaches des HR-Benutzers. Beispiel:
    BEGIN
        DBMS_CACHE.REFRESH (      
          owner          => 'HR',
          refresh_type   => 'ALL');                                                                 
    END;                                                                 
    /

    In diesem Beispiel werden vorhandene Caches aktualisiert und bei Bedarf neue externe Tabellencaches für das Schema HR erstellt.

    Die Eigenschaft refresh_type gibt den Geltungsbereich an, in dem die Aktualisierung ausgeführt wird. Die Eigenschaft kann einen der folgenden Werte aufweisen:
    • ALL: Alle vorhandenen AUTO-Caches für das Schema HR werden aktualisiert, und bei Bedarf werden neue Caches erstellt.

    • CURRENT: Es werden nur vorhandene Caches aktualisiert, es werden keine neuen Caches hinzugefügt.

    • NEW: Es werden nur neue Caches erstellt.

    Weitere Informationen finden Sie unter Prozedur REFRESH.

Externe Tabellencaches löschen

Zeigt ein Beispiel zum Löschen von AUTO-Caches für das angegebene Schema an.

Während jedes Aktualisierungszyklus werden ungültige Caches und die zuletzt aufgerufenen Caches aus der Datenbank gelöscht. Alternativ können Sie die Prozedur DBMS_CACHE.CLEAR verwenden, um alle Caches für einen angegebenen Benutzer zu löschen.

  1. Mit DBMS_CACHE.CLEAR können Sie alle externen Tabellencaches für das HR-Schema löschen. Beispiel:
    BEGIN
     DBMS_CACHE.CLEAR (
        owner => 'HR');                                                                
    END;                                                                 
    /

    In diesem Beispiel werden alle externen Tabellencaches für das Schema HR gelöscht.

    Weitere Informationen finden Sie unter CLEAR-Prozedur.

Cacheperformance für externe Tabellen überwachen und diagnostizieren

Autonomous AI Database bietet Ansichten, mit denen Sie den externen Tabellencache überwachen können.

Anzeigen Beschreibung

Ansichten DBA_EXTERNAL_TAB_CACHES und USER_EXTERNAL_TAB_CACHES

Stellt Informationen über alle externen Tabellencaches in der Datenbank oder über die externen Tabellencaches eines Benutzers bereit.

ALL_EXTERNAL_TAB_CACHE_LOCATIONS

Stellt Informationen zu den Dateien in Cloud Storage bereit, die für den aktuellen Benutzer zugänglich sind und zu gecachten externen Tabellen gehören.

USER_EXTERNAL_TAB_CACHE_LOCATIONS

Enthält Informationen zu den Dateien im Cloud-Speicher, deren Eigentümer der aktuelle Benutzer ist und die zu zwischengespeicherten externen Tabellen gehören. In dieser Ansicht wird die Spalte OWNER nicht angezeigt.

Diese Views enthalten detaillierte Informationen darüber, wie gecachte Daten für externe Tabellen in der Datenbank gespeichert, aufgerufen und verwaltet werden. Mit diesen Views können Sie die Cache-Performance überwachen, veraltete oder veraltete Daten identifizieren und die Speicherplatzauslastung analysieren, um eine optimale Abfrageeffizienz sicherzustellen. Durch die Überwachung dieser Views können Sie erkennen, wann Caches aktualisiert werden müssen, prüfen, ob die Cachegrößen innerhalb der konfigurierten Grenzwerte liegen, und Performanceengpässe im Zusammenhang mit dem externen Datenzugriff diagnostizieren.

Beispiele:

Die folgende Abfrage enthält Informationen zu aktiven oder veralteten externen Tabellencaches. Sie können dann die veralteten Caches löschen oder löschen, um nach Bedarf Speicherplatz freizugeben:
SELECT table_name, cached, stale, last_refreshed, last_accessed
  FROM all_external_tab_cache_locations
  ORDER BY stale DESC, usage_count DESC;

Die folgende Abfrage enthält Informationen zu Cache-Bestand und Speicherplatzbelegung:

SELECT external_table_name, cache_cur_size, cache_max_size, disabled
    FROM user_external_tab_caches;

Anwendungsfälle für das Caching externer Tabellen

Beschreibt häufige Szenarios, in denen externes Tabellen-Caching von Vorteil ist.

Anwendungsfall Was zu cachen Kostenauswirkung Performanceauswirkung Notizen

Interaktives BI oder Dashboards über externe Tabellen

Häufig abgefragte externe Tabellen oder Partitionen, die Dashboards füttern

Eliminiert wiederholte cloudübergreifende oder regionale Lesevorgänge

Hält heiße Daten lokal, um schnellere, konsistente Reaktionszeiten zu erzielen und Kaltstarts zu vermeiden

Dies ist das häufigste Szenario

Multicloud-Analysen (Beispiel: Autonomous AI Database auf OCI, die S3 oder GCS oder Azure liest)

Zugriff auf Hot-Datasets aus Nicht-OCI-Objektspeichern

Reduziert Cloud-übergreifenden Egress-Traffic und reduziert die Gebühren für Provideranforderungen

Entfernt Remote-I/O und Netzwerklatenz

Kosten und Latenz gemeinsam angeben

Regionsübergreifender Zugriff (gleiche Cloud)

Externe Daten in einer anderen Region

Verhindert regionsübergreifenden Egress bei wiederholten Scans

Reduziert die Latenz durch Lokalisierung von Lesevorgängen

Dieselbe Begründung wie bei Multicloud.

Materialized View über externe Daten aktualisieren

Externe Quelltabellen für Materialized Views

Reduziert wiederholten Egress für geplante Aktualisierungen

Stabilisiert und beschleunigt die Materialized View-Aktualisierung; verkürzt die Remote Scan-Zeit

Ideal für nahe an Echtzeitaggregate

Letzte Dateien Pipelines (Landing Zone)

Letzte N Stunden oder Tage von Dateien mit ADD_LATEST_FILES

 

Neueste Daten sind immer heiß

 

Kleine, aber häufig verknüpfte Lookup- oder Referenzdaten

Kleine externe Tabellen, die in Joins verwendet werden

Verhindert Überlastung aufgrund vieler kleiner Anforderungen

Behält Lookup-Daten für Joins lokal

Kleine Dictionary-Daten sind immer auf dem neuesten Stand und müssen kein komplexes ETL verwalten

Data Science und Feature Engineering

Wiederverwendung von Schulungen oder Featuresets in externen Tabellen

Weniger Remote-Lesevorgänge während iterativer Arbeit

Schnellere wiederholte Scans während des Experiments

Funktioniert gut mit Notebook-gesteuerten Loops

Bursty- oder gedrosselter Objektspeicher

Externe Tabelle mit hohem Datenverkehr

Weniger Wiederholungen bei vielen Benutzern

Schirmt Abfragen von Speicherdrosselung und variablem Durchsatz ab

Verbessert die SLA-Vorhersagbarkeit

Eisberg oder große abgetrennte Seen

Häufig gelesene Hot-Partitionen oder Snapshots

Vermeidet wiederholte Lesevorgänge derselben Parkettstreifen

Lokalisiert Datenseiten für Hot-Partitionen; Steadier-Abfragezeiten

Link zur Iceberg-Einrichtungsseite

Ad-hoc-Exploration in großem Maßstab

Vorläufige externe Tabellen mit wiederholtem Zugriff

Verhindert Rückzahlung von Egress während der Erkundung

Veranlasst Nachfassabfragen nach dem ersten Durchlauf

Gut auf Rampen, ohne Pipelines zu kopieren.