Föderierte Cloud SQL-Abfragen
Auf dieser Seite wird beschrieben, wie Sie Daten in Cloud SQL mithilfe von föderierten Abfragen in BigQuery abfragen.
Überblick
Mit der Föderation von BigQuery und Cloud SQL kann BigQuery Daten in Cloud SQL in Echtzeit abfragen, ohne Daten kopieren oder verschieben zu müssen. Föderierte Abfragen unterstützen sowohl MySQL- (2. Generation) als auch PostgreSQL-Instanzen in Cloud SQL.
Nach der ersten einmaligen Einrichtung können Sie eine Abfrage mit der SQL-Funktion EXTERNAL_QUERY
schreiben.
Zum Replizieren von Daten nach BigQuery können Sie auch Cloud Data Fusion oder Datastream verwenden. Weitere Informationen zur Verwendung von Cloud Data Fusion finden Sie unter Daten von MySQL in BigQuery replizieren.
Vorbereitung
BigQuery-Verbindungsdienst aktivieren
- Öffnen Sie in der API-Bibliothek die Seite BigQuery Connection API.
- Wählen Sie im Drop-down-Menü das Projekt aus, das Ihre externe Datenquelle enthält.
Klicken Sie auf die Schaltfläche AKTIVIEREN.
Dienstkonto
Wenn Sie die BigQuery Connection API aktivieren, wird automatisch ein Dienstkonto erstellt. Wenn Sie die BigQuery Connection API in einem Projekt aktivieren, das Ihre Cloud SQL-Datenquelle enthält, werden die folgenden Rollen angewendet:
Rolle | Beschreibung |
---|---|
cloudsql.client |
Verbindung mit einer Cloud SQL-Instanz herstellen |
logging.logWriter |
In Stackdriver Logging schreiben |
monitoring.metricWriter |
In Cloud Monitoring schreiben |
Weitere Informationen zu Dienstkonten finden Sie unter Dienst-Agents.
Öffentliche IP-Adresse
Die Föderation von BigQuery und Cloud SQL unterstützt nur Cloud SQL-Instanzen mit einer öffentlichen IP-Verbindung. Konfigurieren Sie die öffentliche IP-Verbindung für Ihre Cloud SQL-Instanz.
Zum Schutz Ihrer Cloud SQL-Instanzen können Sie öffentliche IP-Verbindungen ohne autorisierte Adresse hinzufügen. Mit dieser Methode ist Ihre Instanz über das öffentliche Internet nicht erreichbar, aber für Abfragen nach BigQuery zugänglich. Im Vergleich zu Cloud SQL-Instanzen, die private IP-Adressen verwenden, sind diese Instanzen jedoch weniger sicher.
Cloud SQL-Datenbankverbindungen einrichten
Sobald die BigQuery Connection API aktiviert ist, erstellen Sie eine Verbindung zur Cloud SQL-Datenbank.
Console
Rufen Sie zum Erstellen einer Verbindungsressource die BigQuery-Seite in der Cloud Console auf.
Wählen Sie im Menü
Daten hinzufügen die Option Externe Datenquelle aus.Geben Sie im Dialogfeld Externe Datenquelle die folgenden Informationen ein:
- Wählen Sie als Verbindungstyp den Typ der Quelle aus, z. B. MySQL oder Postgres.
- Geben Sie unter Verbindungs-ID eine Kennung für die Verbindungsressource ein. Buchstaben, Ziffern und Unterstriche sind zulässig. Beispiel:
bq_sql_connection
- Wählen Sie unter Datenstandort einen BigQuery-Standort (oder eine Region) aus, der mit Ihrer externen Region für die Datenquellen kompatibel ist.
- Optional: Sie können unter Anzeigename einen nutzerfreundlichen Namen für die Verbindung eingeben, z. B.
My connection resource
. Der Anzeigename kann ein beliebiger Wert sein, mit dem Sie die Verbindungsressource identifizieren können, wenn Sie sie später ändern müssen. - Optional: Sie können unter Beschreibung eine Beschreibung für diese Verbindungsressource eingeben.
- Wenn Sie Cloud SQL MySQL oder Postgres als Verbindungstyp ausgewählt haben, geben Sie als Cloud SQL-Instanz-ID den vollständigen Namen der Cloud SQL-Instanz normalerweise im Format
project-id:location-id:instance-id
ein. Sie finden die Instanz-ID auf der Detailseite der Cloud SQL-Instanz, die Sie abfragen möchten. - Geben Sie unter Datenbankname den Namen der Datenbank ein.
- Geben Sie unter Datenbanknutzername den Nutzernamen für die Datenbank ein.
Geben Sie unter Datenbankpasswort das Passwort für die Datenbank ein.
- Optional: Klicken Sie auf Passwort anzeigen, um das Passwort anzuzeigen.
Klicken Sie auf Verbindung erstellen.
bq
Geben Sie den Befehl bq mk
ein und geben Sie das Verbindungs-Flag --connection
an. Die folgenden Flags sind ebenfalls erforderlich:
--connection_type
--properties
--connection_credential
--project_id
--location
Die folgenden Flags sind optional:
--display_name
: Der Anzeigename für die Verbindung.--description
: Eine Beschreibung der Verbindung.
Die connection_id
ist ein optionaler Parameter, der als letztes Argument des Befehls hinzugefügt werden kann, der intern für die Speicherung verwendet wird. Wenn keine Verbindungs-ID angegeben wird, wird automatisch eine eindeutige ID generiert.
Die connection_id
kann Buchstaben, Ziffern und Unterstriche enthalten.
bq mk --connection --display_name='friendly name' --connection_type=TYPE \
--properties=PROPERTIES --connection_credential=CREDENTIALS \
--project_id=PROJECT_ID --location=LOCATION \
CONNECTION_ID
Dabei gilt:
TYPE
: der Typ der externen Datenquelle.PROPERTIES
: die Parameter für die erstellte Verbindung im JSON-Format Beispiel:--properties='{"param":"param_value"}'
. Zum Erstellen einer Verbindungsressource müssen Sie die ParameterinstanceID
,database
undtype
angeben.CREDENTIALS
: die Parameterusername
undpassword
PROJECT_ID
: Ihre Projekt-ID.LOCATION
: die Region, in der sich Ihre Cloud SQL-Instanz befindetCONNECTION_ID
: die Verbindungs-ID.
Mit dem folgenden Befehl wird beispielsweise eine neue Verbindungsressource mit dem Namen „my_new_connection“ (Anzeigename: „My new connection“) in einem Projekt mit der ID federation-test
erstellt.
bq mk --connection --display_name='friendly name' --connection_type='CLOUD_SQL' \
--properties='{"instanceId":"federation-test:us-central1:mytestsql","database":"mydatabase","type":"MYSQL"}' \
--connection_credential='{"username":"myusername", "password":"mypassword"}' \
--project_id=federation-test --location=us my_connection_id
API
Innerhalb der BigQuery Connection API können Sie CreateConnection
innerhalb von ConnectionService
aufrufen, um eine Verbindung zu instanziieren. Weitere Informationen finden Sie auf der Seite der Clientbibliotheken.
Java
Bevor Sie dieses Beispiel ausprobieren, folgen Sie den Schritten zur Einrichtung von Java in der BigQuery-Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur BigQuery Java API.
Informationen zum Ansehen, Auflisten, Freigeben, Aktualisieren und Löschen von Verbindungsressourcen finden Sie unter Mit Verbindungen arbeiten.
Beispiel
Angenommen Sie speichern eine Kundentabelle in BigQuery und eine Verkaufstabelle in Cloud SQL und möchten die beiden Tabellen in einer einzigen Abfrage verknüpfen. Im folgenden Beispiel wird eine föderierte Abfrage an eine Cloud SQL-Tabelle namens orders
gesendet und die Ergebnisse werden mit einer BigQuery-Tabelle namens mydataset.customers
verknüpft.
SELECT c.customer_id, c.name, rq.first_order_date
FROM mydataset.customers AS c
LEFT OUTER JOIN EXTERNAL_QUERY(
'us.connection_id',
'''SELECT customer_id, MIN(order_date) AS first_order_date
FROM orders
GROUP BY customer_id''') AS rq ON rq.customer_id = c.customer_id
GROUP BY c.customer_id, c.name, rq.first_order_date;
Die Beispielabfrage besteht aus 3 Teilen:
- Die externe Abfrage
SELECT customer_id, MIN(order_date) AS first_order_date FROM orders GROUP BY customer_id
wird in der operativen PostgreSQL-Datenbank ausgeführt, um das erste Bestelldatum für jeden Kunden über die FunktionEXTERNAL_QUERY()
abzurufen. - Verknüpfen Sie die Ergebnistabelle der externen Abfrage mit der Kundentabelle in BigQuery anhand von
customer_id
. - Die Kundendaten und das Datum der ersten Bestellung werden ausgewählt.
Unterstützte Regionen
Die folgende Tabelle zeigt, welche Regionen für BigQuery und Cloud SQL unterstützt werden.
Regionale Standorte
Beschreibung der Region | Cloud SQL-Region | Kompatible BigQuery-Region | Kompatible BigQuery-Multiregion | |
---|---|---|---|---|
Amerika | ||||
Iowa | us-central |
Nicht unterstützt: Diese Region der Cloud SQL-Instanz ist V1. Föderierte Abfragen unterstützen nur V2-Instanzen von Cloud SQL. |
||
Iowa | us-central1 |
us-central1 |
US |
|
Las Vegas | us-west4 |
us-west4 |
US |
|
Los Angeles | us-west2 |
us-west2 |
US |
|
Montreal | northamerica-northeast1 |
northamerica-northeast1 |
US |
|
Nord-Virginia | us-east4 |
us-east4 |
US |
|
Oregon | us-west1 |
us-west1 |
US |
|
Salt Lake City | us-west3 |
us-west3 |
US |
|
São Paulo | southamerica-east1 |
southamerica-east1 |
||
Santiago | southamerica-west1 |
southamerica-west1 |
||
South Carolina | us-east1 |
us-east1 |
US |
|
Toronto | northamerica-northeast2 |
northamerica-northeast2 |
US |
|
Europa | ||||
Belgien | europe-west1 |
europe-west1 |
EU |
|
Finnland | europe-north1 |
europe-north1 |
EU |
|
Frankfurt | europe-west3 |
europe-west3 |
EU |
|
London | europe-west2 |
europe-west2 |
EU |
|
Netherlands | europe-west4 |
europe-west4 |
EU |
|
Warschau | europe-central2 |
europe-central2 |
EU |
|
Zürich | europe-west6 |
europe-west6 |
EU |
|
Asia Pacific | ||||
Delhi | asia-south2 |
asia-south2 |
||
Hong Kong | asia-east2 |
asia-east2 |
||
Jakarta | asia-southeast2 |
asia-southeast2 |
||
Melbourne | australia-southeast2 |
australia-southeast2 |
||
Mumbai | asia-south1 |
asia-south1 |
||
Osaka | asia-northeast2 |
asia-northeast2 |
||
Seoul | asia-northeast3 |
asia-northeast3 |
||
Singapur | asia-southeast1 |
asia-southeast1 |
||
Sydney | australia-southeast1 |
australia-southeast1 |
||
Taiwan | asia-east1 |
asia-east1 |
||
Tokio | asia-northeast1 |
asia-northeast1 |
Multiregionale Standorte
Multiregionale Standorte sind für Cloud SQL-Instanzen nicht verfügbar. Cloud SQL-Multiregionen können nicht für föderierte Abfragen verwendet werden.
Daten in der Multiregion EU
werden nicht in den Rechenzentren europe-west2
(London) oder europe-west6
(Zürich) gespeichert.
Beschränkungen
Föderierte Cloud SQL-Abfragen unterliegen den folgenden Einschränkungen:
Leistung: Eine föderierte Abfrage ist wahrscheinlich nicht so schnell wie das alleinige Abfragen des BigQuery-Speichers. BigQuery muss warten, bis die Quelldatenbank die externe Abfrage ausführt und Daten vorübergehend aus der externen Datenquelle in BigQuery verschiebt. Außerdem ist die Quelldatenbank möglicherweise nicht für komplexe analytische Abfragen optimiert.
Föderierte Abfragen sind schreibgeschützt. Die externe Abfrage, die in der Quelldatenbank ausgeführt wird, muss schreibgeschützt sein. Daher werden DML- und DDL-Anweisungen nicht unterstützt.
Nicht unterstützte Datentypen. Wenn Ihre externe Abfrage einen Datentyp enthält, der in BigQuery nicht unterstützt wird, schlägt die Abfrage sofort fehl. Sie können den nicht unterstützten Datentyp in einen anderen unterstützten Datentyp umwandeln.
Eingeschränkte Cloud SQL-Instanzen. Föderierte Abfragen werden nur von der Cloud SQL-V2-Instanz mit öffentlicher IP-Adresse (im Gegensatz zu einer privaten IP-Adresse) unterstützt.
Project. Sie müssen die Verbindungsressource im selben Projekt wie die Cloud SQL-Instanz erstellen.
Kontingente und Limits
Zusätzlich zu den Kontingenten und Limits für föderierte Abfragen gelten für Cloud SQL-Datenbanken die folgenden Einschränkungen.
- Regionenübergreifende föderierte Abfragen: Wenn sich der BigQuery-Standort zur Abfrageverarbeitung und der Standort der externen Datenquelle unterscheiden, ist dies eine regionenübergreifende Abfrage. Sie können pro Projekt und Tag regionenübergreifende Abfragen in einem Umfang von bis zu 1 TB ausführen. Das folgende Beispiel zeigt eine regionenübergreifende Abfrage.
- Die Cloud SQL-Instanz befindet sich in
us-west1
, während sich die BigQuery-Verbindung in der MultiregionUS
befindet. Der BigQuery-Standort zur Abfrageverarbeitung istUS
.
- Die Cloud SQL-Instanz befindet sich in
- Kontingent: Nutzer sollten ihr Abfragekontingent in der externen Datenquelle Cloud SQL steuern. Es gibt keine zusätzliche Kontingenteinstellung für föderierte Abfragen. Wenn Sie eine Isolation von Arbeitslasten erreichen möchten, wird empfohlen, nur ein Lesereplikat der Datenbank abzufragen.
- Es gelten Kontingente und Beschränkungen für Cloud SQL MySQL und PostgreSQL.
Referenz
Cloud SQL-Tabellenschema ansehen
Mit der Funktion EXTERNAL_QUERY()
können Sie information_schema-Tabellen abfragen, um auf Datenbankmetadaten zuzugreifen, z. B. um eine Liste aller Tabellen in der Datenbank oder das Tabellenschema abzurufen. Die folgenden information_schema-Beispielabfragen funktionieren sowohl in MySQL als auch in PostgreSQL. Weitere Informationen finden Sie in den Artikeln zu information_schema-Tabellen in MySQL bzw. information_schema-Tabellen in PostgreSQL.
-- List all tables in a database.
SELECT * FROM EXTERNAL_QUERY("connection_id",
"select * from information_schema.tables;");
-- List all columns in a table.
SELECT * FROM EXTERNAL_QUERY("connection_id",
"select * from information_schema.columns where table_name='x';");
Details zur Verbindungsressource
Name des Attributs | Wert | Beschreibung |
---|---|---|
name |
String | Name der Verbindungsressource im Format project_id.location_id.connection_id. |
location |
String | Standort der Verbindung. Er entspricht dem Standort der Cloud SQL-Instanz mit den folgenden Ausnahmen: Cloud SQL us-central1 wird BigQuery US zugeordnet, Cloud SQL europe-west1 wird BigQuery EU zugeordnet. |
friendlyName |
String | Ein nutzerfreundlicher Anzeigename für die Verbindung. |
description |
String | Beschreibung der Verbindung. |
cloudSql.type |
String | Kann "POSTGRES" oder "MYSQL" sein. |
cloudSql.instanceId |
String | Name der Cloud SQL-Instanz, in der Regel im folgenden Format:Project-id:location-id:instance-id Sie finden die Instanz-ID auf der Detailseite der Cloud SQL-Instanz. |
cloudSql.database |
String | Die Cloud SQL-Datenbank, zu der Sie eine Verbindung herstellen möchten. |
Details zu Anmeldedaten für die Verbindungsressource
Name des Attributs | Wert | Beschreibung |
---|---|---|
username |
String | Nutzername der Datenbank. |
password |
String | Passwort der Datenbank. |
Datentypzuordnungen
Wenn Sie eine föderierte Cloud SQL-Abfrage ausführen, werden die Daten aus Cloud SQL (als MySQL- oder PostgreSQL-Datentypen) in BigQuery-Standard-SQL-Typen konvertiert. Die folgenden Datentypzuordnungen stammen von MySQL zu BigQuery und von PostgreSQL zu BigQuery.
Wissenswertes über Zuordnungen:
- Die meisten MySQL-Datentypen können demselben BigQuery-Datentyp zugeordnet werden.
- PostgreSQL unterstützt viele nicht standardmäßige Datentypen, die in BigQuery nicht unterstützt werden, zum Beispiel
money
,path
,uuid
,boxer
und andere. - Die numerischen Datentypen in MySQL und PostgreSQL werden standardmäßig dem BigQuery-Wert
NUMERIC
zugeordnet. DerNUMERIC
-Wertebereich ist in BigQuery kleiner als in MySQL und PostgreSQL. Sie kann auch mit „default_type_for_decimal_columns“ in EXTERNAL_QUERY-Optionen mitBIGNUMERIC
,FLOAT64
oderSTRING
verknüpft werden.
Fehlerbehandlung
Wenn Ihre externe Abfrage einen Datentyp enthält, der in BigQuery nicht unterstützt wird, schlägt die Abfrage sofort fehl. Sie können den nicht unterstützten Datentyp in einen anderen unterstützten MySQL/PostgreSQL-Datentyp umwandeln.
Sie können den nicht unterstützten Datentyp in einen anderen unterstützten MySQL- oder PostgreSQL-Datentyp umwandeln.
Nicht unterstützter MySQL-Datentyp
- Fehlermeldung:
Invalid table-valued function external_query Found unsupported MySQL type in BigQuery at [1:15]
- Nicht unterstützter Typ:
GEOMETRY
,BIT
- Lösung: Wandeln Sie den nicht unterstützten Datentyp in STRING um.
- Beispiel:
SELECT ST_AsText(ST_GeomFromText('POINT(1 1)'));
. Dieser Befehl wandelt den nicht unterstützten DatentypGEOMETRY
inSTRING
um.
- Fehlermeldung:
Nicht unterstützter PostgreSQL-Datentyp
- Fehlermeldung:
Invalid table-valued function external_query Postgres type (OID = 790) is not supported now at [1:15]
- Nicht unterstützter Typ:
money
,time with time zone
,inet
,path
,pg_lsn
,point
,polygon
,tsquery
,tsvector
,txid_snapshot
,uuid
,box
,cidr
,circle
,interval
,jsonb
,line
,lseg
,macaddr
,macaddr8
- Lösung: Wandeln Sie den nicht unterstützten Datentyp in STRING um.
- Beispiel:
SELECT CAST('12.34'::float8::numeric::money AS varchar(30));
. Dieser Befehl wandelt den nicht unterstützten Datentypmoney
inSTRING
um.
- Fehlermeldung:
Typzuordnung von MySQL zu BigQuery
MySQL-Typ | MySQL-Beschreibung | BigQuery-Typ | Unterschied zwischen Typen |
---|---|---|---|
Ganzzahl | |||
INT | 4 Byte, 2^32 - 1 | INT64 | |
TINYINT | 1 Byte, 2^8 - 1 | INT64 | |
SMALLINT | 2 Byte, 2^16 - 1 | INT64 | |
MEDIUMINT | 3 Byte, 2^24 - 1 | INT64 | |
BIGINT | 8 Byte, 2^64 - 1 | INT64 | |
UNSIGNED BIGINT | 8 Byte, 2^64 - 1 | NUMERIC | |
Genaue numerische Werte | |||
DECIMAL (M,D) | Eine Dezimalzahl wird durch (M,D) dargestellt, wobei M die Gesamtzahl der Stellen und D die Anzahl der Dezimalstellen ist. M <= 65 |
NUMERIC, BIGNUMERIC, FLOAT64 oder STRING |
DECIMAL (M,D) wird standardmäßig NUMERIC zugeordnet oder kann BIGNUMERIC, FLOAT64 oder STRING mit default_type_for_decimal_columns zugeordnet werden. |
Ungefähre numerische Werte | |||
FLOAT (M,D) | 4 Byte, M <= 23 | FLOAT64 | |
DOUBLE (M,D) | 8 Byte, M <= 53 | FLOAT64 | |
Datum und Uhrzeit | |||
TIMESTAMP | "1970-01-01 00:00:01" UTC bis "2038-01-19 03:14:07" UTC | TIMESTAMP | MySQL TIMESTAMP wird als UTC-Zeitzone abgerufen, unabhängig davon, von wo aus Sie BigQuery aufrufen. |
DATETIME | "1000-01-01 00:00:00" bis "9999-12-31 23:59:59". | DATETIME | |
DATE | "1000-01-01" bis "9999-12-31" | DATE | |
TIME | Uhrzeit im Format "HH:MM:SS" "-838:59:59" bis "838:59:59" |
TIME |
Der TIME-Bereich in BigQuery ist kleiner, von 00:00:00 bis 23:59:59 |
YEAR | INT64 | ||
Zeichen und Strings | |||
ENUM | Stringobjekt mit einem Wert aus einer Liste zulässiger Werte | STRING | |
CHAR (M) | Ein String mit fester Länge zwischen 1 und 255 Zeichen | STRING | |
VARCHAR (M) | Ein String mit variabler Länge zwischen 1 und 255 Zeichen | STRING | |
TEXT | Ein Feld mit einer maximalen Länge von 65.535 Zeichen | STRING | |
TINYTEXT | Eine TEXT-Spalte mit einer maximalen Länge von 255 Zeichen | STRING | |
MEDIUMTEXT | Eine TEXT-Spalte mit einer maximalen Länge von 16.777.215 Zeichen | STRING | |
LONGTEXT | Eine TEXT-Spalte mit einer maximalen Länge von 4.294.967.295 Zeichen | STRING | |
Binär | |||
BLOB | Ein Binary Large Object mit einer maximalen Länge von 65.535 Zeichen | BYTES | |
MEDIUM_BLOB | Ein BLOB mit einer maximalen Länge von 16.777.215 Zeichen | BYTES | |
LONG_BLOB | Ein BLOB mit einer maximalen Länge von 4.294.967.295 Zeichen | BYTES | |
TINY_BLOB | Ein BLOB mit einer maximalen Länge von 255 Zeichen | BYTES | |
BINARY | Ein String mit fester Länge zwischen 1 und 255 Zeichen | BYTES | |
VARBINARY | Ein String mit variabler Länge zwischen 1 und 255 Zeichen | BYTES | |
Andere | |||
SET | Geben Sie beim Deklarieren der SET-Spalte einige Werte vor. Verwenden Sie dann INSERT, um dieser Spalte einen beliebigen Satz vordefinierter Werte hinzuzufügen. | STRING |
|
GEOMETRY | GEOGRAPHY | NOCH NICHT UNTERSTÜTZT | |
BIT | INT64 | NOCH NICHT UNTERSTÜTZT |
Typzuordnung von PostgreSQL zu BigQuery
Name | Beschreibung | BigQuery-Typ | Unterschied zwischen Typen |
---|---|---|---|
Ganzzahl | |||
smallint | 2 Byte, -32.768 bis +32.767 | INT64 | |
smallserial | Siehe smallint | INT64 | |
integer | 4 Byte, -2.147.483.648 bis +2.147.483.647 | INT64 | |
serial | Siehe integer | INT64 | |
bigint | 8 Byte, -9.223.372.036.854.775.808 bis 9.223.372.036.854.775.807 | INT64 | |
bigserial | Siehe bigint | INT64 | |
Genaue numerische Werte | |||
numeric [ (p, s) ] | Bis zu 1.000 Stellen | NUMERIC, BIGNUMERIC, FLOAT64 oder STRING | „Numeric“ [ (p, s) ] wird standardmäßig NUMERIC zugeordnet oder kann BIGNUMERIC, FLOAT64 oder STRING mit default_type_for_decimal_columns zugeordnet werden. |
Decimal [ (p, s) ] | Siehe numeric | NUMERIC | Siehe numeric |
money | 8 Byte, zwei Dezimalstellen, -92.233.720.368.547.758,08 bis +92.233.720.368.547.758,07 | NICHT UNTERSTÜTZT | |
Ungefähre numerische Werte | |||
real | 4 Byte, Gleitkommazahl mit einfacher Genauigkeit | FLOAT64 | |
double precision | 8 Byte, Gleitkommazahl mit doppelter Genauigkeit | FLOAT64 | |
Datum und Uhrzeit | |||
date | Kalenderdatum (Jahr, Monat, Tag) | DATE | |
time [ (p) ] [ ohne Zeitzone ] | Uhrzeit (ohne Zeitzone) | TIME | |
time [ (p) ] mit Zeitzone | Uhrzeit, mit Zeitzone | NICHT UNTERSTÜTZT | |
timestamp [ (p) ] [ ohne Zeitzone ] | Datum und Uhrzeit (ohne Zeitzone) | DATETIME | |
timestamp [ (p) ] mit Zeitzone | Datum und Uhrzeit, mit Zeitzone | TIMESTAMP | PostgreSQL TIMESTAMP wird als UTC-Zeitzone abgerufen, unabhängig davon, von wo aus Sie BigQuery aufrufen. |
interval | Eine Zeitdauer | NICHT UNTERSTÜTZT | |
Zeichen und Strings | |||
character [ (n) ] | Zeichenstring mit fester Länge | STRING | |
character varying [ (n) ] | Zeichenstring mit variabler Länge | STRING | |
text | Zeichenstring mit variabler Länge | STRING | |
Binär | |||
bytea | Binärdaten ("Bytearray") | BYTES | |
bit [ (n) ] | Bitfolge mit fester Länge | BYTES | |
bit varying [ (n) ] | Bitfolge mit variabler Länge | BYTES | |
Andere | |||
boolean | Logischer boolescher Wert (wahr/falsch) | BOOL | |
inet | IPv4- oder IPv6-Hostadresse | NICHT UNTERSTÜTZT | |
path | Geometrischer Pfad auf einer Ebene | NICHT UNTERSTÜTZT | |
pg_lsn | PostgreSQL-Logsequenznummer | NICHT UNTERSTÜTZT | |
point | Geometrischer Punkt auf einer Ebene | NICHT UNTERSTÜTZT | |
polygon | Geschlossener geometrischer Pfad auf einer Ebene | NICHT UNTERSTÜTZT | |
tsquery | Textsuchabfrage | NICHT UNTERSTÜTZT | |
tsvector | Textsuchdokument | NICHT UNTERSTÜTZT | |
txid_snapshot | Snapshot der Transaktions-ID auf Nutzerebene | NICHT UNTERSTÜTZT | |
uuid | Universell eindeutige Kennzeichnung | NICHT UNTERSTÜTZT | |
xml | XML-Daten. | STRING | |
box | Rechteckiges Feld auf einer Ebene | NICHT UNTERSTÜTZT | |
cidr | IPv4- oder IPv6-Netzwerkadresse | NICHT UNTERSTÜTZT | |
Kreis | Kreis auf einer Ebene | NICHT UNTERSTÜTZT | |
interval [ Felder ] [ (p) ] | Zeitspanne | NICHT UNTERSTÜTZT | |
json | JSON-Textdaten | STRING | |
jsonb | JSON-Binärdaten, zerlegt | NICHT UNTERSTÜTZT | |
Linie | Unendliche Linie auf einer Ebene | NICHT UNTERSTÜTZT | |
lseg | Liniensegment auf einer Ebene | NICHT UNTERSTÜTZT | |
macaddr | MAC-Adresse (Media Access Control) | NICHT UNTERSTÜTZT | |
macaddr8 | MAC-Adresse (Media Access Control) (EUI-64-Format) | NICHT UNTERSTÜTZT |