Jebakan JOIN Firestore
Anda menghadapi masalah Firestore yang umum. Fungsi Firebase Anda memunculkan error ukuran batch maksimum (maximum batch size error). Anda perlu menggabungkan (join) pesanan dan pelanggan untuk sebuah dashboard. Biasanya Anda menduplikasi data untuk memperbaikinya. Namun sekarang data Anda menjadi usang dan tidak konsisten.
Google mengumumkan Pipelines API untuk mengatasi hal ini. API ini memungkinkan operasi JOIN di berbagai koleksi tanpa menduplikasi data. Beberapa pengembang melaporkan waktu kueri yang cepat dalam pengujian skala kecil.
Saya menghabiskan satu minggu menguji API ini di bawah beban berat. Inilah hal-hal yang tidak diberitahukan oleh dokumentasinya.
Biaya Tinggi Setiap eksekusi pipeline membaca dari semua koleksi yang terlibat. Sebuah JOIN antara dua koleksi akan menagih biaya pembacaan (reads) pada keduanya. Jika Anda melakukan JOIN pada dua koleksi berisi 50.000 dokumen, biaya Anda akan membengkak dengan buruk. Ini bukan sekadar biaya linear yang sederhana.
Batasan Performa Dalam pengujian saya, sebuah pipeline terhadap 10.000 dokumen memakan waktu 380ms. Saat saya menguji 100.000 dokumen, kuerinya mengalami timeout pada detik ke-30. Anda tidak sedang memperbaiki masalah tersebut. Anda hanya mengubah error batch menjadi error timeout.
Masalah Cold Start Pipelines membuat konteks eksekusi yang terpisah. Dalam lingkungan serverless seperti Cloud Functions, hal ini menambah penundaan selama 2 hingga 4 detik. Pengguna Anda akan menganggap aplikasi Anda lambat.
Pipelines API adalah alat untuk pembuatan prototipe atau koleksi kecil di bawah 5.000 dokumen. Ini bukan pengganti database relasional. Google menyediakan ini untuk membantu Anda tetap berada dalam ekosistem Firebase alih-alih pindah ke PostgreSQL atau Spanner.
Jika Anda menggunakan Pipelines, ikuti aturan berikut:
• Audit ukuran koleksi Anda. Jika sebuah koleksi melebihi 20.000 dokumen, hitung biaya JOIN terlebih dahulu. • Batasi kompleksitas. JOIN di tiga koleksi atau lebih adalah pertanda buruk. • Pantau biaya pembacaan setiap minggu. Pembacaan Pipeline muncul secara berbeda pada tagihan Anda. • Tetap simpan data denormalisasi Anda. Gunakan Pipelines sebagai pelengkap, bukan pengganti total. • Uji dengan trafik nyata. Benchmark pada koleksi yang sepi tidak mencerminkan realitas produksi.
Jangan gunakan solusi sementara untuk menghindari keputusan arsitektur yang sebenarnya.
Bagaimana Anda menangani relasi di Firestore? Apakah Anda menggunakan denormalisasi atau client-side joins? Beritahu saya di kolom komentar.