Masz trzy lata danych historycznych w BigQuery i codzienny proces ingestowania danych. Zapytania filtrowane do ostatnich 30–90 dni nadal skanują całą tabelę, zwiększając koszty. Jakie jest najbardziej opłacalne rozwiązanie, zachowując dostęp SQL?

Poprawna odpowiedź to partycjonowanie tabel według kolumny typu TIMESTAMP lub DATE. BigQuery jest zoptymalizowane do skanowania tylko niezbędnych partycji, gdy zapytania zawierają filtry na kolumnie partycjonującej. To znacznie redukuje ilość skanowanych danych i obniża koszty, jednocześnie zachowując dostęp SQL. Pozostałe opcje są mniej optymalne: Eksportowanie do CSV i używanie Cloud Datalab (obecnie Vertex AI Workbench) nie jest rozwiązaniem dla problemu skanowania w BigQuery i wprowadza dodatkową warstwę złożoności oraz potencjalne koszty przechowywania. Rozdzielenie danych na dwie tabele (krótkoterminowe i długoterminowe) wymagałoby modyfikacji zapytań i logiki aplikacji do łączenia danych, co jest mniej efektywne niż wbudowane partycjonowanie. Tworzenie oddzielnej tabeli dla każdego dnia za pomocą Apache Beam i używanie symboli wieloznacznych jest możliwe, ale znacznie zwiększa złożoność zarządzania tabelami i zapytań, co jest mniej eleganckie i trudniejsze w utrzymaniu niż partycjonowanie.