Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
CTASHinweise zur Nutzung
Einschränkungen
Amazon Redshift erzwingt ein Kontingent für die Anzahl der Tabellen pro Cluster nach Knotentyp.
Die maximale Anzahl von Zeichen für einen Tabellennamen ist 127.
Die maximale Anzahl der Spalten, die Sie in einer einzelnen Tabelle definieren können, ist 1.600.
Vererbung von Spalten- und Tabellenattributen
CREATETABLEAS (CTAS) -Tabellen erben keine Einschränkungen, Identitätsspalten, Standardspaltenwerte oder den Primärschlüssel aus der Tabelle, aus der sie erstellt wurden.
Sie können keine Codierungen für die Spaltenkomprimierung für CTAS Tabellen angeben. Amazon Redshift weist die Komprimierungskodierung automatisch wie folgt zu:
-
Spalten, die als Sortierschlüssel definiert sind, wird RAW Komprimierung zugewiesen.
-
Spalten, die alsBOOLEAN,, REAL DOUBLE PRECISIONGEOMETRY, oder GEOGRAPHY Datentyp definiert sind, wird RAW Komprimierung zugewiesen.
-
Spalten, die alsSMALLINT,,,INTEGER,BIGINT, DECIMAL DATE TIME TIMETZTIMESTAMP, oder definiert TIMESTAMPTZ sind oder denen eine AZ64 Komprimierung zugewiesen wurde.
-
Spalten, die als CHARVARCHAR, definiert VARBYTE sind oder denen LZO Komprimierung zugewiesen wurde.
Weitere Informationen erhalten Sie unter Kompressionskodierungen und Datentypen.
Um Spaltenkodierungen explizit zuzuweisen, verwenden Sie CREATE TABLE.
CTASbestimmt den Verteilungsstil und den Sortierschlüssel für die neue Tabelle auf der Grundlage des Abfrageplans für die SELECT Klausel.
Bei komplexen Abfragen, wie z. B. Abfragen, die Verknüpfungen, Aggregationen, eine Order-by-Klausel oder eine Limit-Klausel enthalten, CTAS bemüht man sich nach besten Kräften, den optimalen Verteilungsstil und Sortierschlüssel auf der Grundlage des Abfrageplans auszuwählen.
Anmerkung
Um für große Datensätze oder komplexe Abfragen eine optimale Leistung zu erzielen, werden Tests mit typischen Datensätzen empfohlen.
Sie können häufig vorhersagen, welcher Verteilungs- und Sortierschlüssel CTAS ausgewählt wird, indem Sie den Abfrageplan daraufhin untersuchen, welche Spalten, falls vorhanden, der Abfrageoptimierer für die Sortierung und Verteilung von Daten auswählt. Handelt es sich bei dem obersten Knoten des Abfrageplans um einen einfachen sequentiellen Scan aus einer einzelnen Tabelle (XN Seq Scan), werden in der CTAS Regel der Verteilungsstil und der Sortierschlüssel der Quelltabelle verwendet. Wenn es sich bei dem obersten Knoten des Abfrageplans um einen anderen Knoten handelt, wird bei einem sequentiellen Scan (wie XN Limit, XN Sort, XN usw.) nach besten Kräften versucht HashAggregate, den optimalen Verteilungsstil und den optimalen Sortierschlüssel auf der Grundlage des Abfrageplans auszuwählen. CTAS
Nehmen wir beispielsweise an, Sie erstellen fünf Tabellen mit den folgenden Klauseltypen: SELECT
-
Eine einfache SELECT-Anweisung
-
Eine Limit-Klausel
-
Eine Order-by-Klausel mit LISTID
-
Eine Reihenfolge nach Klausel mit QTYSOLD
-
Eine SUM Aggregatfunktion mit einer Group by-Klausel.
Die folgenden Beispiele zeigen den Abfrageplan für jede CTAS Anweisung.
explain create table sales1_simple as select listid, dateid, qtysold from sales; QUERY PLAN ---------------------------------------------------------------- XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8) (1 row) explain create table sales2_limit as select listid, dateid, qtysold from sales limit 100; QUERY PLAN ---------------------------------------------------------------------- XN Limit (cost=0.00..1.00 rows=100 width=8) -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8) (2 rows) explain create table sales3_orderbylistid as select listid, dateid, qtysold from sales order by listid; QUERY PLAN ------------------------------------------------------------------------ XN Sort (cost=1000000016724.67..1000000017155.81 rows=172456 width=8) Sort Key: listid -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8) (3 rows) explain create table sales4_orderbyqty as select listid, dateid, qtysold from sales order by qtysold; QUERY PLAN ------------------------------------------------------------------------ XN Sort (cost=1000000016724.67..1000000017155.81 rows=172456 width=8) Sort Key: qtysold -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8) (3 rows) explain create table sales5_groupby as select listid, dateid, sum(qtysold) from sales group by listid, dateid; QUERY PLAN ---------------------------------------------------------------------- XN HashAggregate (cost=3017.98..3226.75 rows=83509 width=8) -> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8) (2 rows)
Um den Verteilungs- und Sortierschlüssel für jede Tabelle anzuzeigen, fragen Sie die DEF Systemkatalogtabelle TABLE PG_ _ ab, wie im Folgenden gezeigt.
select * from pg_table_def where tablename like 'sales%'; tablename | column | distkey | sortkey ----------------------+------------+---------+--------- sales | salesid | f | 0 sales | listid | t | 0 sales | sellerid | f | 0 sales | buyerid | f | 0 sales | eventid | f | 0 sales | dateid | f | 1 sales | qtysold | f | 0 sales | pricepaid | f | 0 sales | commission | f | 0 sales | saletime | f | 0 sales1_simple | listid | t | 0 sales1_simple | dateid | f | 1 sales1_simple | qtysold | f | 0 sales2_limit | listid | f | 0 sales2_limit | dateid | f | 0 sales2_limit | qtysold | f | 0 sales3_orderbylistid | listid | t | 1 sales3_orderbylistid | dateid | f | 0 sales3_orderbylistid | qtysold | f | 0 sales4_orderbyqty | listid | t | 0 sales4_orderbyqty | dateid | f | 0 sales4_orderbyqty | qtysold | f | 1 sales5_groupby | listid | f | 0 sales5_groupby | dateid | f | 0 sales5_groupby | sum | f | 0
In der folgenden Tabelle werden die Ergebnisse zusammengefasst. Aus Gründen der Einfachheit werden Details zu Kosten, Zeilen und zur Breite aus dem Beispielplan ausgelassen.
|
Tabelle |
CTASSELECTAussage |
Oberster Knoten des Beispielplans |
Verteilungsschlüssel |
Sortierschlüssel |
|---|---|---|---|---|
| S1_ SIMPLE |
|
|
LISTID | DATEID |
| S2_ LIMIT |
|
|
Keine () EVEN | None |
| S3_ _VON_ ORDER LISTID |
|
|
LISTID | LISTID |
| S4_ ORDER _VON_ QTY |
|
|
LISTID | QTYSOLD |
| S5_ GROUP _VON |
|
|
Keiner () EVEN | None |
Sie können den Verteilungsstil und den Sortierschlüssel in der CTAS Anweisung explizit angeben. Die folgende Anweisung erstellt beispielsweise eine Tabelle mithilfe der EVEN Verteilung und gibt SALESID sie als Sortierschlüssel an.
create table sales_disteven diststyle even sortkey (salesid) as select eventid, venueid, dateid, eventname from event;
Kompressionskodierung
ENCODEAUTOwird als Standard für Tabellen verwendet. Amazon Redshift verwaltet automatisch die Komprimierungskodierung für alle Spalten in der Tabelle.
Verteilung eingehender Daten
Wenn das Hash-Verteilungsschema der eingehenden Daten dem der Zieltabelle entspricht, ist keine physische Verteilung der Daten notwendig, wenn die Daten geladen werden. Wenn beispielsweise ein Verteilungsschlüssel für die neue Tabelle festgelegt wird und die Daten aus einer anderen Tabelle eingefügt werden, die anhand der gleichen Schlüsselspalte verteilt wird, werden die Daten unter Verwendung derselben Knoten und Slices entsprechend geladen. Wenn jedoch sowohl die Quell- als auch die Zieltabelle auf EVEN Verteilung eingestellt sind, werden die Daten in die Zieltabelle neu verteilt.
Automatische Operationen ANALYZE
Amazon Redshift analysiert automatisch Tabellen, die Sie mit CTAS Befehlen erstellen. Sie müssen den ANALYZE Befehl nicht für diese Tabellen ausführen, wenn sie zum ersten Mal erstellt werden. Wenn Sie sie ändern, sollten Sie sie jedoch genauso wie andere Tabellen analysieren.
