BigQuery bez optymalizacji skanuje całą tabelę przy każdym zapytaniu – Full Table Scan. Na tabeli 500 GB oznacza to $2.50 za każde zapytanie, nawet jeśli potrzebujesz danych tylko z ostatniego tygodnia. Partycjonowanie i klastrowanie redukują ten koszt do ułamka – często o 90-95%. To dwie różne techniki, które rozwiązują dwa różne problemy.
Partycjonowanie – cięcie tabeli po dacie
Partycjonowanie dzieli fizycznie tabelę na segmenty według wartości kolumny (najczęściej daty). Każdy dzień, miesiąc lub rok to osobny blok danych na dysku BigQuery.
Gdy zapytanie zawiera filtr WHERE transaction_date > '2026-04-01', BigQuery pomija wszystkie partycje sprzed tej daty – nie odczytuje ich nawet z dysku. Zamiast skanować 500 GB historycznych danych, skanuje np. 15 GB z ostatnich 30 dni.
Partycjonowanie stosuj gdy:
- Tabela rośnie w czasie (eventy, transakcje, logi GA4, dane IoT)
- Zapytania prawie zawsze filtrują po dacie lub przedziale czasowym
- Tabela ma >1 GB i jest odpytywana regularnie z Data Studio lub Scheduled Queries
Klastrowanie – sortowanie po kolumnach kategorycznych
Klastrowanie nie tnie tabeli na partycje – zamiast tego sortuje fizycznie dane według wybranych kolumn. BigQuery wie gdzie na dysku są dane z region = 'PL' i przy zapytaniu z WHERE region = 'PL' pomija bloki z innymi regionami.
Klastrowanie stosuj gdy:
- Zapytania często filtrują po kolumnach tekstowych: kategoria, kanał, region, status zamówienia
- Kolumna ma umiarkowaną liczbę unikalnych wartości (10–10 000 kategorii)
- Masz zapytania z wieloma filtrami jednocześnie:
WHERE kraj = 'PL' AND kategoria = 'elektronika'
Maksymalnie 4 kolumny klastrowe na tabelę, podawane w kolejności od najczęściej filtrowanej.
SQL: Tworzenie tabel z partycją i klastrem
-- Tabela z partycjonowaniem po dacie i klastrowaniem po 2 kolumnach
CREATE TABLE `projekt.analytics.transakcje`
PARTITION BY DATE(transaction_date)
CLUSTER BY region, category
AS
SELECT
transaction_id,
transaction_date,
region,
category,
revenue,
cost
FROM `projekt.raw.transakcje_source`
Po tej operacji Data Studio podłączone do tej tabeli automatycznie korzysta z optymalizacji – gdy użytkownik filtruje dashboard po dacie i regionie, BigQuery skanuje tylko pasujące partycje i bloki klastrowe.
Porównanie: kiedy stosować co?
| Cecha | Partycjonowanie | Klastrowanie | Oba razem |
|---|---|---|---|
| Filtrowanie po dacie | Tak | Nie | Tak |
| Filtrowanie po kategorii/regionie | Nie | Tak | Tak |
| Gwarantowane pruning | Tak (dokładne) | Tak (przybliżone) | Tak (oba) |
| Maks. podział | 4 000 partycji/tabela | 4 kolumny | – |
| Najlepsze dla | Dane szeregów czasowych | Dane kategoryczne | Większość produkcyjnych DWH |
Przykład oszczędności: tabela transakcji 500 GB
Firma e-commerce z 3 lata historycznych danych transakcji (500 GB łącznie, ~5 GB/miesiąc). Dashboard Data Studio odpytuje dane z ostatnich 30 dni, filtrując po regionie.
| Wariant | Skanowane dane | Koszt zapytania |
|---|---|---|
| Brak optymalizacji (Full Table Scan) | 500 GB | $2.50 |
| Tylko partycjonowanie (ostatnie 30 dni) | ~5 GB | $0.025 |
| Partycja + Klastrowanie (30 dni, 1 region) | ~0.5 GB | $0.0025 (–99,9%) |
Przy dashboardzie otwieranym 50 razy dziennie przez 5 osób: bez optymalizacji – $3 750/rok. Z partycją i klastrowaniem – $3.75/rok. Różnica wynika wyłącznie z dwóch linii SQL przy tworzeniu tabeli.
Partycjonuj po czasie, klastruj po kategoriach – i podepnij Data Studio do widoku BigQuery zamiast surowej tabeli. To trzy zasady, które eliminują 95%+ kosztów zapytań w typowych dashboardach B2B.