Seltsames Verhalten bei BigQuery-Dataset-Standort

Question

Ich bemerkte ein merkwürdiges Verhalten in der Google Cloud-Compute-Engine mit BigQuery- und VM-Instanzen.

Ich habe einen Java-Prozess, der Daten in BigQuery streamt.

Ich erwartete bessere Ergebnisse, wenn ich die gleiche Region für das BigQuery-Dataset und die VM-Instanzen auswähle, aber meine Tests zeigten ein unerwartetes Verhalten.

CASE1: VM auf uns-central1-a UND Dataset Lage US Durchschnittliche Zeit für das Einfügen von BigQuery Antwort: 150 Millisekunden

CASE2: VM auf Europa-West1-C und Dataset Lage US Durchschnitt Zeit für das Einfügen von BigQuery Antwort: 700 Millisekunden

Case3: VM auf uns-central1-a UND-Datensatz Standort EU Durchschnittliche Zeit für das Einfügen von BigQuery Antwort: 1200 Millisekunden

Case4: VM auf Europa-West1-C und Dataset Ort EU Durchschnittliche Zeit für das Einfügen von BigQuery responset: 1700 Millisekunden

ich die Abnahme der Leistungen in CASE2 und Case3 verstehen kann, aber was ist Case4?

Der Test zeigt, dass wenn die BigQuery-Dataset-Position "EU" ist, die Leistung abnimmt, selbst wenn die VM-Region europe-west1-c ist.

Meine Schlussfolgerung ist: Verwenden Sie nie Bigquery in der EU (sicher, mit Ausnahme der Anforderungen an den Speicherort der Daten)!

Alles falsch in meinen Überlegungen?

Answer 1

Danke für die Berichterstattung.

Sieht aus wie die im Post erwähnte Latenz beide Tabellen.get() + tabledata.insertAll() enthält. Die Latenzdifferenz wird hauptsächlich durch tables.get() verursacht.

Uns ist bekannt, dass das Aufrufen von Metadaten-bezogenen APIs (z. B. tables.get) aus EU langsamer ist als aus USA. Es wird durch einige bestehende Infrastrukturbeschränkungen verursacht, und leider gibt es eine kurzfristige Lösung dafür. Aber wir arbeiten aktiv an einigen Backend-Änderungen, um diesen Latenzunterschied auf lange Sicht zu minimieren.

Ein paar Dinge, die Sie sich anschauen sollten, dies zu mildern:

• Pre-erstellen Sie Ihre Tabellen vor Zeiten, so dass keine Notwendigkeit, jedes Mal zu überprüfen Tabelle Existenz vor einem insertAll
• Wenn es täglich Tisch, vielleicht PartitionTable versuchen? Dann müssen Sie nur einmal Tabelle erstellen. https://cloud.google.com/bigquery/docs/partitioned-tableshttps://cloud.google.com/bigquery/docs/querying-partitioned-tables
• Wenn neu erstellte Tabellen dasselbe Schema wie eine Basistabelle haben, versuchen Sie, in eine Vorlagentabelle zu streamen. https://cloud.google.com/bigquery/streaming-data-into-bigquery#template-tables