Spalten-Engine von AlloyDB

Auf dieser Seite finden Sie einen Überblick über das spaltenorientierte Modul, das AlloyDB for PostgreSQL bietet, und eine Anleitung zur Verwendung.

Die spaltenbasierte Engine von AlloyDB beschleunigt die Verarbeitung von Scans, Joins und Aggregaten in SQL-Abfrage durch die folgenden Komponenten:

  • Ein Spaltenspeicher, der Tabellen- und materialisierte Ansichtsdaten für ausgewählte Spalten enthält, die in ein spaltenorientiertes Format umorganisiert wurden.

  • Ein spaltenorientierter Abfrageplaner und eine spaltenorientierte Ausführungs-Engine zur Unterstützung der Verwendung des Spaltenspeichers in Abfragen.

Die spaltenorientierte Engine kann auf der primären Instanz, einer Lesepoolinstanz oder beiden verwendet werden. Sie können auch die automatische Spaltenformatierung verwenden, um Ihre Arbeitslast zu analysieren und den Spaltenspeicher automatisch mit den Spalten zu füllen, die die beste Leistungssteigerung bieten.

Wenn Sie die spaltenorientierte Engine für eine bestimmte Abfrage verwenden möchten, müssen sich alle Spalten in den Fragmenten dieser Abfrage, z. B. Joins und Scans, im Spaltenspeicher befinden.

Standardmäßig verwendet die spaltenorientierte Engine 30% des Arbeitsspeichers Ihrer Instanz. Je nach Arbeitslast, Arbeitsspeichernutzung und Konfiguration eines Lesepools können Sie die Arbeitsspeicherzuweisung für die spaltenorientierte Engine auf Ihrer primären Instanz reduzieren und der Lesepoolinstanz mehr Arbeitsspeicher zuweisen. Informationen zum Ansehen und Überwachen der Arbeitsspeichernutzung durch die Spalten-Engine finden Sie unter Arbeitsspeichernutzung des Spaltenspeichers ansehen. Informationen zum Ändern der vom Spaltenspeicher verwendeten Speichergröße finden Sie unter Größe des Spaltenspeichers konfigurieren. Die empfohlene Arbeitsspeichergröße für die spaltenbasierte Engine für Ihre 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 der Vorgänge und ihrer Abfragemuster, die am meisten von der spaltenorientierten Engine profitieren:

  • Table Scans

    • Sie verfügt über selektive Filter wie WHERE-Klauseln.
    • Es werden nur wenige Spalten aus einer größeren Tabelle oder materialisierten Ansicht verwendet.
    • Sie verwendet Ausdrücke wie LIKE, SUBSTR oder „TRIM“.

  • Aggregatfunktionen

    • Sie verwenden nur die folgenden Ausdrücke: SUM, MIN, MAX, AVG und COUNT.
    • Sie stehen am Anfang der Abfrage eines spaltenorientierten Scans.
    • Sie sind nicht gruppiert oder werden nach Spalten gruppiert.

  • ORDER-BY und SORT: nur, wenn ORDER-BY oder SORT in den Scanergebnissen von Spalten enthalten ist, auf die über die spaltenorientierte Engine zugegriffen wird.

  • LIMIT: nur, wenn sich der Operator am Anfang der Anfrage eines spaltenweisen 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-Qualifizierer verwendet werden.

  • Selektive Joins nur, wenn sich die Joins am Anfang der Abfrage eines spaltenweisen Scans befinden.

Weitere Informationen dazu, welche Abfragen am besten mit der spaltenorientierten Engine funktionieren, ob und wie die spaltenorientierte Engine von einer Abfrage verwendet wurde, finden Sie unter Verwendung der spaltenorientierten Engine mit EXPLAIN überprüfen.

Spaltenorientierte Engine verwenden

So verwenden Sie die spaltenbasierte Engine in einer AlloyDB-Instanz:

  1. Aktivieren Sie die Engine auf der Instanz.

    Das Aktivieren der Engine ist ein einmaliger Vorgang und erfordert einen Neustart.

  2. Fügen Sie dem Spaltenspeicher Spalten hinzu.

    Mit einer der folgenden Methoden können Sie dem Spaltenspeicher Spalten hinzufügen:

  3. Mit der Ansicht g_columnar_relations können Sie nachvollziehen, 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 können dem Spaltenspeicher hinzugefügt werden?

Es gibt einige Einschränkungen hinsichtlich der Datentypen und Datenquellen, die Sie verwenden können, wenn Sie dem Spaltenspeicher Spalten hinzufügen.

Unterstützte Datentypen

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

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

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-Leaf-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 einem Index ausführen, kann der AlloyDB-Optimierer den Zeilenspeicher verwenden.
  • Spalten, die dem Spaltenspeicher manuell hinzugefügt wurden, 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 Spaltenorientierung können Spalten basierend auf der Abfragenutzung dynamisch hinzugefügt und entfernt werden.
  • 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 Spaltendaten ungültig. Wenn Sie eine Tabelle oder eine materialisierte Ansicht im Spaltenspeicher validieren möchten, können Sie entweder die Aktualisierungshäufigkeit verringern oder die Aktualisierungen der Spalten-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. Wenn Sie häufig oder in großem Umfang Änderungen an Ihrer Tabelle oder Ansicht vornehmen, ist der invalid_block_count hoch.

Nächste Schritte