Spaltenbasierte Engine von AlloyDB Omni

Auf dieser Seite wird die AlloyDB Omni-spaltenorientierte Engine beschrieben und es wird erläutert, wie Sie die Engine in Container- und Kubernetes-Clusterinstallationen verwenden. Auf dieser Seite wird davon ausgegangen, dass Sie mit PostgreSQL vertraut sind.

Die spaltenbasierte Engine von AlloyDB Omni beschleunigt die Verarbeitung von SQL-Abfragen für Scans, Joins und Aggregate mit den folgenden Komponenten:

  • Ein Spaltenspeicher, der Tabellen- und Materialized-View-Daten für ausgewählte Spalten enthält, die in einem spaltenorientierten Format neu angeordnet wurden.

  • Ein spaltenorientierter Abfrageplaner und eine Ausführungs-Engine, die die Verwendung des Spaltenspeichers in Abfragen unterstützt.

Sie können die spaltenorientierte Engine auf der primären Instanz, einer Lesepoolinstanz oder auf beiden verwenden. Sie können auch die automatische Spaltenformatierung verwenden, um Ihre Arbeitslast zu analysieren und den Spaltenspeicher automatisch mit den Spalten zu füllen, die den größten Leistungsgewinn bieten.

Wenn Sie die spaltenorientierte Engine mit einer bestimmten Abfrage verwenden möchten, müssen sich alle Spalten, auf die in der Abfrage verwiesen wird, wie z. B. Joins und Scans, im Spaltenspeicher befinden.

Standardmäßig verwendet die spaltenorientierte Engine 1 GB des Arbeitsspeichers Ihrer Instanz. Je nach Arbeitslast, Arbeitsspeichernutzung und Konfiguration des Lesepools können Sie die Arbeitsspeicherzuweisung der spaltenorientierten Engine für die primäre Instanz reduzieren und der Lesepoolinstanz mehr Arbeitsspeicher zuweisen.

Informationen zum Ansehen und Überwachen der Arbeitsspeichernutzung durch die spaltenorientierte Engine finden Sie unter Speichernutzung des Spaltenspeichers ansehen. Informationen zum Ändern der vom Spaltenspeicher verwendeten Speichergröße finden Sie unter Größe des Spaltenspeichers konfigurieren. Informationen zur empfohlenen Arbeitsspeichergröße für die spaltenbasierte Engine Ihrer Instanz finden Sie unter Empfohlene Arbeitsspeichergröße für den Spaltenspeicher.

Abfragetypen, die von der spaltenbasierten Engine profitieren

Bestimmte Abfragen können von der spaltenbasierten Engine profitieren. Im Folgenden finden Sie eine Liste von Vorgängen und Abfragemustern, die von der spaltenorientierten Engine am meisten profitieren:

Vorgang Abfragemuster
Tabellenscan Selektive Filter, z. B. WHERE-Klauseln
Eine kleine Anzahl von Spalten aus einer größeren Tabelle oder materialisierten Ansicht.
Ausdrücke wie LIKE, SUBSTR oder TRIM.
Aggregationsfunktionen Nur Ausdrücke wie SUM, MIN, MAX, AVG und COUNT.
Am Anfang der Abfrage eines spaltenbasierten Scans.
Nicht gruppiert oder nach Spalten gruppiert.
ORDER-BY Nur wenn sich der Operator am Anfang der Abfrage eines spaltenbasierten Scans befindet.
SORT Nur, wenn der Operator sich am Anfang der Abfrage eines spaltenbasierten Scans befindet und nur nach den Basisspalten der Tabelle oder der materialisierten Ansicht sortiert.
LIMIT Nur, wenn der Operator sich am Anfang der Abfrage eines spaltenbasierten Scans befindet und vor allen SORT- oder GROUP BY-Operatoren steht.
INNER HASH JOIN Nur wenn die verwendeten Schlüssel Spalten sind und keine Join-Qualifikatoren verwendet werden.
Selektive Joins Nur wenn die Joins am Anfang der Abfrage eines spaltenbasierten Scans stehen.

Weitere Informationen dazu, welche Abfragen am besten mit der spaltenorientierten Engine funktionieren, ob die spaltenorientierte Engine für eine Abfrage verwendet wurde und wie sie verwendet wurde, finden Sie unter Verwendung der spaltenorientierten Engine mit EXPLAIN prüfen.

Spaltenbasierte Engine verwenden

So verwenden Sie die spaltenorientierte Engine in einer AlloyDB Omni-Instanz:

  1. Aktivieren Sie die Engine auf der Instanz.

    Die Aktivierung des Datenbankmoduls ist ein einmaliger Vorgang, der einen Neustart der Datenbank erfordert.

  2. Fügen Sie dem Spaltenspeicher Spalten hinzu.

    Sie haben folgende Möglichkeiten, dem Spaltenspeicher Spalten hinzuzufügen:

  3. Mit der Ansicht g_columnar_relations können Sie nachverfolgen, was sich im Spaltenspeicher befindet. Nachdem Spalten hinzugefügt wurden, können Sie mit der Anweisung EXPLAIN die Verwendung der spaltenorientierten Engine in SQL-Abfragen prüfen.

Eine ausführliche Anleitung zur Verwendung der spaltenorientierten Engine finden Sie unter Spaltenorientierte Engine konfigurieren.

Welche Daten Sie dem Spaltenspeicher hinzufügen können

Es gibt einige Einschränkungen für die Datentypen und Datenquellen, die Sie verwenden können, wenn Sie dem Tabellenspeicher Spalten hinzufügen.

Unterstützte Datentypen

Die spaltenorientierte Engine unterstützt nur Spalten mit den folgenden vordefinierten Datentypen:

  • array
  • bigint
  • boolean
  • bytea
  • char
  • date
  • decimal
  • double precision
  • enum
  • float4
  • float8
  • integer
  • json
  • jsonb
  • numeric
  • real
  • serial
  • short
  • smallint
  • text
  • timestamp
  • uuid
  • varchar

Die spaltenorientierte Engine ignoriert alle Versuche, dem Spaltenspeicher manuell Spalten mit nicht unterstützten Datentypen hinzuzufügen.

Nicht unterstützte Datenquellen

Die spaltenorientierte Engine unterstützt keine Tabellen oder materialisierten Ansichten mit den folgenden Attributen als Datenquellen:

  • Nicht untergeordnete partitionierte Tabellen

  • Fremde Tabellen

  • Tabellen oder Ansichten mit weniger als 5.000 Zeilen

Einschränkungen der spaltenbasierten Engine

  • Wenn Sie eine Analyseabfrage für eine Spalte mit Index ausführen, verwendet der AlloyDB Omni-Optimierungstool möglicherweise den Zeilenspeicher.
  • Manuell dem Spaltenspeicher hinzugefügte Spalten werden nicht automatisch entfernt. Wenn Sie manuell hinzugefügte Spalten erzwingen möchten, verwenden Sie google_columnar_engine_drop in Ihrer Instanz.
  • Bei der automatischen Spaltenstruktur werden möglicherweise basierend auf der Abfragenutzung dynamisch Spalten hinzugefügt und entfernt.
  • Nicht alle Datentypen werden von der spaltenorientierten Engine unterstützt. Informationen zu den unterstützten Datentypen finden Sie unter Unterstützte Datentypen.

  • Häufige Aktualisierungen von Zeilen machen spaltenbasierte Daten ungültig. Wenn Sie eine Tabelle oder eine materialisierte Ansicht im spaltenorientierten Speicher validieren möchten, können Sie entweder die Aktualisierungshäufigkeit verringern oder die Aktualisierungen der spaltenorientierten Engine häufiger planen.

    Sie können die Spalten invalid_block_count und total_block_count in g_columnar_relations vergleichen, um zu prüfen, ob Ihre Tabelle oder Ansicht betroffen ist. Bei häufigen oder umfangreichen Änderungen an der Tabelle oder Ansicht ist der Wert für invalid_block_count hoch.

Nächste Schritte