Replikasi database menggunakan pengambilan data perubahan

Last reviewed 2020-10-20 UTC

Dokumen ini menjelaskan beberapa pendekatan dalam menggunakan pengambilan data perubahan (CDC) untuk mengintegrasikan berbagai sumber data dengan BigQuery. Dokumen ini memberikan analisis kompromi antara konsistensi data, kemudahan penggunaan, dan biaya untuk setiap pendekatan. Hal ini akan membantu Anda memahami solusi yang ada, mempelajari berbagai pendekatan untuk menggunakan data yang direplikasi oleh CDC, dan dapat membuat analisis biaya-manfaat terhadap pendekatan-pendekatan tersebut.

Dokumen ini ditujukan untuk membantu arsitek data, data engineer, dan analis bisnis dalam mengembangkan pendekatan yang optimal untuk mengakses data replika di BigQuery. Hal ini mengasumsikan bahwa Anda sudah memahami BigQuery, SQL, dan alat command line.

Ringkasan replikasi data CDC

Database seperti MySQL, Oracle, dan SAP adalah sumber data CDC yang paling sering dibahas. Namun, setiap sistem dapat dianggap sebagai sumber data jika sistem tersebut menangkap dan menyediakan perubahan pada elemen data yang diidentifikasi oleh kunci utama. Jika sistem tidak menyediakan proses CDC bawaan, seperti log transaksi, Anda dapat men-deploy pembaca batch inkremental untuk mendapatkan perubahan.

Dokumen ini membahas proses CDC yang memenuhi kriteria berikut:

  1. Replikasi data menangkap perubahan untuk setiap tabel secara terpisah.
  2. Setiap tabel memiliki kunci utama atau kunci utama gabungan.
  3. Setiap peristiwa CDC yang dimunculkan diberi ID perubahan yang meningkat secara monoton, biasanya nilai numerik seperti ID transaksi atau stempel waktu.
  4. Setiap peristiwa CDC berisi status lengkap dari baris yang diubah.

Diagram berikut menunjukkan arsitektur umum menggunakan CDC untuk mereplikasi sumber data ke BigQuery:

Arsitektur umum yang menggunakan CDC untuk mereplikasi sumber data ke BigQuery.

Pada diagram sebelumnya, tabel utama dan tabel delta dibuat di BigQuery untuk setiap tabel data sumber. Tabel utama berisi semua kolom tabel sumber, ditambah satu kolom untuk nilai ID perubahan terbaru. Anda dapat mempertimbangkan nilai ID perubahan terbaru sebagai ID versi entity yang diidentifikasi oleh kunci utama kumpulan data, dan menggunakannya untuk menemukan versi terbaru.

Tabel delta berisi semua kolom tabel sumber, ditambah kolom jenis operasi—salah satu dari pembaruan, penyisipan, atau penghapusan—dan nilai ID perubahan.

Berikut adalah keseluruhan proses untuk mereplikasi data ke BigQuery menggunakan CDC:

  1. Dump data awal tabel sumber diekstrak.
  2. Data yang diekstrak akan ditransformasi secara opsional, lalu dimuat ke dalam tabel utama yang sesuai. Jika tabel tidak memiliki kolom yang dapat digunakan sebagai ID perubahan, seperti stempel waktu yang terakhir diperbarui, ID perubahan akan ditetapkan ke nilai terendah untuk jenis data kolom tersebut. Hal ini memungkinkan pemrosesan berikutnya mengidentifikasi kumpulan data tabel utama yang diperbarui setelah dump data awal.
  3. Baris yang berubah setelah dump data awal dicatat oleh proses pengambilan CDC.
  4. Jika diperlukan, transformasi data tambahan dilakukan oleh lapisan pemrosesan CDC. Misalnya, lapisan pemrosesan CDC mungkin memformat ulang stempel waktu untuk digunakan oleh BigQuery, membagi kolom secara vertikal, atau menghapus kolom.
  5. Data disisipkan ke tabel delta yang sesuai di BigQuery, menggunakan pemuatan micro-batch atau streaming insert.

Jika transformasi tambahan dilakukan sebelum data dimasukkan ke BigQuery, jumlah dan jenis kolom dapat berbeda dari tabel sumber. Namun, kumpulan kolom yang sama ada di tabel utama dan tabel delta.

Tabel delta berisi semua peristiwa perubahan untuk tabel tertentu sejak pemuatan awal. Menyediakan semua peristiwa perubahan dapat bermanfaat untuk mengidentifikasi tren, status entity yang diwakili oleh tabel pada momen tertentu, atau frekuensi perubahan.

Untuk mendapatkan status entity saat ini yang diwakili oleh kunci utama tertentu, Anda dapat membuat kueri tabel utama dan tabel delta untuk kumpulan data yang memiliki ID perubahan terbaru. Kueri ini dapat menjadi mahal karena Anda mungkin perlu melakukan penggabungan antara tabel utama dan delta serta menyelesaikan pemindaian tabel menyeluruh terhadap salah satu atau kedua tabel guna menemukan entri terbaru untuk kunci utama tertentu. Anda dapat menghindari pemindaian tabel menyeluruh dengan mengelompokkan atau mempartisi tabel berdasarkan kunci utama, tetapi tidak selalu memungkinkan.

Dokumen ini membandingkan pendekatan umum berikut yang dapat membantu Anda mendapatkan status entity saat ini ketika Anda tidak dapat mempartisi atau mengelompokkan tabel:

  • Pendekatan konsistensi yang segera: kueri mencerminkan status saat ini dari data replika. Konsistensi yang segera memerlukan kueri yang menggabungkan tabel utama dan tabel delta, serta memilih baris terbaru untuk setiap kunci utama.
  • Pendekatan yang dioptimalkan untuk biaya: kueri yang lebih cepat dan lebih murah dijalankan tetapi ketersediaan data akan menjadi lebih terlambat. Anda dapat menggabungkan data ke tabel utama secara berkala.
  • Pendekatan campuran: Anda menggunakan pendekatan konsistensi yang segera atau pendekatan yang dioptimalkan untuk biaya bergantung pada kebutuhan dan anggaran Anda.

Selain pendekatan-pendekatan ini, dokumen ini juga membahas cara lebih lanjut untuk meningkatkan performa.

Sebelum memulai

Dokumen ini menunjukkan penggunaan alat command line bq dan pernyataan SQL untuk melihat dan membuat kueri data BigQuery. Contoh tata letak dan kueri tabel akan ditampilkan nanti dalam dokumen ini. Jika Anda ingin bereksperimen dengan data sampel, selesaikan penyiapan berikut:

  1. Pilih project atau buat project dan aktifkan penagihan untuk project tersebut.
    • Jika Anda membuat project, BigQuery akan diaktifkan secara otomatis.
    • Jika Anda memilih project yang sudah ada, aktifkan BigQuery API.
  2. Di konsol Google Cloud, buka Cloud Shell.

  3. Untuk memperbarui file konfigurasi BigQuery, buka file ~/.bigqueryrc di editor teks dan tambahkan atau perbarui baris berikut di mana saja dalam file:

    [query]
--use_legacy_sql=false

[mk]
--use_legacy_sql=false

  4. Clone repositori GitHub yang berisi skrip untuk menyiapkan lingkungan BigQuery:

    git clone https://github.com/GoogleCloudPlatform/bq-mirroring-cdc.git

  5. Buat set data, tabel utama, dan tabel delta:

    cd bq-mirroring-cdc/tutorial
chmod +x *.sh
./create-tables.sh

Untuk menghindari potensi tagihan saat selesai bereksperimen, nonaktifkan project atau hapus set data.

Menyiapkan data BigQuery

Guna menunjukkan berbagai solusi untuk replikasi data CDC ke BigQuery, Anda menggunakan sepasang tabel utama dan delta yang diisi dengan data sampel seperti tabel contoh sederhana berikut.

Untuk menggunakan penyiapan yang lebih canggih dari yang dijelaskan dalam dokumen ini, Anda dapat menggunakan demo integrasi BigQuery CDC. Demo ini mengotomatiskan proses pengisian tabel, dan mencakup skrip untuk memantau proses replikasi. Jika Anda ingin menjalankan demo, ikuti petunjuk dalam file README yang ada di root repositori GitHub yang Anda clone di bagian Sebelum memulai dalam dokumen ini.

Contoh data menggunakan model data sederhana: sesi web yang berisi ID sesi yang dibuat sistem yang diperlukan dan nama pengguna opsional. Saat sesi dimulai, nama pengguna akan bernilai null. Setelah pengguna login, nama pengguna akan terisi.

Untuk memuat data ke tabel utama dari skrip lingkungan BigQuery, Anda dapat menjalankan perintah seperti berikut ini:

bq load cdc_tutorial.session_main init.csv

Untuk mendapatkan isi tabel utama, Anda dapat menjalankan kueri seperti berikut:

bq query "select * from cdc_tutorial.session_main limit 1000"

Outputnya akan terlihat seperti berikut:

+-----+----------+-----------+
| id  | username | change_id |
+-----+----------+-----------+
| 100 | NULL     |         1 |
| 101 | Sam      |         2 |
| 102 | Jamie    |         3 |
+-----+----------+-----------+

Selanjutnya, Anda memuat batch pertama perubahan CDC ke dalam tabel delta. Untuk memuat batch pertama perubahan CDC ke tabel delta dari skrip lingkungan BigQuery, Anda dapat menjalankan perintah seperti berikut:

bq load cdc_tutorial.session_delta first-batch.csv

Untuk mendapatkan isi tabel delta, Anda dapat menjalankan kueri seperti berikut:

bq query "select * from cdc_tutorial.session_delta limit 1000"

Outputnya akan terlihat seperti berikut:

+-----+----------+-----------+-------------+
| id  | username | change_id | change_type |
+-----+----------+-----------+-------------+
| 100 | Cory     |         4 | U           |
| 101 | Sam      |         5 | D           |
| 103 | NULL     |         6 | I           |
| 104 | Jamie    |         7 | I           |
+-----+----------+-----------+-------------+

Dalam output sebelumnya, nilai change_id adalah ID unik dari perubahan baris tabel. Nilai dalam kolom change_type mewakili hal berikut:

  • U: operasi pembaruan
  • D: operasi penghapusan
  • I: operasi penyisipan

Tabel utama berisi informasi tentang sesi 100, 101, dan 102. Tabel delta memiliki perubahan berikut:

  • Sesi 100 diperbarui dengan nama pengguna "Cory".
  • Sesi 101 dihapus.
  • Sesi 103 dan 104 baru dibuat.

Status sesi saat ini pada sistem sumber adalah sebagai berikut:

+-----+----------+
| id  | username |
+-----+----------+
| 100 | Cory     |
| 102 | Jamie    |
| 103 | NULL     |
| 104 | Jamie    |
+-----+----------+

Meskipun status saat ini ditampilkan sebagai tabel, tabel ini tidak ada dalam bentuk terwujud. Tabel ini adalah kombinasi dari tabel utama dan delta.

Mengkueri data.

Ada beberapa pendekatan yang dapat Anda gunakan untuk menentukan status sesi secara keseluruhan. Kelebihan dan kekurangan setiap pendekatan dijelaskan di bagian berikut.

Pendekatan konsistensi yang segera

Jika konsistensi data yang segera adalah tujuan utama Anda dan data sumber sering berubah, Anda dapat menggunakan satu kueri yang menggabungkan tabel utama dan tabel delta, serta memilih baris terbaru (baris dengan stempel waktu terbaru atau nilai angka tertinggi).

Untuk membuat tampilan BigQuery yang menggabungkan tabel utama dan delta serta menemukan baris terbaru, Anda dapat menjalankan perintah alat bq seperti berikut:

bq mk --view \
"SELECT * EXCEPT(change_type, row_num)
FROM (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY change_id DESC) AS row_num
  FROM (
    SELECT * EXCEPT(change_type), change_type
    FROM \`$(gcloud config get-value project).cdc_tutorial.session_delta\` UNION ALL
    SELECT *, 'I'
    FROM \`$(gcloud config get-value project).cdc_tutorial.session_main\`))
WHERE
  row_num = 1
  AND change_type <> 'D'" \
 cdc_tutorial.session_latest_v

Pernyataan SQL dalam tampilan BigQuery sebelumnya melakukan hal berikut:

  • UNION ALL terdalam menghasilkan baris dari tabel utama dan tabel delta:
    • SELECT * EXCEPT(change_type), change_type FROM session_delta memaksa kolom change_type menjadi kolom terakhir dalam daftar.
    • SELECT *, 'I' FROM session_main memilih baris dari tabel utama seolah-olah baris tersebut merupakan baris sisipan.
    • Menggunakan operator * membuat contoh tetap sederhana. Jika ada kolom tambahan atau urutan kolom yang berbeda, ganti pintasan dengan daftar kolom eksplisit.
  • SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY change_id DESC) AS row_num menggunakan fungsi jendela di BigQuery untuk menetapkan nomor baris berurutan yang dimulai dengan 1 ke setiap grup baris yang memiliki nilai id yang sama, yang ditentukan oleh PARTITION BY. Baris diurutkan berdasarkan change_id dalam urutan menurun dalam grup tersebut. Karena change_id dijamin akan meningkat, perubahan terbaru memiliki kolom row_num yang memiliki nilai 1.
  • WHERE row_num = 1 AND change_type <> 'D' hanya memilih baris terbaru dari setiap grup. Ini adalah teknik penghapusan duplikat yang umum digunakan di BigQuery. Klausa ini juga menghapus baris dari hasil jika jenis perubahannya adalah penghapusan.
  • SELECT * EXCEPT(change_type, row_num) paling atas menghapus kolom tambahan yang diperkenalkan untuk pemrosesan dan yang tidak relevan.

Contoh sebelumnya tidak menggunakan jenis perubahan penyisipan dan pembaruan dalam tampilan karena mereferensikan nilai change_id tertinggi akan memilih penyisipan asli atau pembaruan terbaru. Dalam hal ini, setiap baris berisi data lengkap untuk semua kolom.

Setelah membuat tampilan, Anda dapat menjalankan kueri terhadap tampilan tersebut. Untuk mendapatkan perubahan terbaru, Anda dapat menjalankan kueri seperti berikut:

bq query 'select * from cdc_tutorial.session_latest_v order by id limit 10'

Outputnya akan terlihat seperti berikut:

+-----+----------+-----------+
| id  | username | change_id |
+-----+----------+-----------+
| 100 | Cory     |         4 |
| 102 | Jamie    |         3 |
| 103 | NULL     |         6 |
| 104 | Jamie    |         7 |
+-----+----------+-----------+

Saat Anda membuat kueri tampilan, data dalam tabel delta akan segera terlihat jika Anda memperbarui data dalam tabel delta menggunakan pernyataan bahasa manipulasi data (DML), atau hampir segera jika Anda melakukan streaming data.

Pendekatan yang dioptimalkan untuk biaya

Pendekatan konsistensi yang segera cukup sederhana, tetapi tidak efisien karena mengharuskan BigQuery untuk membaca semua data historis, mengurutkan berdasarkan kunci utama, dan memproses operasi lain dalam kueri untuk mengimplementasikan tampilan. Jika Anda sering mengkueri status sesi, pendekatan konsistensi yang segera dapat menurunkan performa dan meningkatkan biaya penyimpanan serta pemrosesan data di BigQuery.

Untuk meminimalkan biaya, Anda dapat menggabungkan perubahan tabel delta ke tabel utama dan secara berkala menghapus permanen baris gabungan dari tabel delta. Terdapat biaya tambahan untuk penggabungan dan penghapusan permanen, tetapi jika Anda sering mengkueri tabel utama, biayanya jauh lebih kecil dibandingkan dengan biaya untuk terus menemukan kumpulan data terbaru sebuah kunci dalam tabel delta.

Untuk menggabungkan data dari tabel delta ke tabel utama, Anda dapat menjalankan pernyataan MERGE seperti berikut:

bq query \
'MERGE `cdc_tutorial.session_main` m
USING
  (
  SELECT * EXCEPT(row_num)
  FROM (
    SELECT *, ROW_NUMBER() OVER(PARTITION BY delta.id ORDER BY delta.change_id DESC) AS row_num
    FROM `cdc_tutorial.session_delta` delta )
  WHERE row_num = 1) d
ON  m.id = d.id
  WHEN NOT MATCHED
AND change_type IN ("I", "U") THEN
INSERT (id, username, change_id)
VALUES (d.id, d.username, d.change_id)
  WHEN MATCHED
  AND d.change_type = "D" THEN
DELETE
  WHEN MATCHED
  AND d.change_type = "U"
  AND (m.change_id < d.change_id) THEN
UPDATE
SET username = d.username, change_id = d.change_id'

Pernyataan MERGE sebelumnya memengaruhi empat baris dan tabel utama memiliki status sesi saat ini. Untuk mengkueri tabel utama dalam tampilan ini, Anda dapat menjalankan kueri seperti berikut:

  bq query 'select * from cdc_tutorial.session_main order by id limit 10'

Outputnya akan terlihat seperti berikut:

+-----+----------+-----------+
| id  | username | change_id |
+-----+----------+-----------+
| 100 | Cory     |         4 |
| 102 | Jamie    |         3 |
| 103 | NULL     |         6 |
| 104 | Jamie    |         7 |
+-----+----------+-----------+

Data dalam tabel utama mencerminkan status sesi terbaru.

Cara terbaik untuk menggabungkan data secara rutin dan konsisten adalah dengan menggunakan pernyataan MERGE, yang memungkinkan Anda menggabungkan beberapa pernyataan INSERT, UPDATE, dan DELETE ke dalam satu operasi atomik. Berikut adalah beberapa nuansa dari pernyataan MERGE sebelumnya:

  • Tabel session_main digabungkan dengan sumber data yang ditentukan dalam klausa USING, yang dalam hal ini adalah subkueri.
  • Subkueri menggunakan teknik yang sama seperti tampilan dalam pendekatan konsistensi yang segera: teknik ini memilih baris terbaru dalam grup kumpulan data yang memiliki nilai id yang sama— kombinasi ROW_NUMBER() OVER(PARTITION BY id ORDER BY change_id DESC) row_num dan WHERE row_num = 1.
  • Penggabungan dilakukan pada kolom id dari kedua tabel, yang merupakan kunci utama.
  • Klausa WHEN NOT MATCHED memeriksa kecocokan. Jika tidak ada kecocokan, kueri akan memeriksa apakah kumpulan data terbaru adalah penyisipan atau pembaruan, lalu menyisipkan kumpulan data tersebut.
    • Jika kumpulan data cocok dan jenis perubahan adalah penghapusan, kumpulan data akan dihapus dalam tabel utama.
    • Jika kumpulan data cocok, jenis perubahan akan pembaruan, dan nilai change_id tabel delta lebih tinggi dari nilai change_id kumpulan data utama, data akan diperbarui, termasuk nilai change_id terbaru.

Pernyataan MERGE sebelumnya berfungsi dengan benar untuk kombinasi perubahan berikut:

  • Beberapa baris pembaruan untuk kunci utama yang sama: hanya pembaruan terbaru yang akan diterapkan.

  • Pembaruan yang tidak cocok di tabel utama: jika tabel utama tidak memiliki kumpulan data di bawah kunci utama, kumpulan data baru akan disisipkan.

    Pendekatan ini melewati ekstrak tabel utama dan dimulai dengan tabel delta. Tabel utama diisi secara otomatis.

  • Menyisipkan dan memperbarui baris dalam batch delta yang belum diproses. Baris pembaruan terbaru digunakan dan kumpulan data baru dimasukkan ke dalam tabel utama.

  • Menyisipkan dan menghapus baris dalam batch yang belum diproses. Kumpulan data tidak disisipkan.

Pernyataan MERGE sebelumnya bersifat idempoten: menjalankannya beberapa kali menghasilkan status tabel utama yang sama dan tidak menyebabkan efek samping. Jika Anda menjalankan ulang pernyataan MERGE tanpa menambahkan baris baru ke tabel delta, outputnya akan terlihat seperti berikut:

Number of affected rows: 0

Anda dapat menjalankan pernyataan MERGE pada interval reguler untuk memperbarui tabel utama setelah setiap penggabungan. Keaktualan data di tabel utama bergantung pada frekuensi penggabungan. Untuk mengetahui informasi tentang cara menjalankan pernyataan MERGE secara otomatis, lihat bagian "Menjadwalkan penggabungan" di file README demo yang telah Anda download sebelumnya.

Pendekatan campuran

Pendekatan konsistensi yang segera dan pendekatan yang dioptimalkan untuk biaya tidak eksklusif terhadap satu sama lain. Jika Anda menjalankan kueri terhadap tampilan session_latest_v dan tabel session_main, kueri tersebut akan menampilkan hasil yang sama. Anda dapat memilih pendekatan yang akan digunakan bergantung pada kebutuhan dan anggaran Anda: biaya yang lebih tinggi dan konsistensi yang hampir segera atau biaya lebih rendah tetapi data berpotensi tidak berlaku lagi. Bagian berikut membahas cara membandingkan pendekatan dan alternatif potensial.

Membandingkan pendekatan

Bagian ini menjelaskan cara membandingkan pendekatan dengan mempertimbangkan biaya dan performa setiap solusi, serta keseimbangan latensi data yang dapat diterima versus biaya menjalankan penggabungan.

Biaya kueri

Untuk mengevaluasi biaya dan performa setiap solusi, contoh berikut memberikan analisis sekitar 500.000 sesi yang dihasilkan oleh demo integrasi CDC BigQuery. Model sesi dalam demo sedikit lebih kompleks daripada model yang diperkenalkan sebelumnya dalam dokumen ini dan di-deploy di set data yang berbeda, tetapi konsepnya sama.

Anda dapat membandingkan biaya kueri dengan menggunakan kueri agregasi sederhana. Contoh kueri berikut menguji pendekatan konsistensi yang segera terhadap tampilan yang menggabungkan data delta dengan tabel utama:

SELECT status, count(*) FROM `cdc_demo.session_latest_v`
GROUP BY status ORDER BY status

Kueri menghasilkan biaya berikut:

Slot time consumed: 15.115 sec, Bytes shuffled 80.66 MB

Contoh kueri berikut menguji pendekatan yang dioptimalkan untuk biaya terhadap tabel utama:

SELECT status, count(*) FROM `cdc_demo.session_main`
GROUP BY status ORDER BY status

Kueri menghasilkan biaya yang lebih rendah berikut:

Slot time consumed: 1.118 sec, Bytes shuffled 609 B

Konsumsi waktu slot dapat bervariasi ketika Anda menjalankan kueri yang sama beberapa kali, tetapi rata-ratanya cukup konsisten. Nilai Bytes shuffled konsisten di antara eksekusi yang berbeda.

Hasil pengujian performa bervariasi bergantung pada jenis kueri dan tata letak tabel. Demo sebelumnya tidak menggunakan pengelompokan atau partisi data.

Latensi data

Jika Anda menggunakan pendekatan yang dioptimalkan untuk biaya, latensi data adalah jumlah dari hal berikut:

  • Penundaan pemicu replikasi data. Ini adalah waktu antara saat data dipertahankan selama peristiwa sumber dan saat sistem replikasi memicu proses replikasi.
  • Waktu untuk menyisipkan data ke BigQuery (bervariasi berdasarkan solusi replikasi).
  • Waktu untuk menampilkan data buffer streaming BigQuery dalam tabel delta. Jika Anda menggunakan streaming insert, biasanya proses ini berlangsung selama beberapa detik.
  • Penundaan antara proses penggabungan.
  • Waktu untuk menjalankan penggabungan.

Jika Anda menggunakan pendekatan konsistensi yang segera, latensi data adalah jumlah dari hal berikut:

  • Penundaan pemicu replikasi data.
  • Waktu untuk menyisipkan data ke BigQuery.
  • Waktu untuk data buffer streaming bigQuery muncul dalam tabel delta.

Anda dapat mengonfigurasi penundaan antara proses penggabungan bergantung pada kompromi antara biaya menjalankan penggabungan dan kebutuhan agar data menjadi lebih konsisten. Jika perlu, Anda dapat menggunakan skema yang lebih kompleks, seperti penggabungan yang sering yang dilakukan selama jam kerja dan penggabungan setiap jam di luar jam kerja.

Alternatif yang perlu dipertimbangkan

Pendekatan konsistensi yang segera dan pendekatan yang dioptimalkan untuk biaya adalah opsi CDC yang paling umum untuk mengintegrasikan berbagai sumber data dengan BigQuery. Bagian ini menjelaskan opsi integrasi data yang lebih sederhana dan lebih murah.

Tabel delta sebagai satu sumber kebenaran

Jika tabel delta berisi histori lengkap perubahan, Anda dapat membuat tampilan hanya terhadap tabel delta dan tidak menggunakan tabel utama. Menggunakan tabel delta sebagai satu sumber tepercaya adalah contoh database peristiwa. Pendekatan ini memberikan konsistensi instan dengan biaya rendah dengan sedikit penalti performa. Pertimbangkan pendekatan ini jika Anda memiliki tabel dimensi yang berubah sangat lambat dengan sejumlah kecil kumpulan data.

Dump data lengkap tanpa CDC

Jika Anda memiliki tabel dengan ukuran yang dapat dikelola (misalnya, kurang dari 1 GB), akan dapat lebih mudah bagi Anda untuk melakukan dump data lengkap dengan urutan berikut:

  1. Impor dump data awal ke tabel dengan nama unik.
  2. Buat tampilan yang hanya mereferensikan tabel baru.
  3. Jalankan kueri terhadap tampilan, bukan tabel yang mendasarinya.
  4. Impor dump data berikutnya ke tabel lain.
  5. Buat ulang tampilan untuk mengarah ke data yang baru diupload.
  6. Hapus tabel asli (opsional).
  7. Ulangi langkah-langkah sebelumnya untuk mengimpor, membuat ulang, dan menghapus secara rutin.

Mempertahankan histori perubahan di tabel utama

Dalam pendekatan yang dioptimalkan untuk biaya, histori perubahan tidak dipertahankan dan perubahan terbaru akan menimpa data sebelumnya. Jika perlu mempertahankan histori, Anda dapat menyimpannya menggunakan array perubahan, dengan berhati-hati agar tidak melebihi batas ukuran baris maksimum. Jika Anda mempertahankan histori perubahan di tabel utama, penggabungan DML akan lebih kompleks karena satu operasi MERGE dapat menggabungkan beberapa baris dari tabel delta menjadi satu baris dalam tabel utama.

Menggunakan sumber data gabungan

Dalam beberapa kasus, Anda dapat mereplikasi ke sumber data selain BigQuery, lalu mengekspos sumber data tersebut menggunakan kueri gabungan. BigQuery mendukung sejumlah sumber data eksternal. Misalnya, jika mereplikasi skema mirip bintang dari database MySQL, Anda dapat mereplikasi dimensi yang berubah secara perlahan menjadi versi hanya baca MySQL menggunakan replikasi MySQL native. Saat menggunakan metode ini, Anda hanya mereplikasi tabel fakta yang sering berubah ke BigQuery. Jika Anda ingin menggunakan sumber data gabungan, pertimbangkan bahwa ada beberapa batasan dalam mengkueri sumber data gabungan.

Meningkatkan performa lebih lanjut

Bagian ini membahas cara meningkatkan performa lebih lanjut dengan mengelompokkan dan mempartisi tabel serta melakukan pruning pada data gabungan.

Tabel BigQuery cluster dan partisi

Jika Anda memiliki set data yang sering dikueri, analisis penggunaan setiap tabel dan sesuaikan desain tabel menggunakan pengelompokan dan partisi. Mengelompokkan salah satu dari tabel utama dan delta atau keduanya berdasarkan kunci utama dapat menghasilkan performa yang lebih baik dibandingkan dengan pendekatan lainnya. Untuk memverifikasi performa, uji kueri pada set data yang berukuran minimal 10 GB.

Melakukan pruning pada data gabungan

Tabel delta bertambah seiring waktu, dan setiap permintaan penggabungan akan menyia-nyiakan resource dengan membaca sejumlah baris yang tidak diperlukan untuk hasil akhir. Jika Anda hanya menggunakan data tabel delta untuk menghitung status terbaru, melakukan pruning pada data gabungan dapat mengurangi biaya penggabungan dan dapat menurunkan biaya keseluruhan dengan mengurangi jumlah data yang disimpan di BigQuery.

Anda dapat melakukan pruning pada data gabungan dengan cara berikut:

  • Buat kueri secara berkala di tabel utama untuk mengetahui nilai change_id maksimum dan hapus semua kumpulan data delta yang memiliki nilai change_id yang lebih rendah dari nilai maksimum tersebut. Jika Anda melakukan streaming insert ke tabel delta, penyisipan mungkin tidak akan dihapus selama jangka waktu tertentu.
  • Gunakan partisi tabel delta berbasis penyerapan dan jalankan skrip harian untuk menghapus partisi yang sudah diproses. Jika partisi BigQuery yang lebih terperinci tersedia, Anda dapat meningkatkan frekuensi penghapusan permanen. Untuk informasi tentang implementasi, lihat bagian "Menghapus permanen data yang diproses" di file README demo yang telah Anda download sebelumnya.

Kesimpulan

Untuk memilih pendekatan yang tepat—atau beberapa pendekatan—pertimbangkan kasus penggunaan yang ingin Anda selesaikan. Anda mungkin dapat mengatasi kebutuhan replikasi data dengan menggunakan teknologi migrasi database yang ada. Jika Anda memiliki kebutuhan yang kompleks—misalnya, jika Anda perlu menyelesaikan kasus penggunaan data yang hampir real time dan mengoptimalkan biaya untuk pola akses data lainnya—Anda mungkin perlu menyiapkan frekuensi migrasi database khusus berdasarkan produk lain atau solusi open source. Pendekatan dan teknik yang dijelaskan dalam dokumen ini dapat membantu Anda menerapkan solusi tersebut dengan sukses.

Langkah selanjutnya