Mengapa 2 kueri ini memiliki GB yang sama yang diproses (dan biayanya)?

Data pengujian saya terdiri dari 27.768.767 baris. Skema saya menyertakan kolom "pesan" bertipe string. Panjang string ini bervariasi tetapi umumnya beberapa ratus karakter. Ada juga kolom user_id bertipe int. Berikut adalah dua kueri yang keduanya mengembalikan 0 baris (klausa Where tidak cocok dengan data saya). Namun yang mengejutkan saya, keduanya melaporkan 4,69 GB diproses.

SELECT * FROM logtesting.logs WHERE user_id=1;

Query complete (1.7s elapsed, 4.69 GB processed)

.

SELECT * FROM logtesting.logs WHERE message CONTAINS 'this string never appears';

Query complete (2.1s elapsed, 4.69 GB processed)

Karena int disimpan dalam 8 byte, saya berharap data yang diproses di int sebelumnya (user_id) kueri akan berukuran sekitar 213MB (28 juta baris * 8 byte per user_id). Kueri (pesan) yang terakhir lebih sulit untuk diperkirakan karena panjang stringnya bervariasi, tetapi saya perkirakan ukurannya beberapa kali lebih besar daripada kueri (user_id) sebelumnya.

Apakah pemahaman saya tentang cara BigQuery menghitung biaya kueri salah?


person Ian Rose    schedule 09.07.2015    source sumber


Jawaban (1)


Apa pun yang Anda lakukan, BigQuery perlu memindai semua baris dalam tabel Anda (meskipun belum tentu semua kolom), jadi wajar jika Anda mengalami hal ini, karena tabel Anda tidak berubah. Klausa Where hanya berarti tidak akan MENGEMBALIKAN data. Pihaknya masih perlu memprosesnya.

Satu-satunya cara untuk memastikan Anda menurunkan pemrosesan adalah dengan tidak memilih semua kolom Anda. BigQuery berbasis kolom, jadi jika Anda tidak memerlukan semua atribut, jangan kembalikan semuanya (ini juga berarti atribut tersebut tidak akan diproses). INI akan membantu menurunkan biaya Anda :)

Secara historis, "pilih *" tidak didukung untuk memastikan orang tidak mengalami kesulitan

person Patrice    schedule 09.07.2015
comment
Wow itu sangat aneh. Saya berharap kolom mana yang saya pilih tidak menjadi masalah karena saya tidak memiliki baris yang cocok, tetapi saya hanya mencoba select user_id alih-alih select * dan itu pasti mengubah banyak hal. 424 MB diproses pada kueri sebelumnya dan 2,17 GB diproses pada kueri terakhir. Mungkin pengoptimalan baca mengharuskan BigQuery menarik semua kolom yang mungkin diperlukan (baik untuk klausa tempat maupun nilai yang dikembalikan) semuanya dalam satu kesempatan, sehingga tidak dapat melakukan pengoptimalan yang saya asumsikan. - person Ian Rose; 09.07.2015
comment
Sejak BigQuery shard, hal ini sebenarnya sudah diduga. Karena ia tidak dapat mengetahui sebelumnya apa yang diperlukan atau tidak, ia hanya membuang seluruh tabel Anda menjadi pecahan, dan setiap pecahan memfilter hasilnya. Karena seluruh meja Anda perlu dikirim bolak-balik, maka Anda dikenakan biaya untuk semuanya. Itu sebabnya mengubah Select itu penting, karena ini berarti hanya kolom relevan yang dikirim - person Patrice; 09.07.2015