Bagaimana Google Menyimpan Tabel Kueri Besar Anda Dan Bagaimana Pengaruhnya Terhadap Anda

Ini adalah instalasi pembicaraan teknologi dari blog kami, dipersembahkan oleh pengembang luar biasa, Adam Knox.

Meskipun Big Query menggunakan sintaks yang sangat mirip dengan SQL, sebenarnya dibutuhkan cara yang sangat berbeda untuk solusi pemrosesan data dalam jumlah besar. Big Query memiliki kecenderungan untuk memaksa sesuatu dan tidak benar-benar menggunakan indeks, jadi banyak data berarti banyak prosesor dan waktu pemrosesan. Untuk melakukan ini, Google telah menggunakan cara berbeda untuk menyimpan data yang dapat memengaruhi cara Anda mendesain kueri.

Format Berkas

Saat tabel dibuat, Google menggunakan format ColumnIO mereka untuk menyimpan data Anda. Setiap kolom disimpan sebagai file terpisah dengan pengecualian bidang yang berulang. Jika Anda memiliki tabel dengan kolom: name (string), phoneNumbers (repeated integer); nama akan disimpan dalam satu baris dengan nama lain, dan semua nomor telepon yang terkait dengan nama tersebut akan disimpan dalam satu baris dengan nomor telepon. Kolom juga bisa terbelah jika terlalu besar, tetapi itu tidak akan berdampak pada alur kerja.

Mengetahui hal ini memberikan kemampuan untuk menjalankan kueri lebih cepat dengan tidak memproses kolom yang sebenarnya tidak Anda pedulikan dan dalam beberapa kasus bahkan membuat kueri yang sebelumnya tidak mungkin dijalankan, menjadi mungkin. Kueri juga dapat menjadi lebih murah karena sistem membebankan biaya berdasarkan jumlah data yang diproses, dan jika kolom tidak disertakan dalam kueri, maka data tersebut tidak diproses.

Penyimpanan File

Jika Anda telah membuat tabel, Anda dapat merasa cukup aman bahwa tabel tidak akan kemana-mana, karena setelah file Anda dibuat, mereka akan disimpan di tiga pusat data yang berbeda, dan bahkan tiga tempat berbeda dalam setiap pusat data. Karena Big Query menimbulkan masalah pada prosesor, data harus mudah diakses. Peringatan untuk ini adalah kumpulan data sementara. Ada opsi untuk menentukan waktu kedaluwarsa untuk tabel dalam kumpulan data dan tabel akan hilang setelah lebih lama dari tanggal kedaluwarsa ini.

Tabel Hirarki

Sebuah proyek memiliki kemampuan untuk menyimpan kumpulan data, yang masing-masing dapat berisi tabel. Perintah lengkap untuk mengakses tabel di sintaks Big Query adalah [projectname:datasetname.tablename] , namun ini dapat disingkat menjadi dataset.tablename jika Anda mengakses tabel dari proyek yang sedang Anda kerjakan.

Memecah data terkait ke dalam tabel terpisah (misalnya: menurut tanggal atau setelah peristiwa tertentu terjadi) dapat bermanfaat untuk membuat kueri yang lebih dapat dikelola karena kueri umumnya dijalankan di semua baris dalam tabel. Ini berarti Anda mungkin ingin melihat beberapa tabel, jadi ada sesuatu yang disebut tabel meta yang tersembunyi di setiap kumpulan data yang dapat diakses di [projectname:datasetname.__TABLES__] dan berisi informasi tentang setiap tabel dalam kumpulan data dan dapat digunakan untuk menggabungkan tabel untuk bertanya.

Perintah TABLE_QUERY adalah perintah yang memungkinkan beberapa tabel serupa digabungkan sebelum menjalankan kueri pada agregat, dan kolom apa pun di __TABLES__ dapat digunakan untuk membentuk agregat ini. Misalnya, jika saya ingin mengetahui waktu respons sejak 1 Januari 2016 untuk sebuah proyek, saya dapat menjalankan kueri berikut yang menunjukkan waktu respons minimum, median, dan maksimum:

 SELECT QUANTILES((protoPayload.endTime - protoPayload.startTime), 3) AS responseTimeBucketsInMilliseconds FROM (TABLE_QUERY(appengine_logs, "table_id CONTAINS 'appengine_googleapis_com_request_log' AND creation_time > 1451606400000"))

Karena hanya dua kolom yang masing-masing berisi bilangan bulat yang digunakan, ini masih merupakan kueri yang cukup murah ($0,0003), meskipun mengakses 28+ yang saya diberitahu adalah 1,857TB oleh kueri di bawah ini dan akan menelan biaya sekitar $9 untuk mengakses setiap bidang dari .

 SELECT SUM(size_bytes)/1000000000 FROM [repcore-prod:appengine_logs.__TABLES__] WHERE table_id CONTAINS 'appengine_googleapis_com_request_log' AND creation_time > 1451606400000

Memperbarui File

Big Query sangat bagus dalam hal mencatat perubahan dan menganalisis perubahan tersebut karena Anda dapat mengalirkan baris baru ke tabel. Namun, ini adalah perangkat penyimpanan data yang buruk untuk pencarian cepat dan sering dari baris tertentu karena kurangnya indeks, dan juga tidak bagus dengan menyimpan representasi tunggal dari objek yang Anda harapkan untuk diubah karena baris dalam tabel tidak dapat dimodifikasi atau dihapus. .

Membagi Tabel

Dalam beberapa situasi bahkan mengakses satu kolom terlalu banyak untuk ditangani di Big Query. Saya mempersembahkan kepada Anda kueri yang tidak dapat digunakan berikut yang mengembalikan ID daftar berdasarkan urutan tanggal pembuatan daftar:

 SELECT lid FROM [repcore-prod:datastore.LIS] ORDER BY ct

Secara teknis, baru-baru ini menjadi mungkin untuk berhasil, tetapi tidak untuk orang-orang di Vendasta karena memerlukan pengaktifan tingkat penagihan yang lebih tinggi. Karena tidak ada indeks yang dipesan sebelumnya, ini memproses sejumlah kecil data dengan sangat intensif sehingga dalam hal ini mereka membebankan biaya untuk pemrosesan. Mengubah tingkat penagihan dapat dilakukan dalam kueri interaktif di UI Big Query dengan mencentang “izinkan tidak terbatas” (jika diaktifkan) di bawah tombol “opsi”.

Dengan asumsi kueri Anda seefisien mungkin, ada beberapa pendekatan yang tersisa untuk mengurangi ukuran tabel untuk mengatasi batasan keras semacam ini. Yang pertama adalah dekorator waktu meja dan yang kedua adalah dengan hash.

Anda dapat mempelajari lebih lanjut tentang dekorator meja di sini. Tidak seperti menyaring hasil menggunakan perintah seperti LIMIT/WHERE/HAVING/OMIT , dekorator tabel sebenarnya akan mengurangi biaya kueri tabel karena bahkan tidak akan mengakses data di luar rentang yang diberikan. Sayangnya, metode ini hampir tidak berguna di Vendasta karena bahkan untuk tabel seperti ListingHistoryModel yang sebenarnya kami alirkan, kami masih menghapus seluruh tabel dan menggantinya setiap hari dengan replika jika dari NDB artinya dekorator waktu tabel hanya akan bekerja pada ListingHistoryModel jika Anda hanya peduli dengan entri hari ini.

Melihat logging adalah satu-satunya tempat mereka bisa sangat membantu di Vendasta. Karena ukuran konten log yang sebenarnya, komputasi dan batas memori mudah dicapai, dan kueri bahkan hanya untuk kolom konten log saja mahal. Dengan log, biasanya orang juga hanya peduli pada titik waktu tertentu yang persis dengan bantuan dekorator waktu.

Hasil Kueri

Setiap kali Anda menjalankan kueri, itu membuat tabel baru dan terkadang membuat tabel tersembunyi yang tidak diketahui di balik layar. Jika Anda memilih demikian, maka Anda dapat memberi tabel hasil nama untuk menyimpannya, atau membiarkannya tetap dengan nama yang diberikan google dan membiarkannya menghilang setelah sehari. Jika Anda pernah mengalami "Respons terlalu besar untuk dikembalikan" itu karena mereka melindungi Anda dari diri sendiri. Sangat mudah untuk membuat tabel besar (terutama dengan gabungan silang). Jika ini terjadi dan Anda mengharapkannya terjadi, maka Anda harus memberi nama tabel dan mengaktifkan opsi "Izinkan Hasil Besar". Jika Anda mengulangi kueri yang tidak memiliki baris baru yang dialirkan ke sana, maka Anda hanya akan mendapatkan hasil yang di-cache jika masih ada.